On 03 December 2019 14:36, Brent Lu wrote: > > But on platforms where they can enable the WCLK early they shouldn't be > > looping around here for anything like 400ms. In an ideal world when that > > widget is run SRM should hopefully be already locked but the code does > > allow for some delay. Actually, having a long delay also helps show the user > > that something isn't right here so I'm somewhat loathed to change this. > > > > Even if you do reduce the retry timings what you're still not protecting > > against is the possibility of audio artefacts when SRM finally locks. You want > > this to lock before the any of the audio path is up so I think we need to find a > > way to resolve that rather than relying on getting lucky with a smooth power- > > up. > > > Hi Adam, > > Thanks for the explanation. So the purpose of the code is providing some > timing tolerance for SRM to lock? If so, I would suggest adding warning message > for the lock fail so people have a clue if their design fails the CTS test. Hard to say > if Google further reduces the Cold latency again in the future. Yes, that's right. I have put in a request with our HW team to again clarify timings, but still awaiting feedback. The driver already warns via the kernel logs when SRM lock fails as follows: dev_warn(component->dev, "SRM failed to lock\n"); What else do you think is needed? > > > Regards, > Brent _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
