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/KAgAAFyUA=
Date:   Tue, 3 Dec 2019 14:57:28 +0000
Message-ID: <AM5PR1001MB0994921AE80726BAC59C552B80420@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>
In-Reply-To: <CF33C36214C39B4496568E5578BE70C7403CACC7@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: a5a5b641-087c-425c-0121-08d778011d90
x-ms-traffictypediagnostic: AM5PR1001MB1059:
x-ms-exchange-sharedmailbox-routingagent-processed: True
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM5PR1001MB10597048D192F07E65136892A7420@AM5PR1001MB1059.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(189003)(51914003)(199004)(33656002)(110136005)(71190400001)(71200400001)(52536014)(2906002)(305945005)(5660300002)(74316002)(81156014)(2501003)(8676002)(86362001)(7736002)(81166006)(8936002)(14454004)(99286004)(6246003)(54906003)(9686003)(446003)(26005)(102836004)(11346002)(498600001)(55236004)(186003)(55016002)(3846002)(7696005)(66446008)(66946007)(14444005)(229853002)(6506007)(6116002)(66556008)(76116006)(4326008)(64756008)(6436002)(256004)(25786009)(76176011)(53546011)(66476007);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR1001MB1059;H:AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:0;
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: Sb04F5h+iIQtMsJ7Wkgb0+dzHbZdonypPzM2rdlgxQKzokFblYumwZtBqHFHUadxHRYMtrr48RslroyhABDKuCmenvCbRexlLp6Z4nxiR2yNE7tGeCVSHmlAVcupoEf888lUITZ01JO7ygv5HUTli7hGQ6Qkia8qjFIiL1wVT9q+QTEl/8Mn4KMbV8KVRsIt1mrUi6Fh840V6lMy8zHX9vj1czUgcRnxVuyj/ZpjCgLHKmgeC5ixsA3kz5ZDanjrgcgBETAHWsiXNzvPUPqxqGewm7lolVFf6iegK50NftLAeT3wsmpwag5WhPe6J7H6NyPUVblivR6+qs0gF/mM/qCX6xPJh3lvzUXWhDaGwunTmkWeH4p1g6AL+1JqGrZf3Pn6CkyVc4Fsl8mv1Z7mF9l0/lhJkLSozp3yuBfR1MDPlm62q9Vg1Xt57oxlnceP
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: a5a5b641-087c-425c-0121-08d778011d90
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 14:57:28.1632
 (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: tle34gNxfG2kXneUzZtiECTMr1EwdBAk/gnfwZ4S+A3YcA++ftnGE7U/f9jUwzLu+z/f0nizcb+HnJQw2z7UGGZZXfm9Fur3+Fqm8gjot1U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR1001MB1059
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 14:36, Brent Lu wrote:

> > But on platforms where they can enable the WCLK early they shouldn't be
> > looping around here for anything like 400ms. In an ideal world when tha=
t
> > widget is run SRM should hopefully be already locked but the code does
> > allow for some delay. Actually, having a long delay also helps show the=
 user
> > that something isn't right here so I'm somewhat loathed to change this.
> >
> > Even if you do reduce the retry timings what you're still not protectin=
g
> > against is the possibility of audio artefacts when SRM finally locks. Y=
ou want
> > this to lock before the any of the audio path is up so I think we need =
to find a
> > way to resolve that rather than relying on getting lucky with a smooth =
power-
> > up.
> >
> Hi Adam,
>=20
> Thanks for the explanation. So the purpose of the code is providing some
> timing tolerance for SRM to lock? If so, I would suggest adding warning m=
essage
> for the lock fail so people have a clue if their design fails the CTS tes=
t. Hard to say
> if Google further reduces the Cold latency again in the future.

Yes, that's right. I have put in a request with our HW team to again clarif=
y
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?

>=20
>=20
> Regards,
> Brent