linux-kernel - Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock

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:   Tue, 09 Mar 2021 23:30:16 +0100
From:   Michael Walle <michael@...le.cc>
To:     Sameer Pujar <spujar@...dia.com>
Cc:     alsa-devel@...a-project.org, broonie@...nel.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

Hi Sameer,

Am 2021-03-09 17:27, schrieb Sameer Pujar:
> On 3/9/2021 8:11 PM, Michael Walle wrote:
>>> If "clocks = <&xxx>" is specified from the CPU or Codec component
>>> device node, the clock is not getting enabled. Thus audio playback
>>> or capture fails.
>>> 
>>> Fix this by populating "simple_dai->clk" field when clocks property
>>> is specified from device node as well. Also tidy up by re-organising
>>> conditional statements of parsing logic.
>>> 
>>> Fixes: bb6fc620c2ed ("ASoC: simple-card-utils: add 
>>> asoc_simple_card_parse_clk()")
>>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
>>> Signed-off-by: Sameer Pujar <spujar@...dia.com>
>> 
>> This actually breaks sound on my board
>> (arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts).
>> The codec on this board (wm8904) has a fixed clock input (only 
>> distinct
>> frequencies are supported) and uses the FLL of the codec to generate 
>> the
>> desired sample rate.
>> 
>> It seems that after this patch the clock rate of the codecs clock 
>> (rather
>> than the FLL) is tried to be changed. Which fails, because it doesn't
>> support arbitrary frequencies.
> 
> Yes, after the given change the clock will be updated if "*mclk-fs"
> property is specified.
> 
> DT you mentioned has property "simple-audio-card,mclk-fs = <256>",
> which means you need a clock that is a function of sample rate. But as
> per above you want a fixed clock for MCLK. I think if you drop this
> property, the clock updates won't happen. Earlier for your case, this
> property was not used at all because the clock handle was not
> populated.

You mean to drop the mclk-fs property? I can't do that because I
actually need a frequency of 256 * sample rate. But that doesn't
necessarily need to be the MCLK, because the codec itself has a
FLL/PLL which can be used to generate any frequency for a given
MCLK. So that is a valid scenario. See also commit 13409d27cb39
("ASoC: wm8904: configure sysclk/FLL automatically").

-michael