linux-kernel - RE: [alsa-devel] [PATCH] ASoC: da7219: check SRM lock in trigger callback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AM6PR10MB2263A832CF4B0947091A0DB380100@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 19 Feb 2020 10:05:04 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     "Lu, Brent" <brent.lu@...el.com>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "Sridharan, Ranjani" <ranjani.sridharan@...el.com>
CC:     "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        Support Opensource <Support.Opensource@...semi.com>,
        Takashi Iwai <tiwai@...e.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Chiang, Mac" <mac.chiang@...el.com>,
        Mark Brown <broonie@...nel.org>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        "cychiang@...gle.com" <cychiang@...gle.com>
Subject: RE: [alsa-devel] [PATCH] ASoC: da7219: check SRM lock in trigger
 callback

On 19 February 2020 05:57, Lu, Brent wrote:

> > Am not going to make myself popular here. It's MCLK and FSYNC (or WCLK as
> > it's termed for our device) that is required for SRM to lock in the PLL.
> >
> > So far I've not found a way in the codec driver to be able to get around this.
> > I spent a very long time with Sathya in the early days (Apollo Lake) looking at
> > options but nothing would fit which is why I have the solution that's in place
> > right now. We could probably reduce the number of rechecks before
> > timeout in the driver but that's really just papering over the crack and there's
> > still the possibility of noise later when SRM finally does lock.
> 
> Hi Adam,
> 
> For Google CTS requirement (200ms cold output latency), we plan to upload a
> patch which reduces the recheck number to 4 and interval to 20ms so the total
> delay here would be 80ms for our platform. We think the time is still sufficient
> for other platforms to generate a stable WCLK and for the codec SRM to lock but
> still needs your confirmation. How do you think?

Hi Brent,

I'm concerned that just setting a timeout to suit the Google CTS requirement
isn't necessarily suitable for all targets, and this doesn't actually fix the
real problem here.

How long do you determine platforms will take to generate a stable WCLK? Do we
have an idea of how long that might be in a worst case scenario? If so then we
can look at adjusting this down, but I'd like to be clear.

> 
> 
> Regards,
> Brent