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:   Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To:     "Lu, Brent" <brent.lu@intel.com>,
        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: AQHVqaxDP6cBrmECm0aX2T25rtDQx6eoJvjggAAPtwCAAAQYEIAAP/KAgAAFyUCAAAdBgIAAHw+Q
Date:   Tue, 3 Dec 2019 17:15:25 +0000
Message-ID: <AM5PR1001MB09946850D64829B34BDA89EB80420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.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>
 <CF33C36214C39B4496568E5578BE70C7403CAFAE@PGSMSX108.gar.corp.intel.com>
In-Reply-To: <CF33C36214C39B4496568E5578BE70C7403CAFAE@PGSMSX108.gar.corp.intel.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.225.80.228]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f0e68229-42ca-499e-6993-08d778146329
x-ms-traffictypediagnostic: AM5PR1001MB1203:
x-ms-exchange-sharedmailbox-routingagent-processed: True
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM5PR1001MB12035FDF116B8A7B52988B16A7420@AM5PR1001MB1203.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(396003)(346002)(136003)(366004)(39860400002)(199004)(189003)(7696005)(52536014)(76176011)(2501003)(11346002)(55016002)(229853002)(7736002)(66446008)(86362001)(305945005)(74316002)(2906002)(66946007)(5660300002)(6436002)(9686003)(64756008)(3846002)(66556008)(66476007)(6116002)(76116006)(25786009)(4326008)(6246003)(110136005)(33656002)(81166006)(8676002)(81156014)(186003)(478600001)(55236004)(71200400001)(446003)(8936002)(71190400001)(6506007)(53546011)(102836004)(99286004)(14444005)(256004)(26005)(316002)(14454004)(54906003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR1001MB1203;H:AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:0;MX:1;
received-spf: None (protection.outlook.com: diasemi.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MyCQiEW0nYPtH4VKwKDqIXBUhAqZy8rRzisK4aWjcyC3+9MOCFF0ih2U0VpY173cjcfNST0+B/MoaVSH/VdVCCM2+Az4S3p7WpL6uPvA8iG0uI/7VNCqpnqKvj+W766keLNgW3V1EH/vtzPqbS/99/VDvZAVUDMvVGECyFvy0YjYGM7pSVtVjadaUZbrcv3hngJAwKbzzNrZJvnWgEzmlGff7BvPzngH9ELm1BS3ejp+B4Qhbasy8ZqU0KBM2bVqRq69C5qGnz75FAemMUKi7y5TFRwwjCbYejrSEPjv65oZF8TlGa97hTdmagZOxf6JBYLyletkrDeY6K5OpWVY6+tYPSnk16xP63bSKZ84h/88kl6utYfSPhVm5acVScHzFmYfb7nIAc+U4FhaUy2ffvpXuOkcMYR8auZr98WMQP979igGlbDnAX13U0R+Vwn6
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: diasemi.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0e68229-42ca-499e-6993-08d778146329
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 17:15:25.3332
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 511e3c0e-ee96-486e-a2ec-e272ffa37b7c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IcpNPWgLX2IleRVSUAmIYSLh1OGBekVdfX11MYS0fpL0p7lyDVbXXh7ZEp3KKjvfz6ySXfndWH5mSgweLo1BmsY1VW0/6ebVC/Syxsfs1bA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR1001MB1203
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 cl=
arify
> > timings, but still awaiting feedback.
> >
> > The driver already warns via the kernel logs when SRM lock fails as fol=
lows:
> >
> > 	dev_warn(component->dev, "SRM failed to lock\n");
> >
> > What else do you think is needed?
> >
>=20
> Hi Adam,
>=20
> Let's say that the SRM locks in the second loop. The 50ms delay was appli=
ed
> 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 b=
efore
> msleep() call, it would be a helpful for people resolving timing issues l=
ike Cold
> latency.
>=20
> do {
> 	pll_status =3D 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 proba=
bly
dev_info() rather than dev_warn(). Also I'd suggest the debug message shoul=
d 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.

>=20
>=20
> Regards,
> Brent