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@xxxxxxxxxxx>
Signed-off-by: Sameer Pujar <spujar@xxxxxxxxxx>
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
