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