> > Am not going to make myself popular here. It's MCLK and FSYNC (or WCLK as > it's termed for our device) that is required for SRM to lock in the PLL. > > So far I've not found a way in the codec driver to be able to get around this. > I spent a very long time with Sathya in the early days (Apollo Lake) looking at > options but nothing would fit which is why I have the solution that's in place > right now. We could probably reduce the number of rechecks before > timeout in the driver but that's really just papering over the crack and there's > still the possibility of noise later when SRM finally does lock. Hi Adam, For Google CTS requirement (200ms cold output latency), we plan to upload a patch which reduces the recheck number to 4 and interval to 20ms so the total delay here would be 80ms for our platform. We think the time is still sufficient for other platforms to generate a stable WCLK and for the codec SRM to lock but still needs your confirmation. How do you think? Regards, Brent
