There are a few clocks whose parents are set in mipi_dsi
and mxsfb nodes, but these clocks are used by the disp_blk_ctrl
power domain which may cause an issue when re-parenting, resuling
in a disp_pixel clock having the wrong parent and wrong rate.
Fix this by moving the assigned-clock-parents as associate clock
assignments to the power-domain node to setup these clocks before
they are enabled.
Fixes: d825fb6455d5 ("arm64: dts: imx8mn: Add display pipeline components")
Signed-off-by: Adam Ford <[email protected]>
---
V2: Split this into a separate patch away from a series of DSIM changes.
No actual changes made to the patch.
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index bd84db550053..8be8f090e8b8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -1069,13 +1069,6 @@ lcdif: lcdif@32e00000 {
<&clk IMX8MN_CLK_DISP_APB_ROOT>,
<&clk IMX8MN_CLK_DISP_AXI_ROOT>;
clock-names = "pix", "axi", "disp_axi";
- assigned-clocks = <&clk IMX8MN_CLK_DISP_PIXEL_ROOT>,
- <&clk IMX8MN_CLK_DISP_AXI>,
- <&clk IMX8MN_CLK_DISP_APB>;
- assigned-clock-parents = <&clk IMX8MN_CLK_DISP_PIXEL>,
- <&clk IMX8MN_SYS_PLL2_1000M>,
- <&clk IMX8MN_SYS_PLL1_800M>;
- assigned-clock-rates = <594000000>, <500000000>, <200000000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_LCDIF>;
status = "disabled";
@@ -1093,12 +1086,6 @@ mipi_dsi: dsi@32e10000 {
clocks = <&clk IMX8MN_CLK_DSI_CORE>,
<&clk IMX8MN_CLK_DSI_PHY_REF>;
clock-names = "bus_clk", "sclk_mipi";
- assigned-clocks = <&clk IMX8MN_CLK_DSI_CORE>,
- <&clk IMX8MN_CLK_DSI_PHY_REF>;
- assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_266M>,
- <&clk IMX8MN_CLK_24M>;
- assigned-clock-rates = <266000000>, <24000000>;
- samsung,pll-clock-frequency = <24000000>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_MIPI_DSI>;
status = "disabled";
@@ -1142,6 +1129,21 @@ disp_blk_ctrl: blk-ctrl@32e28000 {
"lcdif-axi", "lcdif-apb", "lcdif-pix",
"dsi-pclk", "dsi-ref",
"csi-aclk", "csi-pclk";
+ assigned-clocks = <&clk IMX8MN_CLK_DSI_CORE>,
+ <&clk IMX8MN_CLK_DSI_PHY_REF>,
+ <&clk IMX8MN_CLK_DISP_PIXEL>,
+ <&clk IMX8MN_CLK_DISP_AXI>,
+ <&clk IMX8MN_CLK_DISP_APB>;
+ assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_266M>,
+ <&clk IMX8MN_CLK_24M>,
+ <&clk IMX8MN_VIDEO_PLL1_OUT>,
+ <&clk IMX8MN_SYS_PLL2_1000M>,
+ <&clk IMX8MN_SYS_PLL1_800M>;
+ assigned-clock-rates = <266000000>,
+ <24000000>,
+ <594000000>,
+ <500000000>,
+ <200000000>;
#power-domain-cells = <1>;
};
--
2.39.2
On Sun, Apr 23, 2023 at 7:35 AM Adam Ford <[email protected]> wrote:
>
> There are a few clocks whose parents are set in mipi_dsi
> and mxsfb nodes, but these clocks are used by the disp_blk_ctrl
> power domain which may cause an issue when re-parenting, resuling
> in a disp_pixel clock having the wrong parent and wrong rate.
>
> Fix this by moving the assigned-clock-parents as associate clock
> assignments to the power-domain node to setup these clocks before
> they are enabled.
>
> Fixes: d825fb6455d5 ("arm64: dts: imx8mn: Add display pipeline components")
> Signed-off-by: Adam Ford <[email protected]>
Shawn,
Any chance this can get applied? Without it, the 8MN video doesn't
have correct parents and therefore the wrong clock rates too.
adam
> ---
> V2: Split this into a separate patch away from a series of DSIM changes.
> No actual changes made to the patch.
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> index bd84db550053..8be8f090e8b8 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> @@ -1069,13 +1069,6 @@ lcdif: lcdif@32e00000 {
> <&clk IMX8MN_CLK_DISP_APB_ROOT>,
> <&clk IMX8MN_CLK_DISP_AXI_ROOT>;
> clock-names = "pix", "axi", "disp_axi";
> - assigned-clocks = <&clk IMX8MN_CLK_DISP_PIXEL_ROOT>,
> - <&clk IMX8MN_CLK_DISP_AXI>,
> - <&clk IMX8MN_CLK_DISP_APB>;
> - assigned-clock-parents = <&clk IMX8MN_CLK_DISP_PIXEL>,
> - <&clk IMX8MN_SYS_PLL2_1000M>,
> - <&clk IMX8MN_SYS_PLL1_800M>;
> - assigned-clock-rates = <594000000>, <500000000>, <200000000>;
> interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_LCDIF>;
> status = "disabled";
> @@ -1093,12 +1086,6 @@ mipi_dsi: dsi@32e10000 {
> clocks = <&clk IMX8MN_CLK_DSI_CORE>,
> <&clk IMX8MN_CLK_DSI_PHY_REF>;
> clock-names = "bus_clk", "sclk_mipi";
> - assigned-clocks = <&clk IMX8MN_CLK_DSI_CORE>,
> - <&clk IMX8MN_CLK_DSI_PHY_REF>;
> - assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_266M>,
> - <&clk IMX8MN_CLK_24M>;
> - assigned-clock-rates = <266000000>, <24000000>;
> - samsung,pll-clock-frequency = <24000000>;
> interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_MIPI_DSI>;
> status = "disabled";
> @@ -1142,6 +1129,21 @@ disp_blk_ctrl: blk-ctrl@32e28000 {
> "lcdif-axi", "lcdif-apb", "lcdif-pix",
> "dsi-pclk", "dsi-ref",
> "csi-aclk", "csi-pclk";
> + assigned-clocks = <&clk IMX8MN_CLK_DSI_CORE>,
> + <&clk IMX8MN_CLK_DSI_PHY_REF>,
> + <&clk IMX8MN_CLK_DISP_PIXEL>,
> + <&clk IMX8MN_CLK_DISP_AXI>,
> + <&clk IMX8MN_CLK_DISP_APB>;
> + assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_266M>,
> + <&clk IMX8MN_CLK_24M>,
> + <&clk IMX8MN_VIDEO_PLL1_OUT>,
> + <&clk IMX8MN_SYS_PLL2_1000M>,
> + <&clk IMX8MN_SYS_PLL1_800M>;
> + assigned-clock-rates = <266000000>,
> + <24000000>,
> + <594000000>,
> + <500000000>,
> + <200000000>;
> #power-domain-cells = <1>;
> };
>
> --
> 2.39.2
>
On Sun, Apr 23, 2023 at 07:35:13AM -0500, Adam Ford wrote:
> There are a few clocks whose parents are set in mipi_dsi
> and mxsfb nodes, but these clocks are used by the disp_blk_ctrl
> power domain which may cause an issue when re-parenting, resuling
> in a disp_pixel clock having the wrong parent and wrong rate.
>
> Fix this by moving the assigned-clock-parents as associate clock
> assignments to the power-domain node to setup these clocks before
> they are enabled.
>
> Fixes: d825fb6455d5 ("arm64: dts: imx8mn: Add display pipeline components")
> Signed-off-by: Adam Ford <[email protected]>
Is it a fix for v6.4-rc or material for -next?
Shawn
On Sat, May 13, 2023 at 10:58 PM Shawn Guo <[email protected]> wrote:
>
> On Sun, Apr 23, 2023 at 07:35:13AM -0500, Adam Ford wrote:
> > There are a few clocks whose parents are set in mipi_dsi
> > and mxsfb nodes, but these clocks are used by the disp_blk_ctrl
> > power domain which may cause an issue when re-parenting, resuling
> > in a disp_pixel clock having the wrong parent and wrong rate.
> >
> > Fix this by moving the assigned-clock-parents as associate clock
> > assignments to the power-domain node to setup these clocks before
> > they are enabled.
> >
> > Fixes: d825fb6455d5 ("arm64: dts: imx8mn: Add display pipeline components")
> > Signed-off-by: Adam Ford <[email protected]>
>
> Is it a fix for v6.4-rc or material for -next?
The Samsung DSI driver for Nano is in 6.4, and an attempt was made to
setup the device tree in 6.4. While I don't think there are users of
this yet, if people try to add DT entries in their boards, they might
struggle getting the video working if this isn't applied since the
disp1_pix clock may be stuck at 24MHz which likely won't sync much if
any displays.
adam
>
> Shawn
On Sat, May 13, 2023 at 11:23:04PM -0500, Adam Ford wrote:
> On Sat, May 13, 2023 at 10:58 PM Shawn Guo <[email protected]> wrote:
> >
> > On Sun, Apr 23, 2023 at 07:35:13AM -0500, Adam Ford wrote:
> > > There are a few clocks whose parents are set in mipi_dsi
> > > and mxsfb nodes, but these clocks are used by the disp_blk_ctrl
> > > power domain which may cause an issue when re-parenting, resuling
> > > in a disp_pixel clock having the wrong parent and wrong rate.
> > >
> > > Fix this by moving the assigned-clock-parents as associate clock
> > > assignments to the power-domain node to setup these clocks before
> > > they are enabled.
> > >
> > > Fixes: d825fb6455d5 ("arm64: dts: imx8mn: Add display pipeline components")
> > > Signed-off-by: Adam Ford <[email protected]>
> >
> > Is it a fix for v6.4-rc or material for -next?
>
> The Samsung DSI driver for Nano is in 6.4, and an attempt was made to
> setup the device tree in 6.4. While I don't think there are users of
> this yet, if people try to add DT entries in their boards, they might
> struggle getting the video working if this isn't applied since the
> disp1_pix clock may be stuck at 24MHz which likely won't sync much if
> any displays.
Ok, applied for v6.4-rc, thanks!