Hi Jerome,
On Mon, Oct 4, 2021 at 11:17 PM Martin Blumenstingl martin.blumenstingl@googlemail.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