Hello,
This thread is about enabling HDMI audio output for all possible video modes on an i.MX6 SoC. While this is not officially supported by NXP in their BSP releases, the drivers can be modified to force audio output regardless of video mode.
I am interested to know:
- have others tried doing forcing audio output for non-CEA modes?
- what problems did you encounter, if any?
i.MX6 SoCs support a large number of video modes, including non-CEA modes such as those specified in the VESA DMT specification. However, official NXP kernels (up to and including 4.14.98) and their MXC HDMI drivers only support CEA modes out-of-the box. Patches are floating around on the web to enable video support for non-CEA modes, such as this one from Boundary Devices, but one common deficit is that audio support is not enabled.
It is stated in the i.MX6DP/QP reference manual, section 33.4.6.1 CTS Calculation:
Because there is no audio clock carried through the HDMI link, only the pixel clock is used.
The CTS/N has to be set by software with value taken in the following table. Table [33-4] below shows the CTS and N value for the supported standard. All other TMDS clocks are not supported; the TMDS clocks divided or multiplied by 1,001 coefficients are not supported.
The CTS calculation is performed by hdmi_compute_cts() in mxc-hdmi-core.c, which does a lookup on the values in that table. If the (TMDS clock frequency, audio sample frequency) pair isn't present in the table, it returns 0 and the CTS is not configured in the HDMI TX.
The TMDS clock frequency values in that table are 25.2, 27, 54, 74.25, 148.5, and 297 MHz, and these cover pretty much all supported CEA modes. But many video modes have a different TMDS clock frequency, and for these cases the HDMI 1.4b specification gives a recommended N value (depending on the audio sample frequency), and a requirement that the CTS satisfy the equation: 128 * f_S = f_TMDS * N/CTS. So at least - in theory - one can solve for CTS and configure that value in the HDMI TX.
I tried doing this and had immediate success playing 48 kHz audio with many non-CEA video modes on my display. I also found that similar logic has been introduced into the mainline driver for the DesignWare HDMI Controller used by the i.MX6 family: drm: bridge/dw_hdmi: replace CTS calculation for the ACR. So it seems that the constraint described in the NXP reference manual is perhaps overly conservative?
For what it's worth, I have noticed that the same language is used in the DesignWare HDMI Transmitter Controller Databook, so I don't expect NXP to give some deep insight into this documented constraint of third party IP. (Maybe it was simply never tested for this use-case.) I'm rather interested to know how important it is to stick to this advice, and in what scenarios might the audio output not work if it is forced?
In our case we have a device for education/business use, and it's important to know to what extent we can enable audio by default. If non-CEA audio causes white noise/garbled output in many cases, then it would be good to know.
I'll be glad to hear about others' experience with this issue.
Kind regards,
Alvin
