Messages in this thread | | | From | Adam Thomson <> | Subject | RE: [PATCH] ASoC: da7219: remove SRM lock check retry | Date | Tue, 3 Dec 2019 17:15:25 +0000 |
| |
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
| |