On 1/17/23 05:33, Mukunda,Vijendar wrote: > On 16/01/23 20:32, Pierre-Louis Bossart wrote: >> >> 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. > We have come across a race condition, where sound card registration > is successful before codec enumerations across all the links gets completed > and our manager instance going into bad state. > > Please refer below link for error logs. > https://pastebin.com/ZYEN928S You have two RT1316 register areas that are accessed while the codec is not even enumerated: [ 2.755828] rt1316-sdca sdw:0:025d:1316:01:0: ASoC: error at snd_soc_component_update_bits on sdw:0:025d:1316:01:0 for register: [0x41080100] -22 [ 2.758904] rt1316-sdca sdw:0:025d:1316:01:0: ASoC: error at snd_soc_component_update_bits on sdw:0:025d:1316:01:0 for register: [0x00003004] -110 The last one is clearly listed in the regmap list. You probably want to reverse-engineer what causes these accesses. I see this suspicious kcontrol definition that might be related: SOC_SINGLE("Left I Tag Select", 0x3004, 4, 7, 0),
