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: <CAFBinCCAAZHqrKHyfwHPqk9Ki9nDeGFFQfj34ZF58wj+6AjH-g@mail.gmail.com>
Date: Mon, 6 Jan 2025 13:49:44 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Jerome Brunet <jbrunet@...libre.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

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).
With the attached patch I now see hdmi-codec's .prepare callback being called:
$ 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

View attachment "soc-damp-call-prepare.diff" of type "text/x-patch" (1681 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ