Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Lu, Brent" <brent.lu@intel.com>
To:     Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
CC:     Support Opensource <Support.Opensource@diasemi.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] ASoC: da7219: remove SRM lock check retry
Thread-Topic: [PATCH] ASoC: da7219: remove SRM lock check retry
Thread-Index: AQHVqaw+ii/fH1J6I0CEgpyDBLMztaeno36AgACHg7D//4yFAIAAv3yg//+DfwCAAIgLEA==
Date:   Tue, 3 Dec 2019 15:23:03 +0000
Message-ID: <CF33C36214C39B4496568E5578BE70C7403CAFAE@PGSMSX108.gar.corp.intel.com>
References: <1575358265-17905-1-git-send-email-brent.lu@intel.com>
 <AM5PR1001MB0994EB497D3BC7D0F4C6FD9080420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
 <CF33C36214C39B4496568E5578BE70C7403CA7B2@PGSMSX108.gar.corp.intel.com>
 <AM5PR1001MB09946C295B8DAD5F9C8D191080420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
 <CF33C36214C39B4496568E5578BE70C7403CACC7@PGSMSX108.gar.corp.intel.com>
 <AM5PR1001MB0994921AE80726BAC59C552B80420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AM5PR1001MB0994921AE80726BAC59C552B80420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> 
> 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);


Regards,
Brent