linux-kernel - Re: meson-aiu: HDMI codec .prepare() callback not called

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]

Message-ID: <1j4j2caxds.fsf@starbuckisacylon.baylibre.com>
Date: Mon, 06 Jan 2025 14:24:15 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: linux-amlogic@...ts.infradead.org,  linux-sound@...r.kernel.org,
  linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org,
  dmitry.baryshkov@...aro.org
Subject: Re: meson-aiu: HDMI codec .prepare() callback not called

On Mon 06 Jan 2025 at 13:49, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:

> Hi Jerome,
>
> On Mon, Jan 6, 2025 at 11:44 AM Jerome Brunet <jbrunet@...libre.com> wrote:
> [...]
>> > I have further verified that the gx-card parsing does find the HDMi
>> > controller and links it correctly.
>> > To me it's odd that only the .prepare() callback is not called, all
>> > others (as mentioned above: .hw_params, .startup, ...) are working
>> > fine.
>>
>> I think the problem you are seeing comes from the quirk of
>> codec-to-codec links. The hdmi codec link is such a link on Amlogic
>> because further digital routing is required after the backend.
>>
>> Those type of links are not used much beside some
>> CPU offloading on Samsung and Amlogic, as far as I know.
>> It is possible, even likely, that things are still missing there.
>>
>> So those C2C links are operated by the DAPM events, not the regualar
>> ASoC code. You can start here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-dapm.c#n3995
> Thank you - that is indeed the root cause!
>
>> You'll see that .prepare() is not called, same as .trigger()
>> That should propably be fixed :/
> Since I'm still very much clueless about all of this I just came up
> with an experimental patch. Any feedback on it is welcome (I can send
> it as RFC patch - but prepare for me needing support).

It is probably a good idea to send it to get more feedback, yes.

> With the attached patch I now see hdmi-codec's .prepare callback being called:

Looks like a good start :)

Couples of nitpicks:

You might want to check the stream validity in
the function you've introduced, like in soc_dai_trigger()

It may also be nice to update snd_soc_pcm_dai_prepare() with the
introduced function.

> $ speaker-test -c2
>
> speaker-test 1.2.13
>
> Playback device is default
> Stream parameters are 48000Hz, S16_LE, 2 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 128 to 262144
> Period size range from 64 to 131072
> Periods = 4
> [   42.043413] hdmi-audio-codec hdmi-audio-codec.0.auto:
> hdmi_codec_hw_params() width 16 rate 48000 channels 2
> [   42.047916] hdmi-audio-codec hdmi-audio-codec.0.auto:
> hdmi_codec_prepare() width 16 rate 48000 channels 2
>
>
>
> Best regards,
> Martin
>
> [2. text/x-patch; soc-damp-call-prepare.diff]...

-- 
Jerome