Message ID | 20240106223951.387067-1-aford173@gmail.com (mailing list archive) |
---|---|
State | Handled Elsewhere, archived |
Headers | show |
Series | [1/3] dt-bindings: soc: imx: add fdcc clock to i.MX8MP hdmi blk ctrl | expand |
On 06/01/2024 23:39, Adam Ford wrote: > Per guidance from the NXP downstream kernel, if the clock is > disabled before HDMI/LCDIF probe, LCDIF will not get pixel > clock from HDMI PHY and throw an error. Fix this by adding > the fdcc clock to the hdmi_blk_ctrl. > Adding a required clock is ABI break and commit msg is not clear whether this was actually necessary or how did it worked so far... Best regards, Krzysztof
On Sun, Jan 7, 2024 at 4:53 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 06/01/2024 23:39, Adam Ford wrote: > > Per guidance from the NXP downstream kernel, if the clock is > > disabled before HDMI/LCDIF probe, LCDIF will not get pixel > > clock from HDMI PHY and throw an error. Fix this by adding > > the fdcc clock to the hdmi_blk_ctrl. > > > > Adding a required clock is ABI break and commit msg is not clear whether > this was actually necessary or how did it worked so far... As of right now, this power domain isn't enabled in the device tree. This power domain is necessary for the HDMI driver which is split across several drivers which Lucas attempted to push but got some feedback. One of those items in question is the enabling of FDCC during the HDMI Tx probe. The NXP documentation is vague on what this clock is and who uses it. When I did my investigation into how NXP used it, it turned out they didn't use it in the HDMI TX driver, because they moved it to the power domain and referenced it from both the LCDIF and the HDMI TX. NXP's downstream commit didn't get into a lot of detail on how to reproduce the error, but it sounded like some sort of order of operations issue between the LCDIF and HDMI TX. Moving this to the power domain appeared to solve the issue for them, and it seemed like it would have also resolved the concern about its use in the HDMI TX driver that was submitted on the mailing list. In the subsequent patch, I listed the error that NXP described, but I can re-do this commit message to make it more clear if you let me know what you're wanting to see. adam > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml index 1be4ce2a45e8..741b5d8da4bb 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml @@ -42,8 +42,8 @@ properties: - const: hdmi-tx-phy clocks: - minItems: 4 - maxItems: 4 + minItems: 5 + maxItems: 5 clock-names: items: @@ -51,6 +51,7 @@ properties: - const: axi - const: ref_266m - const: ref_24m + - const: fdcc interconnects: maxItems: 3 @@ -82,8 +83,9 @@ examples: clocks = <&clk IMX8MP_CLK_HDMI_APB>, <&clk IMX8MP_CLK_HDMI_ROOT>, <&clk IMX8MP_CLK_HDMI_REF_266M>, - <&clk IMX8MP_CLK_HDMI_24M>; - clock-names = "apb", "axi", "ref_266m", "ref_24m"; + <&clk IMX8MP_CLK_HDMI_24M>, + <&clk IMX8MP_CLK_HDMI_FDCC_TST>; + clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc"; power-domains = <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmi_phy>;
Per guidance from the NXP downstream kernel, if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and throw an error. Fix this by adding the fdcc clock to the hdmi_blk_ctrl. Signed-off-by: Adam Ford <aford173@gmail.com>