linux-kernel - Re: [RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control questions and issues

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] [day] [month] [year] [list]

Message-ID: <CAFBinCBv0GWDUL+WYBU4JAgKgie07m+duxReh2tSopGOHwh4=Q@mail.gmail.com>
Date:   Tue, 5 Oct 2021 23:31:31 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Jerome Brunet <jbrunet@...libre.com>
Cc:     alsa-devel@...a-project.org, linux-amlogic@...ts.infradead.org,
        lgirdwood@...il.com, broonie@...nel.org, perex@...ex.cz,
        tiwai@...e.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control questions
 and issues

Hi Jerome,

On Mon, Oct 4, 2021 at 11:17 PM Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
[...]
> > This bit could also be a remain of an older design, not really connected
> > to anything meaningful. It would not be the first time.
> >
> > The AIU looks like an IP that has evolved a lot over the years, not always
> > in a coordinated fashion. Some scenario are well supported and easy,
> > others seem to require a magic spell.
> >
> > Last (but not least), in AML vendor kernel, the only time this bit poked
> > is around 8ch support (1 for 8ch, 0 otherwise) ... I have no idea why.
> The 32-bit SoCs use SPDIF to feed 2-channel audio to the HDMI TX
> controller and I2S to feed 8-channel audio to the HDMI TX controller.
> It seems that Amlogic stopped this for (at least some) 64-bit SoCs.
>
> My testing results indicate that AIU_CLK_CTRL_MORE[6] is still relevant.
> I can do another round of testing with various combinations of
> AIU_CLK_CTRL_MORE[6] and AIU_HDMI_CLK_DATA_CTRL register values.
> If you want me to test any specific combinations then please let me know.
I have tested various combinations, see the attached result file
(which can be viewed with "column -t /path/to/results.txt").
The short summary is that...
...I2S output requires:
  AIU_HDMI_CLK_DATA_CTRL[1:0] = 0x2
  AIU_HDMI_CLK_DATA_CTRL[5:4] = 0x2
  AIU_CLK_CTRL_MORE[6] = 0x1

...SPDIF output requires:
  AIU_HDMI_CLK_DATA_CTRL[1:0] = 0x2
  AIU_HDMI_CLK_DATA_CTRL[5:4] = (any)
  AIU_CLK_CTRL_MORE[6] = 0x1

My test consisted of running speaker-test -c2 and playing an mp3 with
ffplay on an Odroid-C1.

In other words: this confirms what we have suspected before.
What is your suggestion on how to model these muxes in the driver?

In the meantime I finally understood what #sound-dai-cells = <1>; does
thanks to your previous hints.
With that I can wire up the I2S and SPDIF inputs to the HDMI TX
controller's "HDMI codec".
Many thanks again for this hint!


Best regards,
Martin

View attachment "results.txt" of type "text/plain" (311 bytes)