On 03 December 2019 15:23, Brent Lu wrote:
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?
Hi Adam,
Let's say that the SRM locks in the second loop. The 50ms delay was applied but there is no kernel log message about it because the value of srm_lock is already true when exiting the loop. If we can print every SRM lock fail before msleep() call, it would be a helpful for people resolving timing issues like Cold latency.
do { pll_status = snd_soc_component_read32(component, DA7219_PLL_SRM_STS); if (pll_status & DA7219_PLL_SRM_STS_SRM_LOCK) { break; } else { ++i; dev_warn(component->dev, "SRM failed to lock, retry in 50ms\n"); msleep(50); } } while (i < DA7219_SRM_CHECK_RETRIES);
I have no real problem in providing debug like this, although this is probably dev_info() rather than dev_warn(). Also I'd suggest the debug message should be something like the following if we were to add anything here:
dev_info(component->dev, "Waiting for SRM lock\n");
Timings can be ascertained from the kernel log (assuming timestamping is on) so I don't think we need to explicitly state the delay information.
Regards, Brent