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.
