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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 24 Feb 2023 10:56:22 +0000
From:   Chancel Liu <chancel.liu@....com>
To:     Mark Brown <broonie@...nel.org>
CC:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "ckeepax@...nsource.cirrus.com" <ckeepax@...nsource.cirrus.com>,
        "patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: Re: [PATCH 2/4] ASoC: dt-bindings: wlf,wm8524: Add a property to
 specify power up sequency time

> On Wed, Feb 22, 2023 at 07:39:43PM +0800, Chancel Liu wrote:
> > This property specifies power up to audio out time. It's necessary
> > beacause this device has to wait some time before ready to output
> > audio after MCLK, BCLK and MUTE=1 are enabled. For more details about
> > the timing constraints, please refer to WTN0302 on
> > https://www.cirrus.com/products/wm8524/
> 
> According to that the delay is a property of MCLK and the sample rate rather
> than a per board constant, it shouldn't be in DT but rather the driver should
> figure out the required delay on each startup.

I can't agree with you more. From the power up to audio out timing table in
WTN0302, the delay depends on sample rate and MCLK. Driver should calculate it
rather than read it from DT. However as I mentioned in my last email, values in
the table seem not accurate for all systems. It's a kind of compromise to get
the value from DT. Do other codecs have a similar situation?

Thank you very much for your suggestions!

Regards, 
Chancel Liu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ