Hi Jerome, On Mon, Oct 4, 2021 at 11:02 AM Jerome Brunet <jbrunet@xxxxxxxxxxxx> 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/drivers/gpu/drm/bridge/transwitch/txccq-txc-48352.c [1] https://github.com/endlessm/linux-meson/blob/d6e13c220931110fe676ede6da69fc61a7cb04b6/arch/arm/mach-meson8/hdmi_tx_hw/hdmi_tx_hw.c#L3035:L3038