[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62272f17-bb97-aa10-d5d9-0914595e5431@linux.intel.com>
Date: Mon, 16 Jan 2023 09:02:08 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: "Mukunda,Vijendar" <vijendar.mukunda@....com>,
Mark Brown <broonie@...nel.org>
Cc: "Limonciello, Mario" <mario.limonciello@....com>, vkoul@...nel.org,
alsa-devel@...a-project.org, Mastan.Katragadda@....com,
Sunil-kumar.Dommati@....com, Basavaraj.Hiregoudar@....com,
Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
open list <linux-kernel@...r.kernel.org>,
Syed Saba Kareem <Syed.SabaKareem@....com>,
arungopal.kondaveeti@....com
Subject: Re: [PATCH 19/19] ASoC: amd: ps: increase runtime suspend delay
On 1/16/23 02:35, Mukunda,Vijendar wrote:
> On 14/01/23 01:27, Mark Brown wrote:
>> On Fri, Jan 13, 2023 at 11:33:09AM -0600, Pierre-Louis Bossart wrote:
>>
>>> I do recall some issues with the codec jacks, where if the card
>>> registration happens too late the codec might have suspended. But we
>>> added pm_runtime_resume_and_get in the set_jack_detect callbacks, so
>>> that was solved.
>> Right, I would expect that whatever needs the device to be powered on
>> would be explicitly ensuring that this is done rather than tweaking
>> timeouts - the timeouts should be more of a performance thing to avoid
>> bouncing power too much, not a correctness thing.
> Machine driver probe is executed in parallel with Manager driver
> probe sequence. Because of it, before completion of all peripherals
> enumeration across the multiple links, if card registration is
> completed, codec register writes will fail as Codec device numbers
> are not assigned.
>
> If we understood correctly, as per your suggestion, We shouldn't use any
> time bounds in machine driver probe sequence and before registering the
> sound card, need to traverses through all peripheral initialization completion
> status for all the managers.
What's not clear in your reply is this:
What codec registers are accessed as a result of the machine driver
probe and card registration, and in what part of the card registration?
Are we talking about SoundWire 'standard' registers for device/port
management, about vendor specific ones that are exposed to userspace, or
vendor-specific ones entirely configured by the driver/regmap.
You've got to give us more data or understanding of the sequence to
help. Saying there's a race condition doesn't really help if there's
nothing that explains what codec registers are accessed and when.
Powered by blists - more mailing lists