Hi Jerome,
On Mon, Oct 4, 2021 at 11:02 AM Jerome Brunet jbrunet@baylibre.com wrote: [...]
old 32-bit u-boot sources from the Endless Mini do have some documentation on AIU_I2S_SYNC [0]: // 8'b0_000_1_1_10 // A write to this register will cause the interface to repeat the current // sample. Can be used to regain synchronization. // A read from this register indicates that the next sample to be sent // out of the interface should go into the _left_ channel of the dac.
There's also a note about AIU_I2S_MISC stating: // Bit 4 if true, force each audio data to left or right according to the bit attached with the audio data // This bit should be used with Register AIU_i2s_sync(0x511) together
To be honest: to me this is not helpful since I don't understand how/why the left channel is of importance.
Same here, I already had this description and it is not really that helpful.
OK, so I guess this leaves experimenting (which requires luck)... :-(
[...]
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.
So to me this means that there's three different muxes:
- data mux to choose between 0x0 (all zeros), 0x1 (PCM) and 0x2 (I2S)
- clock mux to choose between 0x0 (disabled), 0x1 (PCM) and 0x2
(hdmi_tx_audio_master_clk)
- hdmi_tx_audio_master_clk clock mux to choose between 0x0 (cts_i958)
and 0x1 (cts_aoclkx2_int)
Based on that I think that it's not possible to have AIU output the I2S and SPDIF signals at the same time to the HDMI TX controller and then letting the HDMI TX controller choose which one to use.
i2s and spdif can be 2 independent paths (with different clock sources). I have already made them work concurrently. I believe (but have no proof) that the same should be possible with the HDMI.
Until the hdmi controller has support for both inputs, we don't need to worry about it.
My work-in-progress HDMI TX controller driver for the 32-bit SoCs [0] does support both (I2S and SPDIF) inputs. That's how I am able to test all of this. I wasn't aware of the fact that it's known that the "machine gun noise" (MGN) issue is related to I2S only. Since I couldn't find a workaround or fix for the MGN issue I wanted to narrow it down by adding SPDIF support to the HDMI TX path.
Based on whichever signal (I2S or SPDIF) we want to use for HDMI we need to configure AIU accordingly (data and clock).
TBH, I'm not really sure what this bit does. From the description, it seems it allows to select an HDMI clock (not idea which one actually) for either the i2s or the spdif path.
Nothing says it is related to the HDMI_CTRL (codec), maybe it is not. Maybe (MAYBE) it defines what will become "the AIU clk" in AIU_HDMI_CLK_DATA_CTRL[1:0].
This is what I am thinking
Until we can feed the i2s encoder from the spdif FIFO, I'm not sure we need to play with it.
I think it's also relevant when we feed HDMI TX from the SPDIF (FIFO + encoder) which is what I am attempting here.
[...]
It is not meant to. The dai_link and the endpoint are i2s. Your HDMI controller should have 2 inputs and should have a way to select one or the other. The format at each of the (internal) input does not change
ah, that makes sense. Let's say AIU has some internal muxing for the HDMI output then AIU would have two outputs as well (let's call them HDMI_OUT_I2S and HDMI_OUT_SPDIF).
I don't think there is another output the HDMI_CTRL mux block. If SPDIF to HDMITX is supported, I suspect the output of the spdif encoder is hardwired to the spdif input of the HDMI controller and it is up to the HDMI controller to take it or not.
I think you are correct with this. My theory is that AIU_CLK_CTRL_MORE[6] and AIU_HDMI_CLK_DATA_CTRL will enable one of the outputs (I2S or SPIDF) from AIU to the HDMI TX controller, meaning that only one signal can be active at a time. The HDMI TX controller then needs to "select" the correct input based on the selected output from AIU.
That being said, I don't see any hard evidence that AML used SPDIF to HDMI in their tree, so maybe it does not work at all.
For the 32-bit SoCs the easiest to understand code-snippet is the HDMI TX audio input configuration [1] Which basically translates to: if (more_than_two_channel_audio) { enable_audio_i2s(); } else { enable_audio_spdif(); }
The code in the AIU driver just assumes that whatever it's configuring is what the HDMI TX driver expects - without a clear link between these two.
Best regards, Martin
[0] https://github.com/xdarklight/linux/blob/meson-mx-integration-5.15-20211003/... [1] https://github.com/endlessm/linux-meson/blob/d6e13c220931110fe676ede6da69fc6...