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:   Thu, 11 Mar 2021 23:11:15 +0100
From:   Michael Walle <michael@...le.cc>
To:     Mark Brown <broonie@...nel.org>
Cc:     Sameer Pujar <spujar@...dia.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, jonathanh@...dia.com,
        kuninori.morimoto.gx@...esas.com, linux-kernel@...r.kernel.org,
        linux-tegra@...r.kernel.org, robh@...nel.org, sharadg@...dia.com,
        thierry.reding@...il.com
Subject: Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock

Am 2021-03-11 17:15, schrieb Mark Brown:
> On Wed, Mar 10, 2021 at 08:20:28PM +0530, Sameer Pujar wrote:
> 
>> If I read this correctly below is the configuration you need,
>> SoC -> MCLK(fixed rate) -> PLL(wm8904) -> PLL output (256 * fs) -> 
>> sysclk
> 
> For this device for integration with something like simple-audio-card
> since there's limited flexibility within the device the simplest thing
> would be to not make the internal clocking of the device visible and
> just have it figure out how to use the input clock, using the MCLK
> directly if possible otherwise using the FLL to generate a suitable
> clock.

Before this patch, part of this was already happening. That is,
simple-audio-card called set_sysclk(samplerate * mclk-fs), then
the codec figured out that its mclk was different than the
requested sample rate and enabled its FLL to generate the requested
sample rate automatically.

With this patch applied, simple-audio-card already tries to change
mclk, which isn't working in my case (the MCLK isn't generated by
a PLL and just supports fixed frequencies) and thus breaks audio. And
this patch also propagate to the stable kernels and breaks my
board there, too.

> The trick is figuring out if it's best to vary the input clock
> or to use the FLL to adapt a fixed input clock,

For simple-audio-card you can set the "clock" property if you want
that clock to be changed/enabled/disabled. But that doesn't seem to
be the way to go, at least it was NAKed by Rob for the audio-graph-card.
I don't see a way to figure out if MCLK should be controlled by
simple-*-card without adding further properties to the device tree.

> and of course adapting any existing users if things get changed.

To be frank, I don't see that happening.

-michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ