[1/3] dt-bindings: soc: imx: add fdcc clock to i.MX8MP hdmi blk ctrl
Commit Message
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>
Comments
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
>
@@ -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>;