Hi Jerome,

On Mon, Oct 4, 2021 at 11:17 PM Martin Blumenstingl
[off-list ref] wrote:
[...]

quoted

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