lkml.org 
[lkml]   [2019]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] ASoC: da7219: remove SRM lock check retry
Date
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

\
 
 \ /
  Last update: 2019-12-03 18:16    [W:0.047 / U:10.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site