* [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
@ 2024-05-31 20:27 Marek Vasut
2024-06-24 9:19 ` Alexander Stein
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-05-31 20:27 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Daniel Vetter, David Airlie, Fabio Estevam,
Lucas Stach, Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
In case an upstream bridge modified the required clock frequency
in its .atomic_check callback by setting adjusted_mode.clock ,
make sure that clock frequency is generated by the LCDIFv3 block.
This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
with (e)DP output, where the TC358767 expects precise timing on
its input side, the precise timing must be generated by the LCDIF.
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Lukas F. Hartmann <lukas@mntmn.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org
Cc: imx@lists.linux.dev
Cc: kernel@dh-electronics.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 2541d2de4e45f..dbd42cc1da87f 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -407,8 +407,7 @@ static void lcdif_crtc_mode_set_nofb(struct drm_crtc_state *crtc_state,
struct drm_display_mode *m = &crtc_state->adjusted_mode;
DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
- m->crtc_clock,
- (int)(clk_get_rate(lcdif->clk) / 1000));
+ m->clock, (int)(clk_get_rate(lcdif->clk) / 1000));
DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n",
lcdif_crtc_state->bus_flags);
DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
@@ -538,7 +537,7 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_device *drm = lcdif->drm;
dma_addr_t paddr;
- clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
+ clk_set_rate(lcdif->clk, m->clock * 1000);
pm_runtime_get_sync(drm->dev);
--
2.43.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-05-31 20:27 [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock Marek Vasut
@ 2024-06-24 9:19 ` Alexander Stein
2024-07-06 0:16 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Alexander Stein @ 2024-06-24 9:19 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Daniel Vetter, David Airlie, Fabio Estevam,
Lucas Stach, Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, Marek Vasut
Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
> In case an upstream bridge modified the required clock frequency
> in its .atomic_check callback by setting adjusted_mode.clock ,
> make sure that clock frequency is generated by the LCDIFv3 block.
>
> This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
> with (e)DP output, where the TC358767 expects precise timing on
> its input side, the precise timing must be generated by the LCDIF.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
With the other rc358767 patches in place, this does the trick.
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Lukas F. Hartmann <lukas@mntmn.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: kernel@dh-electronics.com
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index 2541d2de4e45f..dbd42cc1da87f 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -407,8 +407,7 @@ static void lcdif_crtc_mode_set_nofb(struct drm_crtc_state *crtc_state,
> struct drm_display_mode *m = &crtc_state->adjusted_mode;
>
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
> - m->crtc_clock,
> - (int)(clk_get_rate(lcdif->clk) / 1000));
> + m->clock, (int)(clk_get_rate(lcdif->clk) / 1000));
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n",
> lcdif_crtc_state->bus_flags);
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
> @@ -538,7 +537,7 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_device *drm = lcdif->drm;
> dma_addr_t paddr;
>
> - clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
> + clk_set_rate(lcdif->clk, m->clock * 1000);
>
> pm_runtime_get_sync(drm->dev);
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-06-24 9:19 ` Alexander Stein
@ 2024-07-06 0:16 ` Marek Vasut
2024-10-07 17:01 ` Isaac Scott
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-07-06 0:16 UTC (permalink / raw)
To: Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
On 6/24/24 11:19 AM, Alexander Stein wrote:
> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
>> In case an upstream bridge modified the required clock frequency
>> in its .atomic_check callback by setting adjusted_mode.clock ,
>> make sure that clock frequency is generated by the LCDIFv3 block.
>>
>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
>> with (e)DP output, where the TC358767 expects precise timing on
>> its input side, the precise timing must be generated by the LCDIF.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>
> With the other rc358767 patches in place, this does the trick.
> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
I'll pick this up next week if there is no objection.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-07-06 0:16 ` Marek Vasut
@ 2024-10-07 17:01 ` Isaac Scott
2024-10-07 18:06 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Isaac Scott @ 2024-10-07 17:01 UTC (permalink / raw)
To: Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
Hi Marek,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> On 6/24/24 11:19 AM, Alexander Stein wrote:
> > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
> > > In case an upstream bridge modified the required clock frequency
> > > in its .atomic_check callback by setting adjusted_mode.clock ,
> > > make sure that clock frequency is generated by the LCDIFv3 block.
> > >
> > > This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
> > > with (e)DP output, where the TC358767 expects precise timing on
> > > its input side, the precise timing must be generated by the
> > > LCDIF.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> >
> > With the other rc358767 patches in place, this does the trick.
> > Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>
> I'll pick this up next week if there is no objection.
Unfortunately, this has caused a regression that is present in v6.12-
rc1 on the i.MX8MP PHYTEC Pollux using the
arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
display is the edt,etml1010g3dra panel, as per the upstream dts. We
bisected to this commit, and reverting this change fixed the screen.
We then tried to retest this on top of v6.12-rc2, and found we also had
to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk: imx:
clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
alongside this. Reverting these two commits makes the display work
again at -rc2.
Do you have any suggestions on anything we might be missing on our end?
Please let me know if there's anything you'd like me to test as I'm not
sure what the underlying fault was here.
Best wishes,
Isaac
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-07 17:01 ` Isaac Scott
@ 2024-10-07 18:06 ` Marek Vasut
2024-10-08 10:07 ` Isaac Scott
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-10-07 18:06 UTC (permalink / raw)
To: Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/7/24 7:01 PM, Isaac Scott wrote:
> Hi Marek,
Hi,
> On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
>> On 6/24/24 11:19 AM, Alexander Stein wrote:
>>> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
>>>> In case an upstream bridge modified the required clock frequency
>>>> in its .atomic_check callback by setting adjusted_mode.clock ,
>>>> make sure that clock frequency is generated by the LCDIFv3 block.
>>>>
>>>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
>>>> with (e)DP output, where the TC358767 expects precise timing on
>>>> its input side, the precise timing must be generated by the
>>>> LCDIF.
>>>>
>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>
>>> With the other rc358767 patches in place, this does the trick.
>>> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>>
>> I'll pick this up next week if there is no objection.
>
> Unfortunately, this has caused a regression that is present in v6.12-
> rc1 on the i.MX8MP PHYTEC Pollux using the
> arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
> display is the edt,etml1010g3dra panel, as per the upstream dts. We
> bisected to this commit, and reverting this change fixed the screen.
>
> We then tried to retest this on top of v6.12-rc2, and found we also had
> to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk: imx:
> clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
> alongside this. Reverting these two commits makes the display work
> again at -rc2.
>
> Do you have any suggestions on anything we might be missing on our end?
> Please let me know if there's anything you'd like me to test as I'm not
> sure what the underlying fault was here.
I believe what is going on is that the LCDIF cannot configure its
upstream clock because something else is already using those clock and
it set those clock to a specific frequency. LCDIF is now trying to
configure those clock to match the LVDS panel, and it fails, so it tries
to set some approximate clock and that is not good enough for the LVDS
panel.
Can you share dump of /sys/kernel/debug/clk/clk_summary on failing and
working system ? You might see the difference around the "video" clock.
(I have seen this behavior before, the fix was usually a matter of
moving one of the LCDIFs to another upstream clock like PLL3, so it can
pick well matching output clock instead of some horrid approximation
which then drives the panel likely out of specification)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-07 18:06 ` Marek Vasut
@ 2024-10-08 10:07 ` Isaac Scott
2024-10-08 14:37 ` Marek Vasut
2024-10-08 21:48 ` Marek Vasut
0 siblings, 2 replies; 24+ messages in thread
From: Isaac Scott @ 2024-10-08 10:07 UTC (permalink / raw)
To: Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
> On 10/7/24 7:01 PM, Isaac Scott wrote:
> > Hi Marek,
>
> Hi,
>
> > On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> > > On 6/24/24 11:19 AM, Alexander Stein wrote:
> > > > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
> > > > > In case an upstream bridge modified the required clock
> > > > > frequency
> > > > > in its .atomic_check callback by setting adjusted_mode.clock
> > > > > ,
> > > > > make sure that clock frequency is generated by the LCDIFv3
> > > > > block.
> > > > >
> > > > > This is useful e.g. when LCDIFv3 feeds DSIM which feeds
> > > > > TC358767
> > > > > with (e)DP output, where the TC358767 expects precise timing
> > > > > on
> > > > > its input side, the precise timing must be generated by the
> > > > > LCDIF.
> > > > >
> > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > >
> > > > With the other rc358767 patches in place, this does the trick.
> > > > Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > >
> > > I'll pick this up next week if there is no objection.
> >
> > Unfortunately, this has caused a regression that is present in
> > v6.12-
> > rc1 on the i.MX8MP PHYTEC Pollux using the
> > arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
> > display is the edt,etml1010g3dra panel, as per the upstream dts. We
> > bisected to this commit, and reverting this change fixed the
> > screen.
> >
> > We then tried to retest this on top of v6.12-rc2, and found we also
> > had
> > to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk:
> > imx:
> > clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
> > alongside this. Reverting these two commits makes the display work
> > again at -rc2.
> >
> > Do you have any suggestions on anything we might be missing on our
> > end?
> > Please let me know if there's anything you'd like me to test as I'm
> > not
> > sure what the underlying fault was here.
> I believe what is going on is that the LCDIF cannot configure its
> upstream clock because something else is already using those clock
> and
> it set those clock to a specific frequency. LCDIF is now trying to
> configure those clock to match the LVDS panel, and it fails, so it
> tries
> to set some approximate clock and that is not good enough for the
> LVDS
> panel.
>
> Can you share dump of /sys/kernel/debug/clk/clk_summary on failing
> and
> working system ? You might see the difference around the "video"
> clock.
>
> (I have seen this behavior before, the fix was usually a matter of
> moving one of the LCDIFs to another upstream clock like PLL3, so it
> can
> pick well matching output clock instead of some horrid approximation
> which then drives the panel likely out of specification)
Hi Marek,
Please find attached the clk_summary for v6.12-rc2 before and after the
reversion (the one after the reversion is 6.12-rc2_summary_postfix).
[-- Attachment #2: 6.12-rc2_summary --]
[-- Type: text/plain, Size: 84249 bytes --]
enable prepare protect duty hardware connection
clock count count count rate accuracy phase cycle enable consumer id
---------------------------------------------------------------------------------------------------------------------------------------------
rv3028-clkout 0 0 0 32768 0 0 50000 Y deviceless no_connection_id
dummy 0 0 0 0 0 0 50000 Y 30b50000.mmc ipg
30b60000.mmc ipg
deviceless no_connection_id
clk_ext4 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext4
deviceless no_connection_id
clk_ext3 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext3
deviceless no_connection_id
clk_ext2 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext2
deviceless no_connection_id
clk_ext1 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext1
deviceless no_connection_id
osc_24m 13 16 0 24000000 0 0 50000 Y clock-controller@30380000 osc_24m
timer@306a0000 per
deviceless no_connection_id
usb_phy_ref 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
usb_phy_root_clk 2 2 0 24000000 0 0 50000 Y 382f0040.usb-phy phy
381f0040.usb-phy phy
deviceless no_connection_id
hsio_pll 1 1 0 100000000 0 0 50000 Y 32f00000.pcie-phy ref
deviceless no_connection_id
sai_pll_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai_pll 0 0 0 49152000 0 0 50000 Y deviceless no_connection_id
sai_pll_bypass 0 0 0 49152000 0 0 50000 Y deviceless no_connection_id
sai_pll_out 0 0 0 49152000 0 0 50000 N deviceless no_connection_id
sai_pll_out_div2 0 0 0 24576000 0 0 50000 Y deviceless no_connection_id
earc_phy_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai1_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai2_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai3_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai5_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai6_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai7_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
audpll_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai7_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
vpu_vc8000e 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
vpu_vc8ke_root_clk 0 0 0 24000000 0 0 50000 N 38330000.blk-ctrl vc8000e
power-domain@13 no_connection_id
deviceless no_connection_id
pdm 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pdm_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
pdm_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
media_mipi_test_byte 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
mem_repair 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
media_cam2_pix 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
media_cam2_pix_root_clk 0 0 0 24000000 0 0 50000 N 32ec0000.blk-ctrl cam2
deviceless no_connection_id
media_cam1_pix 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
media_cam1_pix_root_clk 0 0 0 24000000 0 0 50000 N 32ec0000.blk-ctrl cam1
deviceless no_connection_id
hdmi_ref_266m 0 0 0 24000000 0 0 50000 N 32fc0000.blk-ctrl ref_266m
deviceless no_connection_id
hdmi_24m 0 0 0 24000000 0 0 50000 N 32fc0000.blk-ctrl ref_24m
deviceless no_connection_id
hdmi_fdcc_tst 0 0 0 24000000 0 0 50000 N 32fc0000.blk-ctrl fdcc
32fc0000.blk-ctrl fdcc
deviceless no_connection_id
ipp_do_clko2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
ipp_do_clko1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
wdog3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog1_root_clk 1 1 0 24000000 0 0 50000 Y 30280000.watchdog no_connection_id
deviceless no_connection_id
gpt6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt6_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt5_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt1_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm3 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
pwm3_root_clk 2 2 0 24000000 0 0 50000 Y 30680000.pwm per
30680000.pwm ipg
deviceless no_connection_id
pwm2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm1_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
usb_core_ref 2 2 0 24000000 0 0 50000 Y 38200000.usb ref
38100000.usb ref
deviceless no_connection_id
uart4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart1 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
uart1_root_clk 4 4 0 24000000 0 0 50000 Y 30860000.serial per
30860000.serial ipg
deviceless no_connection_id
i2c4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c2 0 1 0 24000000 0 0 50000 N deviceless no_connection_id
i2c2_root_clk 0 1 0 24000000 0 0 50000 N 30a30000.i2c no_connection_id
deviceless no_connection_id
i2c1 0 1 0 24000000 0 0 50000 N deviceless no_connection_id
i2c1_root_clk 0 1 0 24000000 0 0 50000 N 30a20000.i2c no_connection_id
deviceless no_connection_id
sai6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai6_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai5_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai3_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai2_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai7_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai6_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai5_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai3_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai2_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai1_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai1_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c6_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c5_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
mipi_dsi_esc_rx 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sys_pll3_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll3 0 0 0 600000000 0 0 50000 Y deviceless no_connection_id
sys_pll3_bypass 0 0 0 600000000 0 0 50000 Y deviceless no_connection_id
sys_pll3_out 0 0 0 600000000 0 0 50000 N deviceless no_connection_id
sys_pll2_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll2 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_bypass 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_out 5 5 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_1000m 2 3 0 1000000000 0 0 50000 Y deviceless no_connection_id
vpu_g2 0 1 0 500000000 0 0 50000 N deviceless no_connection_id
vpu_g2_root_clk 0 1 0 500000000 0 0 50000 N 38310000.video-codec no_connection_id
38330000.blk-ctrl g2
power-domain@12 no_connection_id
deviceless no_connection_id
media_axi 1 1 0 500000000 0 0 50000 Y deviceless no_connection_id
media_axi_root_clk 2 2 0 500000000 0 0 50000 Y 32e90000.display-controller disp_axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
power-domain@10 no_connection_id
deviceless no_connection_id
noc 1 1 0 1000000000 0 0 50000 Y 32700000.interconnect no_connection_id
32700000.interconnect no_connection_id
deviceless no_connection_id
sys_pll2_500m 2 2 0 500000000 0 0 50000 Y deviceless no_connection_id
media_isp 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
media_isp_root_clk 0 0 0 500000000 0 0 50000 N 32ec0000.blk-ctrl isp
power-domain@18 no_connection_id
deviceless no_connection_id
hsio_axi 3 3 0 500000000 0 0 50000 Y 33800000.pcie pcie_bus
power-domain@17 no_connection_id
deviceless no_connection_id
usb_root_clk 2 2 0 500000000 0 0 50000 Y 38200000.usb bus_early
38100000.usb bus_early
32f10000.blk-ctrl usb
deviceless no_connection_id
hdmi_axi 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
hdmi_root_clk 0 0 0 500000000 0 0 50000 N 32fc0000.blk-ctrl axi
32fc0000.blk-ctrl axi
32fc0000.blk-ctrl axi
power-domain@14 no_connection_id
deviceless no_connection_id
gic 1 1 0 500000000 0 0 50000 Y deviceless no_connection_id
nand 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
nand_root_clk 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
sys_pll2_333m 0 0 0 333333333 0 0 50000 Y deviceless no_connection_id
sys_pll2_250m 0 0 0 250000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_200m 0 0 0 200000000 0 0 50000 Y deviceless no_connection_id
ecspi3 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi3_root_clk 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi2 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi2_root_clk 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
m7_core 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
sys_pll2_166m 0 0 0 166666666 0 0 50000 Y deviceless no_connection_id
sys_pll2_125m 1 1 0 125000000 0 0 50000 Y deviceless no_connection_id
enet_qos 0 0 0 125000000 0 0 50000 N 30bf0000.ethernet tx
deviceless no_connection_id
enet_ref 1 1 0 125000000 0 0 50000 Y 30be0000.ethernet enet_clk_ref
deviceless no_connection_id
sys_pll2_100m 1 1 0 100000000 0 0 50000 Y deviceless no_connection_id
enet_qos_timer 0 0 0 100000000 0 0 50000 N 30bf0000.ethernet ptp_ref
deviceless no_connection_id
enet_timer 1 1 0 100000000 0 0 50000 Y 30be0000.ethernet ptp
deviceless no_connection_id
sys_pll2_50m 2 2 0 50000000 0 0 50000 Y deviceless no_connection_id
pcie_aux 1 1 0 10000000 0 0 50000 Y deviceless no_connection_id
pcie_root_clk 1 1 0 10000000 0 0 50000 Y 33800000.pcie pcie_aux
32f10000.blk-ctrl pcie
deviceless no_connection_id
enet_phy_ref 1 1 0 50000000 0 0 50000 Y 30be0000.ethernet enet_out
deviceless no_connection_id
sys_pll1_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll1 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_bypass 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_out 4 4 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_800m 7 7 0 800000000 0 0 50000 Y deviceless no_connection_id
gpu2d_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu2d_root_clk 0 0 0 800000000 0 0 50000 N 38008000.gpu core
power-domain@6 no_connection_id
deviceless no_connection_id
gpu3d_shader_core 0 0 0 800000000 0 0 50000 N 38000000.gpu shader
power-domain@9 no_connection_id
deviceless no_connection_id
gpu3d_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu3d_root_clk 0 0 0 800000000 0 0 50000 N 38000000.gpu core
power-domain@9 no_connection_id
deviceless no_connection_id
ecspi1 1 1 0 80000000 0 0 50000 Y deviceless no_connection_id
ecspi1_root_clk 2 2 0 80000000 0 0 50000 Y 30820000.spi per
30820000.spi ipg
deviceless no_connection_id
gpu_ahb 0 0 0 400000000 0 0 50000 N 38008000.gpu reg
38000000.gpu reg
power-domain@7 no_connection_id
deviceless no_connection_id
gpu_axi 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu_root_clk 0 0 0 800000000 0 0 50000 N 38008000.gpu bus
38000000.gpu bus
power-domain@7 no_connection_id
deviceless no_connection_id
audio_axi 1 1 0 400000000 0 0 50000 Y power-domain@5 no_connection_id
deviceless no_connection_id
audio_axi_root 0 0 0 400000000 0 0 50000 Y deviceless no_connection_id
audio_ahb 1 1 0 400000000 0 0 50000 Y deviceless no_connection_id
audio_ahb_root 1 5 0 400000000 0 0 50000 Y 30e10000.dma-controller ahb
30e00000.dma-controller ahb
power-domain@5 no_connection_id
deviceless no_connection_id
sai7_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai6_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai5_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai3_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai2_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai1_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
mu3_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
mu2_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
edma_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
dspdbg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
dsp_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
spba2_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sdma3_cg 0 1 0 400000000 0 0 50000 N 30e00000.dma-controller ipg
deviceless no_connection_id
sdma2_cg 0 1 0 400000000 0 0 50000 N 30e10000.dma-controller ipg
deviceless no_connection_id
aud2htx_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
ocrama_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
earc_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
pdm_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
asrc_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
ml_ahb 0 0 0 266666667 0 0 50000 N 38500000.npu reg
power-domain@4 no_connection_id
deviceless no_connection_id
ml_axi 0 0 0 800000000 0 0 50000 N 38500000.npu bus
power-domain@4 no_connection_id
deviceless no_connection_id
ml_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
npu_root_clk 0 0 0 800000000 0 0 50000 N 38500000.npu shader
38500000.npu core
power-domain@4 no_connection_id
deviceless no_connection_id
noc_io 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
arm_a53_div 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
dram_apb 1 1 0 160000000 0 0 50000 Y deviceless no_connection_id
media_apb 1 1 0 200000000 0 0 50000 Y deviceless no_connection_id
media_apb_root_clk 2 3 0 200000000 0 0 50000 Y 32e90000.display-controller axi
blk-ctrl@32ec0000 no_connection_id
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
power-domain@10 no_connection_id
deviceless no_connection_id
main_axi 1 1 0 400000000 0 0 50000 Y 28c06000.etr apb_pclk
28c04000.etf apb_pclk
28c03000.funnel apb_pclk
28c03000.funnel apb_pclk
deviceless no_connection_id
sys_pll1_400m 1 1 0 400000000 0 0 50000 Y deviceless no_connection_id
usdhc3 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
usdhc3_root_clk 0 0 0 400000000 0 0 50000 N 30b60000.mmc per
deviceless no_connection_id
usdhc2 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
usdhc2_root_clk 0 0 0 200000000 0 0 50000 N 30b50000.mmc per
deviceless no_connection_id
usdhc1 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
usdhc1_root_clk 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
qspi 1 1 0 80000000 0 0 50000 Y deviceless no_connection_id
qspi_root_clk 2 2 0 80000000 0 0 50000 Y 30bb0000.spi fspi
30bb0000.spi fspi_en
deviceless no_connection_id
sys_pll1_266m 1 1 0 266666666 0 0 50000 Y deviceless no_connection_id
nand_usdhc_bus 0 0 0 266666666 0 0 50000 N 30b50000.mmc ahb
30b60000.mmc ahb
deviceless no_connection_id
nand_usdhc_rawnand_clk 0 0 0 266666666 0 0 50000 N deviceless no_connection_id
enet_axi 2 2 0 266666666 0 0 50000 Y deviceless no_connection_id
sim_enet_root_clk 1 1 0 266666666 0 0 50000 Y 30be0000.ethernet ahb
deviceless no_connection_id
enet_qos_root_clk 0 0 0 266666666 0 0 50000 N 30bf0000.ethernet stmmaceth
deviceless no_connection_id
enet1_root_clk 1 1 0 266666666 0 0 50000 Y 30be0000.ethernet ipg
deviceless no_connection_id
sys_pll1_200m 0 0 0 200000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_160m 0 0 0 160000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_133m 1 1 0 133333333 0 0 50000 Y deviceless no_connection_id
hdmi_apb 0 0 0 133333333 0 0 50000 N 32fc2000.interrupt-controller ipg
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
power-domain@14 no_connection_id
deviceless no_connection_id
ahb_root 5 4 0 133333333 0 0 50000 Y 30900000.crypto aclk
30bd0000.dma-controller ahb
deviceless no_connection_id
ipg_root 9 9 0 66666667 0 0 50000 Y 308d0000.can ipg
308c0000.can ipg
30900000.crypto ipg
deviceless no_connection_id
tsensor_root_clk 1 1 0 66666667 0 0 50000 Y 30260000.tmu no_connection_id
deviceless no_connection_id
hsio_root_clk 4 4 0 66666667 0 0 50000 Y 33800000.pcie pcie
32f10108.usb hsio
32f10100.usb hsio
power-domain@17 no_connection_id
deviceless no_connection_id
sdma1_root_clk 2 1 0 66666667 0 0 50000 Y 30bd0000.dma-controller ipg
deviceless no_connection_id
qos_enet_root_clk 0 0 0 66666667 0 0 50000 N 30bf0000.ethernet pclk
deviceless no_connection_id
qos_root_clk 0 0 0 66666667 0 0 50000 N deviceless no_connection_id
ocotp_root_clk 0 0 0 66666667 0 0 50000 N 30350000.efuse no_connection_id
deviceless no_connection_id
mu_root_clk 0 0 0 66666667 0 0 50000 N 30aa0000.mailbox no_connection_id
deviceless no_connection_id
gpio5_root_clk 1 1 0 66666667 0 0 50000 Y 30240000.gpio no_connection_id
deviceless no_connection_id
gpio4_root_clk 1 1 0 66666667 0 0 50000 Y 30230000.gpio no_connection_id
deviceless no_connection_id
gpio3_root_clk 1 1 0 66666667 0 0 50000 Y 30220000.gpio no_connection_id
deviceless no_connection_id
gpio2_root_clk 1 1 0 66666667 0 0 50000 Y 30210000.gpio no_connection_id
deviceless no_connection_id
gpio1_root_clk 1 1 0 66666667 0 0 50000 Y 30200000.gpio no_connection_id
deviceless no_connection_id
sys_pll1_100m 0 0 0 100000000 0 0 50000 Y deviceless no_connection_id
dram_alt 0 0 0 100000000 0 0 50000 N deviceless no_connection_id
dram_alt_root 0 0 0 25000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_80m 0 0 0 80000000 0 0 50000 Y deviceless no_connection_id
uart2 0 0 0 80000000 0 0 50000 N deviceless no_connection_id
uart2_root_clk 0 0 0 80000000 0 0 50000 N 30890000.serial per
30890000.serial ipg
deviceless no_connection_id
sys_pll1_40m 0 0 0 40000000 0 0 50000 Y deviceless no_connection_id
can2 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
can2_root_clk 0 0 0 40000000 0 0 50000 N 308d0000.can per
deviceless no_connection_id
can1 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
can1_root_clk 0 0 0 40000000 0 0 50000 N 308c0000.can per
deviceless no_connection_id
wrclk 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
arm_pll_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
arm_pll 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_pll_bypass 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_pll_out 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_a53_core 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm 1 1 0 1200000000 0 0 50000 Y cpu0 no_connection_id
cpu0 no_connection_id
deviceless no_connection_id
vpu_pll_ref_sel 0 1 0 24000000 0 0 50000 Y deviceless no_connection_id
vpu_pll 0 1 0 600000000 0 0 50000 Y deviceless no_connection_id
vpu_pll_bypass 0 1 0 600000000 0 0 50000 Y deviceless no_connection_id
vpu_pll_out 0 1 0 600000000 0 0 50000 N deviceless no_connection_id
vpu_g1 0 1 0 600000000 0 0 50000 N deviceless no_connection_id
vpu_g1_root_clk 0 1 0 600000000 0 0 50000 N 38300000.video-codec no_connection_id
38330000.blk-ctrl g1
power-domain@11 no_connection_id
deviceless no_connection_id
vpu_bus 0 0 0 300000000 0 0 50000 N deviceless no_connection_id
vpu_root_clk 0 0 0 300000000 0 0 50000 N power-domain@8 no_connection_id
deviceless no_connection_id
gpu_pll_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
gpu_pll 0 0 0 1000000000 0 0 50000 Y deviceless no_connection_id
gpu_pll_bypass 0 0 0 1000000000 0 0 50000 Y deviceless no_connection_id
gpu_pll_out 0 0 0 1000000000 0 0 50000 N deviceless no_connection_id
dram_pll_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
dram_pll 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_pll_bypass 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_pll_out 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_core_clk 2 2 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram1_root_clk 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
video_pll1_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
video_pll1 1 1 0 72400000 0 0 50000 Y deviceless no_connection_id
video_pll1_bypass 1 1 0 72400000 0 0 50000 Y deviceless no_connection_id
video_pll1_out 2 2 0 72400000 0 0 50000 Y deviceless no_connection_id
media_ldb 1 1 0 72400000 0 0 50000 Y deviceless no_connection_id
media_ldb_root_clk 1 1 0 72400000 0 0 50000 Y 32ec0000.blk-ctrl:bridge@5c ldb
deviceless no_connection_id
media_disp2_pix 1 1 0 72400000 0 0 50000 Y deviceless no_connection_id
media_disp2_pix_root_clk 1 1 0 72400000 0 0 50000 Y 32e90000.display-controller pix
32ec0000.blk-ctrl disp2
deviceless no_connection_id
media_disp1_pix 0 0 0 72400000 0 0 50000 N deviceless no_connection_id
media_disp1_pix_root_clk 0 0 0 72400000 0 0 50000 N 32ec0000.blk-ctrl disp1
deviceless no_connection_id
media_mipi_phy1_ref 0 0 0 3290910 0 0 50000 N deviceless no_connection_id
media_mipi_phy1_ref_root 0 0 0 3290910 0 0 50000 N 32ec0000.blk-ctrl phy
32ec0000.blk-ctrl phy
deviceless no_connection_id
audio_pll2_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
audio_pll2 0 0 0 361267200 0 0 50000 Y deviceless no_connection_id
audio_pll2_bypass 0 0 0 361267200 0 0 50000 Y deviceless no_connection_id
audio_pll2_out 0 0 0 361267200 0 0 50000 N deviceless no_connection_id
audio_pll1_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
audio_pll1 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
audio_pll1_bypass 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
audio_pll1_out 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
clkout2_sel 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout2_div 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout2 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
clkout1_sel 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout1_div 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout1 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
osc_32k 1 1 0 32768 0 0 50000 Y clock-controller@30380000 osc_32k
deviceless no_connection_id
usb_suspend_clk 4 4 0 32768 0 0 50000 Y 38200000.usb suspend
38100000.usb suspend
32f10108.usb suspend
32f10100.usb suspend
deviceless no_connection_id
[-- Attachment #3: 6.12-rc2_summary_postfix --]
[-- Type: text/plain, Size: 87290 bytes --]
enable prepare protect duty hardware connection
clock count count count rate accuracy phase cycle enable consumer id
---------------------------------------------------------------------------------------------------------------------------------------------
rv3028-clkout 0 0 0 32768 0 0 50000 Y deviceless no_connection_id
dummy 0 0 0 0 0 0 50000 Y 30b50000.mmc ipg
30b60000.mmc ipg
deviceless no_connection_id
ar0144-clk 0 0 0 27000000 0 0 50000 Y 2-0010 no_connection_id
deviceless no_connection_id
clk_ext4 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext4
deviceless no_connection_id
clk_ext3 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext3
deviceless no_connection_id
clk_ext2 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext2
deviceless no_connection_id
clk_ext1 0 0 0 133000000 0 0 50000 Y clock-controller@30380000 clk_ext1
deviceless no_connection_id
osc_24m 13 17 0 24000000 0 0 50000 Y clock-controller@30380000 osc_24m
timer@306a0000 per
deviceless no_connection_id
media_mipi_phy1_ref 0 0 0 1090910 0 0 50000 N deviceless no_connection_id
media_mipi_phy1_ref_root 0 0 0 1090910 0 0 50000 N 32e40000.csi phy
32ec0000.blk-ctrl phy
32ec0000.blk-ctrl phy
deviceless no_connection_id
usb_phy_ref 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
usb_phy_root_clk 2 2 0 24000000 0 0 50000 Y 382f0040.usb-phy phy
381f0040.usb-phy phy
deviceless no_connection_id
hsio_pll 1 1 0 100000000 0 0 50000 Y 32f00000.pcie-phy ref
deviceless no_connection_id
sai_pll_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai_pll 0 0 0 49152000 0 0 50000 Y deviceless no_connection_id
sai_pll_bypass 0 0 0 49152000 0 0 50000 Y deviceless no_connection_id
sai_pll_out 0 0 0 49152000 0 0 50000 N deviceless no_connection_id
sai_pll_out_div2 0 0 0 24576000 0 0 50000 Y deviceless no_connection_id
earc_phy_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai1_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai2_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai3_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai5_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai6_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
sai7_mclk3_cg 0 0 0 24576000 0 0 50000 N deviceless no_connection_id
audpll_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai7_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
vpu_vc8000e 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
vpu_vc8ke_root_clk 0 0 0 24000000 0 0 50000 N 38330000.blk-ctrl vc8000e
power-domain@13 no_connection_id
deviceless no_connection_id
pdm 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pdm_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
pdm_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
media_mipi_test_byte 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
mem_repair 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
media_cam2_pix 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
media_cam2_pix_root_clk 0 0 0 24000000 0 0 50000 N 32ec0000.blk-ctrl cam2
deviceless no_connection_id
hdmi_24m 0 0 0 24000000 0 0 50000 N 32fdff00.phy ref
32fc0000.blk-ctrl ref_24m
deviceless no_connection_id
hdmi_pclk 0 0 0 74250000 0 0 50000 Y 32fd8000.hdmi pix
deviceless no_connection_id
hdmi_fdcc_tst 0 0 0 24000000 0 0 50000 N 32fc0000.blk-ctrl fdcc
32fc0000.blk-ctrl fdcc
deviceless no_connection_id
ipp_do_clko2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
ipp_do_clko1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
wdog3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
wdog1_root_clk 1 1 0 24000000 0 0 50000 Y 30280000.watchdog no_connection_id
deviceless no_connection_id
gpt6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt6_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt5_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
gpt1_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm3 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
pwm3_root_clk 2 2 0 24000000 0 0 50000 Y 30680000.pwm per
30680000.pwm ipg
deviceless no_connection_id
pwm2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm2_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
pwm1_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
usb_core_ref 2 2 0 24000000 0 0 50000 Y 38200000.usb ref
38100000.usb ref
deviceless no_connection_id
uart4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart3_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
uart1 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
uart1_root_clk 4 4 0 24000000 0 0 50000 Y 30860000.serial per
30860000.serial ipg
deviceless no_connection_id
i2c4 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c4_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c3 0 1 0 24000000 0 0 50000 N deviceless no_connection_id
i2c3_root_clk 0 1 0 24000000 0 0 50000 N 30a40000.i2c no_connection_id
deviceless no_connection_id
i2c2 0 1 0 24000000 0 0 50000 N deviceless no_connection_id
i2c2_root_clk 0 1 0 24000000 0 0 50000 N 30a30000.i2c no_connection_id
deviceless no_connection_id
i2c1 0 1 0 24000000 0 0 50000 N deviceless no_connection_id
i2c1_root_clk 0 1 0 24000000 0 0 50000 N 30a20000.i2c no_connection_id
deviceless no_connection_id
sai6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai6_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai5_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai3_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai2_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai7_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai7_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai6_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai6_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai5_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai5_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai3_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai3_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai2_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai2_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_mclk2_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai1_mclk2_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_mclk1_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sai1_mclk1_cg 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sai1_root 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c6 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c6_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c5 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
i2c5_root_clk 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
mipi_dsi_esc_rx 0 0 0 24000000 0 0 50000 N deviceless no_connection_id
sys_pll3_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll3 0 0 0 600000000 0 0 50000 Y deviceless no_connection_id
sys_pll3_bypass 0 0 0 600000000 0 0 50000 Y deviceless no_connection_id
sys_pll3_out 0 0 0 600000000 0 0 50000 N deviceless no_connection_id
sys_pll2_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll2 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_bypass 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_out 5 5 0 1000000000 0 0 50000 Y deviceless no_connection_id
sys_pll2_1000m 2 3 0 1000000000 0 0 50000 Y deviceless no_connection_id
vpu_g2 0 1 0 500000000 0 0 50000 N deviceless no_connection_id
vpu_g2_root_clk 0 1 0 500000000 0 0 50000 N 38310000.video-codec no_connection_id
38330000.blk-ctrl g2
power-domain@12 no_connection_id
deviceless no_connection_id
media_axi 1 1 0 500000000 0 0 50000 Y deviceless no_connection_id
media_axi_root_clk 2 2 0 500000000 0 0 50000 Y 32e10000.isp aclk
32e40000.csi axi
32e90000.display-controller disp_axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
32ec0000.blk-ctrl axi
power-domain@10 no_connection_id
deviceless no_connection_id
noc 1 1 0 1000000000 0 0 50000 Y 32700000.interconnect no_connection_id
32700000.interconnect no_connection_id
deviceless no_connection_id
sys_pll2_500m 3 3 0 500000000 0 0 50000 Y deviceless no_connection_id
media_isp 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
media_isp_root_clk 0 0 0 500000000 0 0 50000 N 32e10000.isp isp
32ec0000.blk-ctrl isp
power-domain@18 no_connection_id
deviceless no_connection_id
hsio_axi 3 3 0 500000000 0 0 50000 Y 33800000.pcie pcie_bus
power-domain@17 no_connection_id
deviceless no_connection_id
usb_root_clk 2 2 0 500000000 0 0 50000 Y 38200000.usb bus_early
38100000.usb bus_early
32f10000.blk-ctrl usb
deviceless no_connection_id
hdmi_axi 1 1 0 500000000 0 0 50000 Y deviceless no_connection_id
hdmi_root_clk 1 1 0 500000000 0 0 50000 Y 32fc0000.blk-ctrl axi
32fc0000.blk-ctrl axi
32fc0000.blk-ctrl axi
power-domain@14 no_connection_id
deviceless no_connection_id
gic 1 1 0 500000000 0 0 50000 Y deviceless no_connection_id
nand 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
nand_root_clk 0 0 0 500000000 0 0 50000 N deviceless no_connection_id
sys_pll2_333m 0 0 0 333333333 0 0 50000 Y deviceless no_connection_id
sys_pll2_250m 0 0 0 250000000 0 0 50000 Y deviceless no_connection_id
media_cam1_pix 0 0 0 250000000 0 0 50000 N deviceless no_connection_id
media_cam1_pix_root_clk 0 0 0 250000000 0 0 50000 N 32e40000.csi wrap
32ec0000.blk-ctrl cam1
deviceless no_connection_id
sys_pll2_200m 0 0 0 200000000 0 0 50000 Y deviceless no_connection_id
ecspi3 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi3_root_clk 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi2 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
ecspi2_root_clk 0 0 0 50000000 0 0 50000 N deviceless no_connection_id
m7_core 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
sys_pll2_166m 0 0 0 166666666 0 0 50000 Y deviceless no_connection_id
sys_pll2_125m 1 1 0 125000000 0 0 50000 Y deviceless no_connection_id
enet_qos 0 0 0 125000000 0 0 50000 N 30bf0000.ethernet tx
deviceless no_connection_id
enet_ref 1 1 0 125000000 0 0 50000 Y 30be0000.ethernet enet_clk_ref
deviceless no_connection_id
sys_pll2_100m 1 1 0 100000000 0 0 50000 Y deviceless no_connection_id
enet_qos_timer 0 0 0 100000000 0 0 50000 N 30bf0000.ethernet ptp_ref
deviceless no_connection_id
enet_timer 1 1 0 100000000 0 0 50000 Y 30be0000.ethernet ptp
deviceless no_connection_id
sys_pll2_50m 2 2 0 50000000 0 0 50000 Y deviceless no_connection_id
pcie_aux 1 1 0 10000000 0 0 50000 Y deviceless no_connection_id
pcie_root_clk 1 1 0 10000000 0 0 50000 Y 33800000.pcie pcie_aux
32f10000.blk-ctrl pcie
deviceless no_connection_id
enet_phy_ref 1 1 0 50000000 0 0 50000 Y 30be0000.ethernet enet_out
deviceless no_connection_id
sys_pll1_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
sys_pll1 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_bypass 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_out 4 4 0 800000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_800m 7 7 0 800000000 0 0 50000 Y deviceless no_connection_id
gpu2d_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu2d_root_clk 0 0 0 800000000 0 0 50000 N 38008000.gpu core
power-domain@6 no_connection_id
deviceless no_connection_id
gpu3d_shader_core 0 0 0 800000000 0 0 50000 N 38000000.gpu shader
power-domain@9 no_connection_id
deviceless no_connection_id
gpu3d_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu3d_root_clk 0 0 0 800000000 0 0 50000 N 38000000.gpu core
power-domain@9 no_connection_id
deviceless no_connection_id
ecspi1 1 1 0 80000000 0 0 50000 Y deviceless no_connection_id
ecspi1_root_clk 2 2 0 80000000 0 0 50000 Y 30820000.spi per
30820000.spi ipg
deviceless no_connection_id
gpu_ahb 0 0 0 400000000 0 0 50000 N 38008000.gpu reg
38000000.gpu reg
power-domain@7 no_connection_id
deviceless no_connection_id
gpu_axi 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
gpu_root_clk 0 0 0 800000000 0 0 50000 N 38008000.gpu bus
38000000.gpu bus
power-domain@7 no_connection_id
deviceless no_connection_id
audio_axi 1 1 0 400000000 0 0 50000 Y power-domain@5 no_connection_id
deviceless no_connection_id
audio_axi_root 0 0 0 400000000 0 0 50000 Y deviceless no_connection_id
audio_ahb 1 1 0 400000000 0 0 50000 Y deviceless no_connection_id
audio_ahb_root 1 5 0 400000000 0 0 50000 Y 30e10000.dma-controller ahb
30e00000.dma-controller ahb
power-domain@5 no_connection_id
deviceless no_connection_id
sai7_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai6_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai5_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai3_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai2_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sai1_ipg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
mu3_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
mu2_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
edma_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
dspdbg_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
dsp_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
spba2_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
sdma3_cg 0 1 0 400000000 0 0 50000 N 30e00000.dma-controller ipg
deviceless no_connection_id
sdma2_cg 0 1 0 400000000 0 0 50000 N 30e10000.dma-controller ipg
deviceless no_connection_id
aud2htx_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
ocrama_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
earc_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
pdm_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
asrc_cg 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
ml_ahb 0 0 0 266666667 0 0 50000 N 38500000.npu reg
power-domain@4 no_connection_id
deviceless no_connection_id
ml_axi 0 0 0 800000000 0 0 50000 N 38500000.npu bus
power-domain@4 no_connection_id
deviceless no_connection_id
ml_core 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
npu_root_clk 0 0 0 800000000 0 0 50000 N 38500000.npu shader
38500000.npu core
power-domain@4 no_connection_id
deviceless no_connection_id
noc_io 1 1 0 800000000 0 0 50000 Y deviceless no_connection_id
arm_a53_div 0 0 0 800000000 0 0 50000 N deviceless no_connection_id
dram_apb 1 1 0 160000000 0 0 50000 Y deviceless no_connection_id
media_apb 1 1 0 200000000 0 0 50000 Y deviceless no_connection_id
media_apb_root_clk 2 3 0 200000000 0 0 50000 Y 32e10000.isp hclk
32e40000.csi pclk
32e90000.display-controller axi
blk-ctrl@32ec0000 no_connection_id
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
32ec0000.blk-ctrl apb
power-domain@10 no_connection_id
deviceless no_connection_id
main_axi 1 1 0 400000000 0 0 50000 Y 28c06000.etr apb_pclk
28c04000.etf apb_pclk
28c03000.funnel apb_pclk
28c03000.funnel apb_pclk
deviceless no_connection_id
sys_pll1_400m 1 1 0 400000000 0 0 50000 Y deviceless no_connection_id
usdhc3 0 0 0 400000000 0 0 50000 N deviceless no_connection_id
usdhc3_root_clk 0 0 0 400000000 0 0 50000 N 30b60000.mmc per
deviceless no_connection_id
usdhc2 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
usdhc2_root_clk 0 0 0 200000000 0 0 50000 N 30b50000.mmc per
deviceless no_connection_id
usdhc1 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
usdhc1_root_clk 0 0 0 200000000 0 0 50000 N deviceless no_connection_id
qspi 1 1 0 80000000 0 0 50000 Y deviceless no_connection_id
qspi_root_clk 2 2 0 80000000 0 0 50000 Y 30bb0000.spi fspi
30bb0000.spi fspi_en
deviceless no_connection_id
sys_pll1_266m 2 2 0 266666666 0 0 50000 Y deviceless no_connection_id
hdmi_ref_266m 1 1 0 266666666 0 0 50000 Y 32fd8000.hdmi isfr
32fc0000.blk-ctrl ref_266m
deviceless no_connection_id
nand_usdhc_bus 0 0 0 266666666 0 0 50000 N 30b50000.mmc ahb
30b60000.mmc ahb
deviceless no_connection_id
nand_usdhc_rawnand_clk 0 0 0 266666666 0 0 50000 N deviceless no_connection_id
enet_axi 2 2 0 266666666 0 0 50000 Y deviceless no_connection_id
sim_enet_root_clk 1 1 0 266666666 0 0 50000 Y 30be0000.ethernet ahb
deviceless no_connection_id
enet_qos_root_clk 0 0 0 266666666 0 0 50000 N 30bf0000.ethernet stmmaceth
deviceless no_connection_id
enet1_root_clk 1 1 0 266666666 0 0 50000 Y 30be0000.ethernet ipg
deviceless no_connection_id
sys_pll1_200m 0 0 0 200000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_160m 0 0 0 160000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_133m 2 2 0 133333333 0 0 50000 Y deviceless no_connection_id
hdmi_apb 4 4 0 133333333 0 0 50000 Y 32fd8000.hdmi iahb
32fdff00.phy apb
32fc2000.interrupt-controller ipg
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
32fc0000.blk-ctrl apb
power-domain@14 no_connection_id
deviceless no_connection_id
ahb_root 5 4 0 133333333 0 0 50000 Y 30bd0000.dma-controller ahb
30900000.crypto aclk
deviceless no_connection_id
ipg_root 9 9 0 66666667 0 0 50000 Y 308d0000.can ipg
308c0000.can ipg
30900000.crypto ipg
deviceless no_connection_id
tsensor_root_clk 1 1 0 66666667 0 0 50000 Y 30260000.tmu no_connection_id
deviceless no_connection_id
hsio_root_clk 4 4 0 66666667 0 0 50000 Y 33800000.pcie pcie
32f10108.usb hsio
32f10100.usb hsio
power-domain@17 no_connection_id
deviceless no_connection_id
sdma1_root_clk 2 1 0 66666667 0 0 50000 Y 30bd0000.dma-controller ipg
deviceless no_connection_id
qos_enet_root_clk 0 0 0 66666667 0 0 50000 N 30bf0000.ethernet pclk
deviceless no_connection_id
qos_root_clk 0 0 0 66666667 0 0 50000 N deviceless no_connection_id
ocotp_root_clk 0 0 0 66666667 0 0 50000 N 30350000.efuse no_connection_id
deviceless no_connection_id
mu_root_clk 0 0 0 66666667 0 0 50000 N 30aa0000.mailbox no_connection_id
deviceless no_connection_id
gpio5_root_clk 1 1 0 66666667 0 0 50000 Y 30240000.gpio no_connection_id
deviceless no_connection_id
gpio4_root_clk 1 1 0 66666667 0 0 50000 Y 30230000.gpio no_connection_id
deviceless no_connection_id
gpio3_root_clk 1 1 0 66666667 0 0 50000 Y 30220000.gpio no_connection_id
deviceless no_connection_id
gpio2_root_clk 1 1 0 66666667 0 0 50000 Y 30210000.gpio no_connection_id
deviceless no_connection_id
gpio1_root_clk 1 1 0 66666667 0 0 50000 Y 30200000.gpio no_connection_id
deviceless no_connection_id
sys_pll1_100m 0 0 0 100000000 0 0 50000 Y deviceless no_connection_id
dram_alt 0 0 0 100000000 0 0 50000 N deviceless no_connection_id
dram_alt_root 0 0 0 25000000 0 0 50000 Y deviceless no_connection_id
sys_pll1_80m 0 0 0 80000000 0 0 50000 Y deviceless no_connection_id
uart2 0 0 0 80000000 0 0 50000 N deviceless no_connection_id
uart2_root_clk 0 0 0 80000000 0 0 50000 N 30890000.serial per
30890000.serial ipg
deviceless no_connection_id
sys_pll1_40m 0 0 0 40000000 0 0 50000 Y deviceless no_connection_id
can2 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
can2_root_clk 0 0 0 40000000 0 0 50000 N 308d0000.can per
deviceless no_connection_id
can1 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
can1_root_clk 0 0 0 40000000 0 0 50000 N 308c0000.can per
deviceless no_connection_id
wrclk 0 0 0 40000000 0 0 50000 N deviceless no_connection_id
arm_pll_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
arm_pll 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_pll_bypass 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_pll_out 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm_a53_core 1 1 0 1200000000 0 0 50000 Y deviceless no_connection_id
arm 1 1 0 1200000000 0 0 50000 Y cpu0 no_connection_id
cpu0 no_connection_id
deviceless no_connection_id
vpu_pll_ref_sel 0 1 0 24000000 0 0 50000 Y deviceless no_connection_id
vpu_pll 0 1 0 600000000 0 0 50000 Y deviceless no_connection_id
vpu_pll_bypass 0 1 0 600000000 0 0 50000 Y deviceless no_connection_id
vpu_pll_out 0 1 0 600000000 0 0 50000 N deviceless no_connection_id
vpu_g1 0 1 0 600000000 0 0 50000 N deviceless no_connection_id
vpu_g1_root_clk 0 1 0 600000000 0 0 50000 N 38300000.video-codec no_connection_id
38330000.blk-ctrl g1
power-domain@11 no_connection_id
deviceless no_connection_id
vpu_bus 0 0 0 300000000 0 0 50000 N deviceless no_connection_id
vpu_root_clk 0 0 0 300000000 0 0 50000 N power-domain@8 no_connection_id
deviceless no_connection_id
gpu_pll_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
gpu_pll 0 0 0 1000000000 0 0 50000 Y deviceless no_connection_id
gpu_pll_bypass 0 0 0 1000000000 0 0 50000 Y deviceless no_connection_id
gpu_pll_out 0 0 0 1000000000 0 0 50000 N deviceless no_connection_id
dram_pll_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
dram_pll 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_pll_bypass 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_pll_out 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram_core_clk 2 2 0 1000000000 0 0 50000 Y deviceless no_connection_id
dram1_root_clk 1 1 0 1000000000 0 0 50000 Y deviceless no_connection_id
video_pll1_ref_sel 1 1 0 24000000 0 0 50000 Y deviceless no_connection_id
video_pll1 1 1 0 1039500000 0 0 50000 Y deviceless no_connection_id
video_pll1_bypass 1 1 0 1039500000 0 0 50000 Y deviceless no_connection_id
video_pll1_out 2 2 0 1039500000 0 0 50000 Y deviceless no_connection_id
media_ldb 1 1 0 519750000 0 0 50000 Y deviceless no_connection_id
media_ldb_root_clk 1 1 0 519750000 0 0 50000 Y 32ec0000.blk-ctrl:bridge@5c ldb
deviceless no_connection_id
media_disp2_pix 1 1 0 74250000 0 0 50000 Y deviceless no_connection_id
media_disp2_pix_root_clk 1 1 0 74250000 0 0 50000 Y 32e90000.display-controller pix
32ec0000.blk-ctrl disp2
deviceless no_connection_id
media_disp1_pix 0 0 0 1039500000 0 0 50000 N deviceless no_connection_id
media_disp1_pix_root_clk 0 0 0 1039500000 0 0 50000 N 32ec0000.blk-ctrl disp1
deviceless no_connection_id
audio_pll2_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
audio_pll2 0 0 0 361267200 0 0 50000 Y deviceless no_connection_id
audio_pll2_bypass 0 0 0 361267200 0 0 50000 Y deviceless no_connection_id
audio_pll2_out 0 0 0 361267200 0 0 50000 N deviceless no_connection_id
audio_pll1_ref_sel 0 0 0 24000000 0 0 50000 Y deviceless no_connection_id
audio_pll1 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
audio_pll1_bypass 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
audio_pll1_out 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
clkout2_sel 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout2_div 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout2 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
clkout1_sel 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout1_div 0 0 0 393216000 0 0 50000 Y deviceless no_connection_id
clkout1 0 0 0 393216000 0 0 50000 N deviceless no_connection_id
osc_32k 2 2 0 32768 0 0 50000 Y 32fd8000.hdmi cec
clock-controller@30380000 osc_32k
deviceless no_connection_id
usb_suspend_clk 4 4 0 32768 0 0 50000 Y 38200000.usb suspend
38100000.usb suspend
32f10108.usb suspend
32f10100.usb suspend
deviceless no_connection_id
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-08 10:07 ` Isaac Scott
@ 2024-10-08 14:37 ` Marek Vasut
2024-10-08 21:48 ` Marek Vasut
1 sibling, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-08 14:37 UTC (permalink / raw)
To: Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/8/24 12:07 PM, Isaac Scott wrote:
> On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
>> On 10/7/24 7:01 PM, Isaac Scott wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
>>>> On 6/24/24 11:19 AM, Alexander Stein wrote:
>>>>> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
>>>>>> In case an upstream bridge modified the required clock
>>>>>> frequency
>>>>>> in its .atomic_check callback by setting adjusted_mode.clock
>>>>>> ,
>>>>>> make sure that clock frequency is generated by the LCDIFv3
>>>>>> block.
>>>>>>
>>>>>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds
>>>>>> TC358767
>>>>>> with (e)DP output, where the TC358767 expects precise timing
>>>>>> on
>>>>>> its input side, the precise timing must be generated by the
>>>>>> LCDIF.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>
>>>>> With the other rc358767 patches in place, this does the trick.
>>>>> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>>>>
>>>> I'll pick this up next week if there is no objection.
>>>
>>> Unfortunately, this has caused a regression that is present in
>>> v6.12-
>>> rc1 on the i.MX8MP PHYTEC Pollux using the
>>> arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
>>> display is the edt,etml1010g3dra panel, as per the upstream dts. We
>>> bisected to this commit, and reverting this change fixed the
>>> screen.
>>>
>>> We then tried to retest this on top of v6.12-rc2, and found we also
>>> had
>>> to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk:
>>> imx:
>>> clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
>>> alongside this. Reverting these two commits makes the display work
>>> again at -rc2.
>>>
>>> Do you have any suggestions on anything we might be missing on our
>>> end?
>>> Please let me know if there's anything you'd like me to test as I'm
>>> not
>>> sure what the underlying fault was here.
>> I believe what is going on is that the LCDIF cannot configure its
>> upstream clock because something else is already using those clock
>> and
>> it set those clock to a specific frequency. LCDIF is now trying to
>> configure those clock to match the LVDS panel, and it fails, so it
>> tries
>> to set some approximate clock and that is not good enough for the
>> LVDS
>> panel.
>>
>> Can you share dump of /sys/kernel/debug/clk/clk_summary on failing
>> and
>> working system ? You might see the difference around the "video"
>> clock.
>>
>> (I have seen this behavior before, the fix was usually a matter of
>> moving one of the LCDIFs to another upstream clock like PLL3, so it
>> can
>> pick well matching output clock instead of some horrid approximation
>> which then drives the panel likely out of specification)
>
> Hi Marek,
>
> Please find attached the clk_summary for v6.12-rc2 before and after the
> reversion (the one after the reversion is 6.12-rc2_summary_postfix).
How come "media_mipi_phy1_ref" is on Video PLL1 before the revert ?
Does it start working if you move "media_mipi_phy1_ref" to osc_24m ?
(probably not)
Also, why is the LDB configured to 74 MHz instead of 519 MHz now ? That
is really odd. I'll see if I can reproduce this later today.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-08 10:07 ` Isaac Scott
2024-10-08 14:37 ` Marek Vasut
@ 2024-10-08 21:48 ` Marek Vasut
2024-10-09 9:55 ` Isaac Scott
2024-10-10 5:31 ` Liu Ying
1 sibling, 2 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-08 21:48 UTC (permalink / raw)
To: Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/8/24 12:07 PM, Isaac Scott wrote:
> On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
>> On 10/7/24 7:01 PM, Isaac Scott wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
>>>> On 6/24/24 11:19 AM, Alexander Stein wrote:
>>>>> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
>>>>>> In case an upstream bridge modified the required clock
>>>>>> frequency
>>>>>> in its .atomic_check callback by setting adjusted_mode.clock
>>>>>> ,
>>>>>> make sure that clock frequency is generated by the LCDIFv3
>>>>>> block.
>>>>>>
>>>>>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds
>>>>>> TC358767
>>>>>> with (e)DP output, where the TC358767 expects precise timing
>>>>>> on
>>>>>> its input side, the precise timing must be generated by the
>>>>>> LCDIF.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>
>>>>> With the other rc358767 patches in place, this does the trick.
>>>>> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>>>>
>>>> I'll pick this up next week if there is no objection.
>>>
>>> Unfortunately, this has caused a regression that is present in
>>> v6.12-
>>> rc1 on the i.MX8MP PHYTEC Pollux using the
>>> arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
>>> display is the edt,etml1010g3dra panel, as per the upstream dts. We
>>> bisected to this commit, and reverting this change fixed the
>>> screen.
>>>
>>> We then tried to retest this on top of v6.12-rc2, and found we also
>>> had
>>> to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk:
>>> imx:
>>> clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
>>> alongside this. Reverting these two commits makes the display work
>>> again at -rc2.
>>>
>>> Do you have any suggestions on anything we might be missing on our
>>> end?
>>> Please let me know if there's anything you'd like me to test as I'm
>>> not
>>> sure what the underlying fault was here.
>> I believe what is going on is that the LCDIF cannot configure its
>> upstream clock because something else is already using those clock
>> and
>> it set those clock to a specific frequency. LCDIF is now trying to
>> configure those clock to match the LVDS panel, and it fails, so it
>> tries
>> to set some approximate clock and that is not good enough for the
>> LVDS
>> panel.
>>
>> Can you share dump of /sys/kernel/debug/clk/clk_summary on failing
>> and
>> working system ? You might see the difference around the "video"
>> clock.
>>
>> (I have seen this behavior before, the fix was usually a matter of
>> moving one of the LCDIFs to another upstream clock like PLL3, so it
>> can
>> pick well matching output clock instead of some horrid approximation
>> which then drives the panel likely out of specification)
>
> Hi Marek,
>
> Please find attached the clk_summary for v6.12-rc2 before and after the
> reversion (the one after the reversion is 6.12-rc2_summary_postfix).
Thank you, this helped greatly.
I believe I know why it used to kind-of work for you, but I'm afraid
this used to work by sheer chance and it does not really work correctly
for the panel you use, even if the panel likely does show the correct
content. But, there is a way to make it work properly for the panel you use.
First of all, the pixel clock never really matched the panel-simple.c
pixel clock for the edt_etml1010g3dra_timing:
$ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
media_disp2_pix 1 1 0 74250000 ...
^^^^^^^^
$ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-simple.c
static const struct display_timing edt_etml1010g3dra_timing = {
.pixelclock = { 66300000, 72400000, 78900000 },
^^^^^^^^
The pixel clock are within tolerance, but there is a discrepancy
74250000 != 72400000 .
Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB nodes")
the IMX8MP_VIDEO_PLL1_OUT is set to a very specific frequency of
1039500000 Hz, which tidily divides by 2 to 519750000 Hz (which is your
LVDS serializer frequency) and divides by 7 to 74250000 Hz which is your
LCDIF pixel clock.
This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it
is still in the imx8mp.dtsi . Therefore, to make your panel work at the
correct desired pixel clock frequency instead of some random one
inherited from imx8mp.dtsi, add the following to the pollux DT, I
believe that will fix the problem and is the correct fix:
&media_blk_ctrl {
// 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
// there is no need to multiply the clock by * 2
assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
<500000000>, <506800000>;
};
Can you please test whether this works and the pixel clock are accurate
in /sys/kernel/debug/clk/clk_summary ?
Now ... as for the LVDS serializer clock ... that is more complicated.
The LCDIF driver does its .atomic_enable first , configures the pixel
clock (and the Video PLL now) and enables the clock. The LVDS LDB
serializer driver does its .atomic_enable second and cannot reconfigure
the clock anymore, the Video PLL is stuck at /7 rate set by LCDIF driver
and won't budge because the clock are already enabled. I'm currently
trying to figure out if this can be improved somehow, but I believe that
would be material for next release.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-08 21:48 ` Marek Vasut
@ 2024-10-09 9:55 ` Isaac Scott
2024-10-09 15:47 ` Marek Vasut
2024-10-10 5:31 ` Liu Ying
1 sibling, 1 reply; 24+ messages in thread
From: Isaac Scott @ 2024-10-09 9:55 UTC (permalink / raw)
To: Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On Tue, 2024-10-08 at 23:48 +0200, Marek Vasut wrote:
> On 10/8/24 12:07 PM, Isaac Scott wrote:
> > On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
> > > On 10/7/24 7:01 PM, Isaac Scott wrote:
> > > > Hi Marek,
> > >
> > > Hi,
> > >
> > > > On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> > > > > On 6/24/24 11:19 AM, Alexander Stein wrote:
> > > > > > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek
> > > > > > Vasut:
> > > > > > > In case an upstream bridge modified the required clock
> > > > > > > frequency
> > > > > > > in its .atomic_check callback by setting
> > > > > > > adjusted_mode.clock
> > > > > > > ,
> > > > > > > make sure that clock frequency is generated by the
> > > > > > > LCDIFv3
> > > > > > > block.
> > > > > > >
> > > > > > > This is useful e.g. when LCDIFv3 feeds DSIM which feeds
> > > > > > > TC358767
> > > > > > > with (e)DP output, where the TC358767 expects precise
> > > > > > > timing
> > > > > > > on
> > > > > > > its input side, the precise timing must be generated by
> > > > > > > the
> > > > > > > LCDIF.
> > > > > > >
> > > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > >
> > > > > > With the other rc358767 patches in place, this does the
> > > > > > trick.
> > > > > > Reviewed-by: Alexander Stein
> > > > > > <alexander.stein@ew.tq-group.com>
> > > > >
> > > > > I'll pick this up next week if there is no objection.
> > > >
> > > > Unfortunately, this has caused a regression that is present in
> > > > v6.12-
> > > > rc1 on the i.MX8MP PHYTEC Pollux using the
> > > > arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts.
> > > > The
> > > > display is the edt,etml1010g3dra panel, as per the upstream
> > > > dts. We
> > > > bisected to this commit, and reverting this change fixed the
> > > > screen.
> > > >
> > > > We then tried to retest this on top of v6.12-rc2, and found we
> > > > also
> > > > had
> > > > to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155
> > > > ("clk:
> > > > imx:
> > > > clk-imx8mp: Allow media_disp pixel clock reconfigure parent
> > > > rate")
> > > > alongside this. Reverting these two commits makes the display
> > > > work
> > > > again at -rc2.
> > > >
> > > > Do you have any suggestions on anything we might be missing on
> > > > our
> > > > end?
> > > > Please let me know if there's anything you'd like me to test as
> > > > I'm
> > > > not
> > > > sure what the underlying fault was here.
> > > I believe what is going on is that the LCDIF cannot configure its
> > > upstream clock because something else is already using those
> > > clock
> > > and
> > > it set those clock to a specific frequency. LCDIF is now trying
> > > to
> > > configure those clock to match the LVDS panel, and it fails, so
> > > it
> > > tries
> > > to set some approximate clock and that is not good enough for the
> > > LVDS
> > > panel.
> > >
> > > Can you share dump of /sys/kernel/debug/clk/clk_summary on
> > > failing
> > > and
> > > working system ? You might see the difference around the "video"
> > > clock.
> > >
> > > (I have seen this behavior before, the fix was usually a matter
> > > of
> > > moving one of the LCDIFs to another upstream clock like PLL3, so
> > > it
> > > can
> > > pick well matching output clock instead of some horrid
> > > approximation
> > > which then drives the panel likely out of specification)
> >
> > Hi Marek,
> >
> > Please find attached the clk_summary for v6.12-rc2 before and after
> > the
> > reversion (the one after the reversion is 6.12-
> > rc2_summary_postfix).
> Thank you, this helped greatly.
>
> I believe I know why it used to kind-of work for you, but I'm afraid
> this used to work by sheer chance and it does not really work
> correctly
> for the panel you use, even if the panel likely does show the correct
> content. But, there is a way to make it work properly for the panel
> you use.
>
> First of all, the pixel clock never really matched the panel-simple.c
> pixel clock for the edt_etml1010g3dra_timing:
>
> $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
> media_disp2_pix 1 1 0 74250000 ...
> ^^^^^^^^
>
> $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-
> simple.c
> static const struct display_timing edt_etml1010g3dra_timing = {
> .pixelclock = { 66300000, 72400000, 78900000 },
> ^^^^^^^^
>
> The pixel clock are within tolerance, but there is a discrepancy
> 74250000 != 72400000 .
>
> Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB
> nodes")
> the IMX8MP_VIDEO_PLL1_OUT is set to a very specific frequency of
> 1039500000 Hz, which tidily divides by 2 to 519750000 Hz (which is
> your
> LVDS serializer frequency) and divides by 7 to 74250000 Hz which is
> your
> LCDIF pixel clock.
>
> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but
> it
> is still in the imx8mp.dtsi . Therefore, to make your panel work at
> the
> correct desired pixel clock frequency instead of some random one
> inherited from imx8mp.dtsi, add the following to the pollux DT, I
> believe that will fix the problem and is the correct fix:
>
> &media_blk_ctrl {
> // 506800000 = 72400000 * 7 (for single-link LVDS, this is
> enough)
> // there is no need to multiply the clock by * 2
> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
> <500000000>, <506800000>;
> };
>
> Can you please test whether this works and the pixel clock are
> accurate
> in /sys/kernel/debug/clk/clk_summary ?
Interestingly, after making the change you suggested to imx8mp-
phyboard-pollux-rdk.dts before the two reversions, the display now
seems to work. Please see below for the relevant section of the new
clk_summary referring to media_disp2_pix:
video_pll1_ref_sel 1 1 0 24000000
0 0 50000 Y deviceless
no_connection_id
video_pll1 1 1 0
506800000 0 0 50000 Y deviceless
no_connection_
video_pll1_bypass 1 1 0
506800000 0 0 50000 Y deviceless
no_connecti
video_pll1_out 2 2 0
506800000 0 0 50000 Y deviceless
no_conne
media_ldb 1 1 0
506800000 0 0 50000 Y deviceless
no_co
media_ldb_root_clk 1 1 0
506800000 0 0 50000 Y
32ec0000.blk-ctrl:bridge@5c l
deviceless no
media_disp2_pix 1 1 0 72400000
0 0 50000 Y deviceless
no_co
media_disp2_pix_root_clk 1 1 0
72400000 0 0 50000 Y
32e90000.display-controller
32ec0000.blk-ctrl di
deviceless no
media_disp1_pix 0 0 0
506800000 0 0 50000 N deviceless
no_co
media_disp1_pix_root_clk 0 0 0
506800000 0 0 50000 N
32ec0000.blk-ctrl
deviceless no
media_mipi_phy1_ref 0 0 0 23036364
0 0 50000 N deviceless
no_co
media_mipi_phy1_ref_root 0 0 0
23036364 0 0 50000 N
32ec0000.blk-ctrl
The media_disp2_pix clock now seems to be correct at 724000000 after
your changes.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-09 9:55 ` Isaac Scott
@ 2024-10-09 15:47 ` Marek Vasut
2024-10-09 15:58 ` Isaac Scott
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-10-09 15:47 UTC (permalink / raw)
To: Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/9/24 11:55 AM, Isaac Scott wrote:
> On Tue, 2024-10-08 at 23:48 +0200, Marek Vasut wrote:
>> On 10/8/24 12:07 PM, Isaac Scott wrote:
>>> On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
>>>> On 10/7/24 7:01 PM, Isaac Scott wrote:
>>>>> Hi Marek,
>>>>
>>>> Hi,
>>>>
>>>>> On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
>>>>>> On 6/24/24 11:19 AM, Alexander Stein wrote:
>>>>>>> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek
>>>>>>> Vasut:
>>>>>>>> In case an upstream bridge modified the required clock
>>>>>>>> frequency
>>>>>>>> in its .atomic_check callback by setting
>>>>>>>> adjusted_mode.clock
>>>>>>>> ,
>>>>>>>> make sure that clock frequency is generated by the
>>>>>>>> LCDIFv3
>>>>>>>> block.
>>>>>>>>
>>>>>>>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds
>>>>>>>> TC358767
>>>>>>>> with (e)DP output, where the TC358767 expects precise
>>>>>>>> timing
>>>>>>>> on
>>>>>>>> its input side, the precise timing must be generated by
>>>>>>>> the
>>>>>>>> LCDIF.
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>>
>>>>>>> With the other rc358767 patches in place, this does the
>>>>>>> trick.
>>>>>>> Reviewed-by: Alexander Stein
>>>>>>> <alexander.stein@ew.tq-group.com>
>>>>>>
>>>>>> I'll pick this up next week if there is no objection.
>>>>>
>>>>> Unfortunately, this has caused a regression that is present in
>>>>> v6.12-
>>>>> rc1 on the i.MX8MP PHYTEC Pollux using the
>>>>> arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts.
>>>>> The
>>>>> display is the edt,etml1010g3dra panel, as per the upstream
>>>>> dts. We
>>>>> bisected to this commit, and reverting this change fixed the
>>>>> screen.
>>>>>
>>>>> We then tried to retest this on top of v6.12-rc2, and found we
>>>>> also
>>>>> had
>>>>> to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155
>>>>> ("clk:
>>>>> imx:
>>>>> clk-imx8mp: Allow media_disp pixel clock reconfigure parent
>>>>> rate")
>>>>> alongside this. Reverting these two commits makes the display
>>>>> work
>>>>> again at -rc2.
>>>>>
>>>>> Do you have any suggestions on anything we might be missing on
>>>>> our
>>>>> end?
>>>>> Please let me know if there's anything you'd like me to test as
>>>>> I'm
>>>>> not
>>>>> sure what the underlying fault was here.
>>>> I believe what is going on is that the LCDIF cannot configure its
>>>> upstream clock because something else is already using those
>>>> clock
>>>> and
>>>> it set those clock to a specific frequency. LCDIF is now trying
>>>> to
>>>> configure those clock to match the LVDS panel, and it fails, so
>>>> it
>>>> tries
>>>> to set some approximate clock and that is not good enough for the
>>>> LVDS
>>>> panel.
>>>>
>>>> Can you share dump of /sys/kernel/debug/clk/clk_summary on
>>>> failing
>>>> and
>>>> working system ? You might see the difference around the "video"
>>>> clock.
>>>>
>>>> (I have seen this behavior before, the fix was usually a matter
>>>> of
>>>> moving one of the LCDIFs to another upstream clock like PLL3, so
>>>> it
>>>> can
>>>> pick well matching output clock instead of some horrid
>>>> approximation
>>>> which then drives the panel likely out of specification)
>>>
>>> Hi Marek,
>>>
>>> Please find attached the clk_summary for v6.12-rc2 before and after
>>> the
>>> reversion (the one after the reversion is 6.12-
>>> rc2_summary_postfix).
>> Thank you, this helped greatly.
>>
>> I believe I know why it used to kind-of work for you, but I'm afraid
>> this used to work by sheer chance and it does not really work
>> correctly
>> for the panel you use, even if the panel likely does show the correct
>> content. But, there is a way to make it work properly for the panel
>> you use.
>>
>> First of all, the pixel clock never really matched the panel-simple.c
>> pixel clock for the edt_etml1010g3dra_timing:
>>
>> $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
>> media_disp2_pix 1 1 0 74250000 ...
>> ^^^^^^^^
>>
>> $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-
>> simple.c
>> static const struct display_timing edt_etml1010g3dra_timing = {
>> .pixelclock = { 66300000, 72400000, 78900000 },
>> ^^^^^^^^
>>
>> The pixel clock are within tolerance, but there is a discrepancy
>> 74250000 != 72400000 .
>>
>> Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB
>> nodes")
>> the IMX8MP_VIDEO_PLL1_OUT is set to a very specific frequency of
>> 1039500000 Hz, which tidily divides by 2 to 519750000 Hz (which is
>> your
>> LVDS serializer frequency) and divides by 7 to 74250000 Hz which is
>> your
>> LCDIF pixel clock.
>>
>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but
>> it
>> is still in the imx8mp.dtsi . Therefore, to make your panel work at
>> the
>> correct desired pixel clock frequency instead of some random one
>> inherited from imx8mp.dtsi, add the following to the pollux DT, I
>> believe that will fix the problem and is the correct fix:
>>
>> &media_blk_ctrl {
>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is
>> enough)
>> // there is no need to multiply the clock by * 2
>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
>> <500000000>, <506800000>;
>> };
>>
>> Can you please test whether this works and the pixel clock are
>> accurate
>> in /sys/kernel/debug/clk/clk_summary ?
>
> Interestingly, after making the change you suggested to imx8mp-
> phyboard-pollux-rdk.dts before the two reversions, the display now
> seems to work. Please see below for the relevant section of the new
> clk_summary referring to media_disp2_pix:
>
> video_pll1_ref_sel 1 1 0 24000000
> 0 0 50000 Y deviceless
> no_connection_id
> video_pll1 1 1 0
> 506800000 0 0 50000 Y deviceless
> no_connection_
> video_pll1_bypass 1 1 0
> 506800000 0 0 50000 Y deviceless
> no_connecti
> video_pll1_out 2 2 0
> 506800000 0 0 50000 Y deviceless
> no_conne
> media_ldb 1 1 0
> 506800000 0 0 50000 Y deviceless
> no_co
> media_ldb_root_clk 1 1 0
> 506800000 0 0 50000 Y
> 32ec0000.blk-ctrl:bridge@5c l
>
> deviceless no
> media_disp2_pix 1 1 0 72400000
> 0 0 50000 Y deviceless
> no_co
> media_disp2_pix_root_clk 1 1 0
> 72400000 0 0 50000 Y
> 32e90000.display-controller
>
> 32ec0000.blk-ctrl di
>
> deviceless no
> media_disp1_pix 0 0 0
> 506800000 0 0 50000 N deviceless
> no_co
> media_disp1_pix_root_clk 0 0 0
> 506800000 0 0 50000 N
> 32ec0000.blk-ctrl
>
> deviceless no
> media_mipi_phy1_ref 0 0 0 23036364
> 0 0 50000 N deviceless
> no_co
> media_mipi_phy1_ref_root 0 0 0
> 23036364 0 0 50000 N
> 32ec0000.blk-ctrl
>
> The media_disp2_pix clock now seems to be correct at 724000000 after
> your changes.
Do you want to submit the DT patch with correct Fixes: tag ? :)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-09 15:47 ` Marek Vasut
@ 2024-10-09 15:58 ` Isaac Scott
2024-10-10 0:38 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Isaac Scott @ 2024-10-09 15:58 UTC (permalink / raw)
To: Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On Wed, 2024-10-09 at 17:47 +0200, Marek Vasut wrote:
> On 10/9/24 11:55 AM, Isaac Scott wrote:
> > On Tue, 2024-10-08 at 23:48 +0200, Marek Vasut wrote:
> > > On 10/8/24 12:07 PM, Isaac Scott wrote:
> > > > On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
> > > > > On 10/7/24 7:01 PM, Isaac Scott wrote:
> > > > > > Hi Marek,
> > > > >
> > > > > Hi,
> > > > >
> > > > > > On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> > > > > > > On 6/24/24 11:19 AM, Alexander Stein wrote:
> > > > > > > > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek
> > > > > > > > Vasut:
> > > > > > > > > In case an upstream bridge modified the required
> > > > > > > > > clock
> > > > > > > > > frequency
> > > > > > > > > in its .atomic_check callback by setting
> > > > > > > > > adjusted_mode.clock
> > > > > > > > > ,
> > > > > > > > > make sure that clock frequency is generated by the
> > > > > > > > > LCDIFv3
> > > > > > > > > block.
> > > > > > > > >
> > > > > > > > > This is useful e.g. when LCDIFv3 feeds DSIM which
> > > > > > > > > feeds
> > > > > > > > > TC358767
> > > > > > > > > with (e)DP output, where the TC358767 expects precise
> > > > > > > > > timing
> > > > > > > > > on
> > > > > > > > > its input side, the precise timing must be generated
> > > > > > > > > by
> > > > > > > > > the
> > > > > > > > > LCDIF.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > > >
> > > > > > > > With the other rc358767 patches in place, this does the
> > > > > > > > trick.
> > > > > > > > Reviewed-by: Alexander Stein
> > > > > > > > <alexander.stein@ew.tq-group.com>
> > > > > > >
> > > > > > > I'll pick this up next week if there is no objection.
> > > > > >
> > > > > > Unfortunately, this has caused a regression that is present
> > > > > > in
> > > > > > v6.12-
> > > > > > rc1 on the i.MX8MP PHYTEC Pollux using the
> > > > > > arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-
> > > > > > rdk.dts.
> > > > > > The
> > > > > > display is the edt,etml1010g3dra panel, as per the upstream
> > > > > > dts. We
> > > > > > bisected to this commit, and reverting this change fixed
> > > > > > the
> > > > > > screen.
> > > > > >
> > > > > > We then tried to retest this on top of v6.12-rc2, and found
> > > > > > we
> > > > > > also
> > > > > > had
> > > > > > to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155
> > > > > > ("clk:
> > > > > > imx:
> > > > > > clk-imx8mp: Allow media_disp pixel clock reconfigure parent
> > > > > > rate")
> > > > > > alongside this. Reverting these two commits makes the
> > > > > > display
> > > > > > work
> > > > > > again at -rc2.
> > > > > >
> > > > > > Do you have any suggestions on anything we might be missing
> > > > > > on
> > > > > > our
> > > > > > end?
> > > > > > Please let me know if there's anything you'd like me to
> > > > > > test as
> > > > > > I'm
> > > > > > not
> > > > > > sure what the underlying fault was here.
> > > > > I believe what is going on is that the LCDIF cannot configure
> > > > > its
> > > > > upstream clock because something else is already using those
> > > > > clock
> > > > > and
> > > > > it set those clock to a specific frequency. LCDIF is now
> > > > > trying
> > > > > to
> > > > > configure those clock to match the LVDS panel, and it fails,
> > > > > so
> > > > > it
> > > > > tries
> > > > > to set some approximate clock and that is not good enough for
> > > > > the
> > > > > LVDS
> > > > > panel.
> > > > >
> > > > > Can you share dump of /sys/kernel/debug/clk/clk_summary on
> > > > > failing
> > > > > and
> > > > > working system ? You might see the difference around the
> > > > > "video"
> > > > > clock.
> > > > >
> > > > > (I have seen this behavior before, the fix was usually a
> > > > > matter
> > > > > of
> > > > > moving one of the LCDIFs to another upstream clock like PLL3,
> > > > > so
> > > > > it
> > > > > can
> > > > > pick well matching output clock instead of some horrid
> > > > > approximation
> > > > > which then drives the panel likely out of specification)
> > > >
> > > > Hi Marek,
> > > >
> > > > Please find attached the clk_summary for v6.12-rc2 before and
> > > > after
> > > > the
> > > > reversion (the one after the reversion is 6.12-
> > > > rc2_summary_postfix).
> > > Thank you, this helped greatly.
> > >
> > > I believe I know why it used to kind-of work for you, but I'm
> > > afraid
> > > this used to work by sheer chance and it does not really work
> > > correctly
> > > for the panel you use, even if the panel likely does show the
> > > correct
> > > content. But, there is a way to make it work properly for the
> > > panel
> > > you use.
> > >
> > > First of all, the pixel clock never really matched the panel-
> > > simple.c
> > > pixel clock for the edt_etml1010g3dra_timing:
> > >
> > > $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
> > > media_disp2_pix 1 1 0 74250000 ...
> > > ^^^^^^^^
> > >
> > > $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-
> > > simple.c
> > > static const struct display_timing edt_etml1010g3dra_timing = {
> > > .pixelclock = { 66300000, 72400000, 78900000 },
> > > ^^^^^^^^
> > >
> > > The pixel clock are within tolerance, but there is a discrepancy
> > > 74250000 != 72400000 .
> > >
> > > Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB
> > > nodes")
> > > the IMX8MP_VIDEO_PLL1_OUT is set to a very specific frequency of
> > > 1039500000 Hz, which tidily divides by 2 to 519750000 Hz (which
> > > is
> > > your
> > > LVDS serializer frequency) and divides by 7 to 74250000 Hz which
> > > is
> > > your
> > > LCDIF pixel clock.
> > >
> > > This Video PLL1 configuration since moved to &media_blk_ctrl {} ,
> > > but
> > > it
> > > is still in the imx8mp.dtsi . Therefore, to make your panel work
> > > at
> > > the
> > > correct desired pixel clock frequency instead of some random one
> > > inherited from imx8mp.dtsi, add the following to the pollux DT, I
> > > believe that will fix the problem and is the correct fix:
> > >
> > > &media_blk_ctrl {
> > > // 506800000 = 72400000 * 7 (for single-link LVDS, this is
> > > enough)
> > > // there is no need to multiply the clock by * 2
> > > assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
> > > <500000000>, <506800000>;
> > > };
> > >
> > > Can you please test whether this works and the pixel clock are
> > > accurate
> > > in /sys/kernel/debug/clk/clk_summary ?
> >
> > Interestingly, after making the change you suggested to imx8mp-
> > phyboard-pollux-rdk.dts before the two reversions, the display now
> > seems to work. Please see below for the relevant section of the new
> > clk_summary referring to media_disp2_pix:
> >
> > video_pll1_ref_sel 1 1 0 24000000
> > 0 0 50000 Y deviceless
> > no_connection_id
> > video_pll1 1 1 0
> > 506800000 0 0 50000 Y deviceless
> > no_connection_
> > video_pll1_bypass 1 1 0
> > 506800000 0 0 50000 Y deviceless
> > no_connecti
> > video_pll1_out 2 2 0
> > 506800000 0 0 50000 Y deviceless
> > no_conne
> > media_ldb 1 1 0
> > 506800000 0 0 50000 Y
> > deviceless
> > no_co
> > media_ldb_root_clk 1 1 0
> > 506800000 0 0 50000 Y
> > 32ec0000.blk-ctrl:bridge@5c l
> >
> >
> > deviceless no
> > media_disp2_pix 1 1 0
> > 72400000
> > 0 0 50000 Y deviceless
> > no_co
> > media_disp2_pix_root_clk 1 1 0
> > 72400000 0 0 50000 Y
> > 32e90000.display-controller
> >
> >
> > 32ec0000.blk-ctrl di
> >
> >
> > deviceless no
> > media_disp1_pix 0 0 0
> > 506800000 0 0 50000 N
> > deviceless
> > no_co
> > media_disp1_pix_root_clk 0 0 0
> > 506800000 0 0 50000 N
> > 32ec0000.blk-ctrl
> >
> >
> > deviceless no
> > media_mipi_phy1_ref 0 0 0
> > 23036364
> > 0 0 50000 N deviceless
> > no_co
> > media_mipi_phy1_ref_root 0 0 0
> > 23036364 0 0 50000 N
> > 32ec0000.blk-ctrl
> >
> > The media_disp2_pix clock now seems to be correct at 724000000
> > after
> > your changes.
>
> Do you want to submit the DT patch with correct Fixes: tag ? :)
I thought this wasn't needed with the other two patches?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-09 15:58 ` Isaac Scott
@ 2024-10-10 0:38 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-10 0:38 UTC (permalink / raw)
To: Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/9/24 5:58 PM, Isaac Scott wrote:
[...]
>>> media_mipi_phy1_ref 0 0 0
>>> 23036364
>>> 0 0 50000 N deviceless
>>> no_co
>>> media_mipi_phy1_ref_root 0 0 0
>>> 23036364 0 0 50000 N
>>> 32ec0000.blk-ctrl
>>>
>>> The media_disp2_pix clock now seems to be correct at 724000000
>>> after
>>> your changes.
>>
>> Do you want to submit the DT patch with correct Fixes: tag ? :)
>
> I thought this wasn't needed with the other two patches?
The DT change is not needed with the other patches, however, I believe
the DT change is the correct fix for current Linux 6.12-rc and the two
patches are feature development for the Linux 6.13.y cycle.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-08 21:48 ` Marek Vasut
2024-10-09 9:55 ` Isaac Scott
@ 2024-10-10 5:31 ` Liu Ying
2024-10-10 15:54 ` Isaac Scott
2024-10-10 17:29 ` Marek Vasut
1 sibling, 2 replies; 24+ messages in thread
From: Liu Ying @ 2024-10-10 5:31 UTC (permalink / raw)
To: Marek Vasut, Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/09/2024, Marek Vasut wrote:
> On 10/8/24 12:07 PM, Isaac Scott wrote:
>> On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
>>> On 10/7/24 7:01 PM, Isaac Scott wrote:
>>>> Hi Marek,
>>>
>>> Hi,
>>>
>>>> On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
>>>>> On 6/24/24 11:19 AM, Alexander Stein wrote:
>>>>>> Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
>>>>>>> In case an upstream bridge modified the required clock
>>>>>>> frequency
>>>>>>> in its .atomic_check callback by setting adjusted_mode.clock
>>>>>>> ,
>>>>>>> make sure that clock frequency is generated by the LCDIFv3
>>>>>>> block.
>>>>>>>
>>>>>>> This is useful e.g. when LCDIFv3 feeds DSIM which feeds
>>>>>>> TC358767
>>>>>>> with (e)DP output, where the TC358767 expects precise timing
>>>>>>> on
>>>>>>> its input side, the precise timing must be generated by the
>>>>>>> LCDIF.
>>>>>>>
>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>
>>>>>> With the other rc358767 patches in place, this does the trick.
>>>>>> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>>>>>
>>>>> I'll pick this up next week if there is no objection.
>>>>
>>>> Unfortunately, this has caused a regression that is present in
>>>> v6.12-
>>>> rc1 on the i.MX8MP PHYTEC Pollux using the
>>>> arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts. The
>>>> display is the edt,etml1010g3dra panel, as per the upstream dts. We
>>>> bisected to this commit, and reverting this change fixed the
>>>> screen.
>>>>
>>>> We then tried to retest this on top of v6.12-rc2, and found we also
>>>> had
>>>> to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155 ("clk:
>>>> imx:
>>>> clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")
>>>> alongside this. Reverting these two commits makes the display work
>>>> again at -rc2.
>>>>
>>>> Do you have any suggestions on anything we might be missing on our
>>>> end?
>>>> Please let me know if there's anything you'd like me to test as I'm
>>>> not
>>>> sure what the underlying fault was here.
>>> I believe what is going on is that the LCDIF cannot configure its
>>> upstream clock because something else is already using those clock
>>> and
>>> it set those clock to a specific frequency. LCDIF is now trying to
>>> configure those clock to match the LVDS panel, and it fails, so it
>>> tries
>>> to set some approximate clock and that is not good enough for the
>>> LVDS
>>> panel.
>>>
>>> Can you share dump of /sys/kernel/debug/clk/clk_summary on failing
>>> and
>>> working system ? You might see the difference around the "video"
>>> clock.
>>>
>>> (I have seen this behavior before, the fix was usually a matter of
>>> moving one of the LCDIFs to another upstream clock like PLL3, so it
>>> can
>>> pick well matching output clock instead of some horrid approximation
>>> which then drives the panel likely out of specification)
>>
>> Hi Marek,
>>
>> Please find attached the clk_summary for v6.12-rc2 before and after the
>> reversion (the one after the reversion is 6.12-rc2_summary_postfix).
> Thank you, this helped greatly.
>
> I believe I know why it used to kind-of work for you, but I'm afraid this used to work by sheer chance and it does not really work correctly for the panel you use, even if the panel likely does show the correct content. But, there is a way to make it work properly for the panel you use.
>
> First of all, the pixel clock never really matched the panel-simple.c pixel clock for the edt_etml1010g3dra_timing:
>
> $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
> media_disp2_pix 1 1 0 74250000 ...
> ^^^^^^^^
>
> $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-simple.c
> static const struct display_timing edt_etml1010g3dra_timing = {
> .pixelclock = { 66300000, 72400000, 78900000 },
> ^^^^^^^^
>
> The pixel clock are within tolerance, but there is a discrepancy 74250000 != 72400000 .
>
> Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB nodes") the IMX8MP_VIDEO_PLL1_OUT is set to a very specific frequency of 1039500000 Hz, which tidily divides by 2 to 519750000 Hz (which is your LVDS serializer frequency) and divides by 7 to 74250000 Hz which is your LCDIF pixel clock.
>
> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>
> &media_blk_ctrl {
> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
> // there is no need to multiply the clock by * 2
> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
This assigns "video_pll1" clock rate to 506.8MHz which is currently not
listed in imx_pll1443x_tbl[].
Does the below patch[1] fix the regression issue? It explicitly sets
the clock frequency of the panel timing to 74.25MHz.
[1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> };
>
> Can you please test whether this works and the pixel clock are accurate in /sys/kernel/debug/clk/clk_summary ?
>
> Now ... as for the LVDS serializer clock ... that is more complicated.
>
> The LCDIF driver does its .atomic_enable first , configures the pixel clock (and the Video PLL now) and enables the clock. The LVDS LDB serializer driver does its .atomic_enable second and cannot reconfigure the clock anymore, the Video PLL is stuck at /7 rate set by LCDIF driver and won't budge because the clock are already enabled. I'm currently trying to figure out if this can be improved somehow, but I believe that would be material for next release.
>
--
Regards,
Liu Ying
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-10 5:31 ` Liu Ying
@ 2024-10-10 15:54 ` Isaac Scott
2024-10-10 16:02 ` Isaac Scott
2024-10-10 17:29 ` Marek Vasut
1 sibling, 1 reply; 24+ messages in thread
From: Isaac Scott @ 2024-10-10 15:54 UTC (permalink / raw)
To: Liu Ying, Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On Thu, 2024-10-10 at 13:31 +0800, Liu Ying wrote:
> On 10/09/2024, Marek Vasut wrote:
> > On 10/8/24 12:07 PM, Isaac Scott wrote:
> > > On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
> > > > On 10/7/24 7:01 PM, Isaac Scott wrote:
> > > > > Hi Marek,
> > > >
> > > > Hi,
> > > >
> > > > > On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> > > > > > On 6/24/24 11:19 AM, Alexander Stein wrote:
> > > > > > > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek
> > > > > > > Vasut:
> > > > > > > > In case an upstream bridge modified the required clock
> > > > > > > > frequency
> > > > > > > > in its .atomic_check callback by setting
> > > > > > > > adjusted_mode.clock
> > > > > > > > ,
> > > > > > > > make sure that clock frequency is generated by the
> > > > > > > > LCDIFv3
> > > > > > > > block.
> > > > > > > >
> > > > > > > > This is useful e.g. when LCDIFv3 feeds DSIM which feeds
> > > > > > > > TC358767
> > > > > > > > with (e)DP output, where the TC358767 expects precise
> > > > > > > > timing
> > > > > > > > on
> > > > > > > > its input side, the precise timing must be generated by
> > > > > > > > the
> > > > > > > > LCDIF.
> > > > > > > >
> > > > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > >
> > > > > > > With the other rc358767 patches in place, this does the
> > > > > > > trick.
> > > > > > > Reviewed-by: Alexander Stein
> > > > > > > <alexander.stein@ew.tq-group.com>
> > > > > >
> > > > > > I'll pick this up next week if there is no objection.
> > > > >
> > > > > Unfortunately, this has caused a regression that is present
> > > > > in
> > > > > v6.12-
> > > > > rc1 on the i.MX8MP PHYTEC Pollux using the
> > > > > arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts.
> > > > > The
> > > > > display is the edt,etml1010g3dra panel, as per the upstream
> > > > > dts. We
> > > > > bisected to this commit, and reverting this change fixed the
> > > > > screen.
> > > > >
> > > > > We then tried to retest this on top of v6.12-rc2, and found
> > > > > we also
> > > > > had
> > > > > to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155
> > > > > ("clk:
> > > > > imx:
> > > > > clk-imx8mp: Allow media_disp pixel clock reconfigure parent
> > > > > rate")
> > > > > alongside this. Reverting these two commits makes the display
> > > > > work
> > > > > again at -rc2.
> > > > >
> > > > > Do you have any suggestions on anything we might be missing
> > > > > on our
> > > > > end?
> > > > > Please let me know if there's anything you'd like me to test
> > > > > as I'm
> > > > > not
> > > > > sure what the underlying fault was here.
> > > > I believe what is going on is that the LCDIF cannot configure
> > > > its
> > > > upstream clock because something else is already using those
> > > > clock
> > > > and
> > > > it set those clock to a specific frequency. LCDIF is now trying
> > > > to
> > > > configure those clock to match the LVDS panel, and it fails, so
> > > > it
> > > > tries
> > > > to set some approximate clock and that is not good enough for
> > > > the
> > > > LVDS
> > > > panel.
> > > >
> > > > Can you share dump of /sys/kernel/debug/clk/clk_summary on
> > > > failing
> > > > and
> > > > working system ? You might see the difference around the
> > > > "video"
> > > > clock.
> > > >
> > > > (I have seen this behavior before, the fix was usually a matter
> > > > of
> > > > moving one of the LCDIFs to another upstream clock like PLL3,
> > > > so it
> > > > can
> > > > pick well matching output clock instead of some horrid
> > > > approximation
> > > > which then drives the panel likely out of specification)
> > >
> > > Hi Marek,
> > >
> > > Please find attached the clk_summary for v6.12-rc2 before and
> > > after the
> > > reversion (the one after the reversion is 6.12-
> > > rc2_summary_postfix).
> > Thank you, this helped greatly.
> >
> > I believe I know why it used to kind-of work for you, but I'm
> > afraid this used to work by sheer chance and it does not really
> > work correctly for the panel you use, even if the panel likely does
> > show the correct content. But, there is a way to make it work
> > properly for the panel you use.
> >
> > First of all, the pixel clock never really matched the panel-
> > simple.c pixel clock for the edt_etml1010g3dra_timing:
> >
> > $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
> > media_disp2_pix 1 1 0 74250000 ...
> > ^^^^^^^^
> >
> > $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-
> > simple.c
> > static const struct display_timing edt_etml1010g3dra_timing = {
> > .pixelclock = { 66300000, 72400000, 78900000 },
> > ^^^^^^^^
> >
> > The pixel clock are within tolerance, but there is a discrepancy
> > 74250000 != 72400000 .
> >
> > Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB
> > nodes") the IMX8MP_VIDEO_PLL1_OUT is set to a very specific
> > frequency of 1039500000 Hz, which tidily divides by 2 to 519750000
> > Hz (which is your LVDS serializer frequency) and divides by 7 to
> > 74250000 Hz which is your LCDIF pixel clock.
> >
> > This Video PLL1 configuration since moved to &media_blk_ctrl {} ,
> > but it is still in the imx8mp.dtsi . Therefore, to make your panel
> > work at the correct desired pixel clock frequency instead of some
> > random one inherited from imx8mp.dtsi, add the following to the
> > pollux DT, I believe that will fix the problem and is the correct
> > fix:
> >
> > &media_blk_ctrl {
> > // 506800000 = 72400000 * 7 (for single-link LVDS, this is
> > enough)
> > // there is no need to multiply the clock by * 2
> > assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
> > <500000000>, <506800000>;
>
> This assigns "video_pll1" clock rate to 506.8MHz which is currently
> not
> listed in imx_pll1443x_tbl[].
>
> Does the below patch[1] fix the regression issue? It explicitly sets
> the clock frequency of the panel timing to 74.25MHz.
>
> [1]
> https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
>
> > };
> >
> > Can you please test whether this works and the pixel clock are
> > accurate in /sys/kernel/debug/clk/clk_summary ?
> >
> > Now ... as for the LVDS serializer clock ... that is more
> > complicated.
> >
> > The LCDIF driver does its .atomic_enable first , configures the
> > pixel clock (and the Video PLL now) and enables the clock. The LVDS
> > LDB serializer driver does its .atomic_enable second and cannot
> > reconfigure the clock anymore, the Video PLL is stuck at /7 rate
> > set by LCDIF driver and won't budge because the clock are already
> > enabled. I'm currently trying to figure out if this can be improved
> > somehow, but I believe that would be material for next release.
> >
>
This patch also fixes the regression!
Tested-by: Isaac Scott <isaac.scott@ideasonboard.com>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-10 15:54 ` Isaac Scott
@ 2024-10-10 16:02 ` Isaac Scott
0 siblings, 0 replies; 24+ messages in thread
From: Isaac Scott @ 2024-10-10 16:02 UTC (permalink / raw)
To: Liu Ying, Marek Vasut, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On Thu, 2024-10-10 at 16:54 +0100, Isaac Scott wrote:
To be clear, my reply applies to the patch referenced by [1]
Tested-by: Isaac Scott <isaac.scott@ideasonboard.com>
> On Thu, 2024-10-10 at 13:31 +0800, Liu Ying wrote:
> > On 10/09/2024, Marek Vasut wrote:
> > > On 10/8/24 12:07 PM, Isaac Scott wrote:
> > > > On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
> > > > > On 10/7/24 7:01 PM, Isaac Scott wrote:
> > > > > > Hi Marek,
> > > > >
> > > > > Hi,
> > > > >
> > > > > > On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
> > > > > > > On 6/24/24 11:19 AM, Alexander Stein wrote:
> > > > > > > > Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek
> > > > > > > > Vasut:
> > > > > > > > > In case an upstream bridge modified the required
> > > > > > > > > clock
> > > > > > > > > frequency
> > > > > > > > > in its .atomic_check callback by setting
> > > > > > > > > adjusted_mode.clock
> > > > > > > > > ,
> > > > > > > > > make sure that clock frequency is generated by the
> > > > > > > > > LCDIFv3
> > > > > > > > > block.
> > > > > > > > >
> > > > > > > > > This is useful e.g. when LCDIFv3 feeds DSIM which
> > > > > > > > > feeds
> > > > > > > > > TC358767
> > > > > > > > > with (e)DP output, where the TC358767 expects precise
> > > > > > > > > timing
> > > > > > > > > on
> > > > > > > > > its input side, the precise timing must be generated
> > > > > > > > > by
> > > > > > > > > the
> > > > > > > > > LCDIF.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > > >
> > > > > > > > With the other rc358767 patches in place, this does the
> > > > > > > > trick.
> > > > > > > > Reviewed-by: Alexander Stein
> > > > > > > > <alexander.stein@ew.tq-group.com>
> > > > > > >
> > > > > > > I'll pick this up next week if there is no objection.
> > > > > >
> > > > > > Unfortunately, this has caused a regression that is present
> > > > > > in
> > > > > > v6.12-
> > > > > > rc1 on the i.MX8MP PHYTEC Pollux using the
> > > > > > arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-
> > > > > > rdk.dts.
> > > > > > The
> > > > > > display is the edt,etml1010g3dra panel, as per the upstream
> > > > > > dts. We
> > > > > > bisected to this commit, and reverting this change fixed
> > > > > > the
> > > > > > screen.
> > > > > >
> > > > > > We then tried to retest this on top of v6.12-rc2, and found
> > > > > > we also
> > > > > > had
> > > > > > to revert commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155
> > > > > > ("clk:
> > > > > > imx:
> > > > > > clk-imx8mp: Allow media_disp pixel clock reconfigure parent
> > > > > > rate")
> > > > > > alongside this. Reverting these two commits makes the
> > > > > > display
> > > > > > work
> > > > > > again at -rc2.
> > > > > >
> > > > > > Do you have any suggestions on anything we might be missing
> > > > > > on our
> > > > > > end?
> > > > > > Please let me know if there's anything you'd like me to
> > > > > > test
> > > > > > as I'm
> > > > > > not
> > > > > > sure what the underlying fault was here.
> > > > > I believe what is going on is that the LCDIF cannot configure
> > > > > its
> > > > > upstream clock because something else is already using those
> > > > > clock
> > > > > and
> > > > > it set those clock to a specific frequency. LCDIF is now
> > > > > trying
> > > > > to
> > > > > configure those clock to match the LVDS panel, and it fails,
> > > > > so
> > > > > it
> > > > > tries
> > > > > to set some approximate clock and that is not good enough for
> > > > > the
> > > > > LVDS
> > > > > panel.
> > > > >
> > > > > Can you share dump of /sys/kernel/debug/clk/clk_summary on
> > > > > failing
> > > > > and
> > > > > working system ? You might see the difference around the
> > > > > "video"
> > > > > clock.
> > > > >
> > > > > (I have seen this behavior before, the fix was usually a
> > > > > matter
> > > > > of
> > > > > moving one of the LCDIFs to another upstream clock like PLL3,
> > > > > so it
> > > > > can
> > > > > pick well matching output clock instead of some horrid
> > > > > approximation
> > > > > which then drives the panel likely out of specification)
> > > >
> > > > Hi Marek,
> > > >
> > > > Please find attached the clk_summary for v6.12-rc2 before and
> > > > after the
> > > > reversion (the one after the reversion is 6.12-
> > > > rc2_summary_postfix).
> > > Thank you, this helped greatly.
> > >
> > > I believe I know why it used to kind-of work for you, but I'm
> > > afraid this used to work by sheer chance and it does not really
> > > work correctly for the panel you use, even if the panel likely
> > > does
> > > show the correct content. But, there is a way to make it work
> > > properly for the panel you use.
> > >
> > > First of all, the pixel clock never really matched the panel-
> > > simple.c pixel clock for the edt_etml1010g3dra_timing:
> > >
> > > $ grep '\<media_disp2_pix\>' 6.12-rc2_summary_postfix
> > > media_disp2_pix 1 1 0 74250000 ...
> > > ^^^^^^^^
> > >
> > > $ grep -A 1 edt_etml1010g3dra_timing drivers/gpu/drm/panel/panel-
> > > simple.c
> > > static const struct display_timing edt_etml1010g3dra_timing = {
> > > .pixelclock = { 66300000, 72400000, 78900000 },
> > > ^^^^^^^^
> > >
> > > The pixel clock are within tolerance, but there is a discrepancy
> > > 74250000 != 72400000 .
> > >
> > > Since commit 94e6197dadc9 ("arm64: dts: imx8mp: Add LCDIF2 & LDB
> > > nodes") the IMX8MP_VIDEO_PLL1_OUT is set to a very specific
> > > frequency of 1039500000 Hz, which tidily divides by 2 to
> > > 519750000
> > > Hz (which is your LVDS serializer frequency) and divides by 7 to
> > > 74250000 Hz which is your LCDIF pixel clock.
> > >
> > > This Video PLL1 configuration since moved to &media_blk_ctrl {} ,
> > > but it is still in the imx8mp.dtsi . Therefore, to make your
> > > panel
> > > work at the correct desired pixel clock frequency instead of some
> > > random one inherited from imx8mp.dtsi, add the following to the
> > > pollux DT, I believe that will fix the problem and is the correct
> > > fix:
> > >
> > > &media_blk_ctrl {
> > > // 506800000 = 72400000 * 7 (for single-link LVDS, this is
> > > enough)
> > > // there is no need to multiply the clock by * 2
> > > assigned-clock-rates = <500000000>, <200000000>, <0>, <0>,
> > > <500000000>, <506800000>;
> >
> > This assigns "video_pll1" clock rate to 506.8MHz which is currently
> > not
> > listed in imx_pll1443x_tbl[].
> >
> > Does the below patch[1] fix the regression issue? It explicitly
> > sets
> > the clock frequency of the panel timing to 74.25MHz.
> >
> > [1]
> > https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> >
> > > };
> > >
> > > Can you please test whether this works and the pixel clock are
> > > accurate in /sys/kernel/debug/clk/clk_summary ?
> > >
> > > Now ... as for the LVDS serializer clock ... that is more
> > > complicated.
> > >
> > > The LCDIF driver does its .atomic_enable first , configures the
> > > pixel clock (and the Video PLL now) and enables the clock. The
> > > LVDS
> > > LDB serializer driver does its .atomic_enable second and cannot
> > > reconfigure the clock anymore, the Video PLL is stuck at /7 rate
> > > set by LCDIF driver and won't budge because the clock are already
> > > enabled. I'm currently trying to figure out if this can be
> > > improved
> > > somehow, but I believe that would be material for next release.
> > >
> >
>
> This patch also fixes the regression!
> Tested-by: Isaac Scott <isaac.scott@ideasonboard.com>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-10 5:31 ` Liu Ying
2024-10-10 15:54 ` Isaac Scott
@ 2024-10-10 17:29 ` Marek Vasut
2024-10-11 3:10 ` Liu Ying
1 sibling, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-10-10 17:29 UTC (permalink / raw)
To: Liu Ying, Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/10/24 7:31 AM, Liu Ying wrote:
Hi,
>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>
>> &media_blk_ctrl {
>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>> // there is no need to multiply the clock by * 2
>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>
> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
> listed in imx_pll1443x_tbl[].
Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates")
the 1443x PLLs can be configured to arbitrary rates which for video PLL
is desirable as those should produce accurate clock.
> Does the below patch[1] fix the regression issue? It explicitly sets
> the clock frequency of the panel timing to 74.25MHz.
>
> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
That patch is wrong, there is an existing entry for this panel in
panel-simple.c which is correct and precise, please do not add that kind
of imprecise duplicate timings into DT.
[...]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-10 17:29 ` Marek Vasut
@ 2024-10-11 3:10 ` Liu Ying
2024-10-12 20:37 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Liu Ying @ 2024-10-11 3:10 UTC (permalink / raw)
To: Marek Vasut, Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/11/2024, Marek Vasut wrote:
> On 10/10/24 7:31 AM, Liu Ying wrote:
>
> Hi,
Hi,
>
>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>>
>>> &media_blk_ctrl {
>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>> // there is no need to multiply the clock by * 2
>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>
>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>> listed in imx_pll1443x_tbl[].
>
> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
Ack.
>
>> Does the below patch[1] fix the regression issue? It explicitly sets
>> the clock frequency of the panel timing to 74.25MHz.
>>
>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
At least the patch[1] is legitimate now to override the display
timing of the panel because the override mode is something
panel-simple.c supports. And, pixel clock @74.25MHz is not out
of the panel specification since edt_etml1010g3dra_timing
indicates the minimum as 66.3MHz and the maximum as 78.9MHz.
Furthermore, if "PHYTEC phyBOARD-Pollux i.MX8MP" also supports
something like MIPI DSI to HDMI, then 74.25MHz panel pixel clock
rate is more desirable because the LVDS display and the MIPI DSI
display pipeline with typical 148.5MHz/74.25MHz pixel clock rates
may use one single "video_pll1" clock.
Anyway, I think it is ok to use the patch[1] or assigning
"video_pll1" clock rate to 506.8MHz in DT(no things like MIPI
DSI to HDMI in existing DT).
>
> [...]
--
Regards,
Liu Ying
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-11 3:10 ` Liu Ying
@ 2024-10-12 20:37 ` Marek Vasut
2024-10-19 21:49 ` Kieran Bingham
0 siblings, 1 reply; 24+ messages in thread
From: Marek Vasut @ 2024-10-12 20:37 UTC (permalink / raw)
To: Liu Ying, Isaac Scott, Alexander Stein, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel, kieran.bingham
On 10/11/24 5:10 AM, Liu Ying wrote:
Hi,
>>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>>>
>>>> &media_blk_ctrl {
>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>>> // there is no need to multiply the clock by * 2
>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>>
>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>>> listed in imx_pll1443x_tbl[].
>>
>> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
>
> Ack.
>
>>
>>> Does the below patch[1] fix the regression issue? It explicitly sets
>>> the clock frequency of the panel timing to 74.25MHz.
>>>
>>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
>> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
>
> At least the patch[1] is legitimate now to override the display
> timing of the panel because the override mode is something
> panel-simple.c supports.
It may be possible to override the mode, but why would this be the
desired if the panel-simple.c already contains valid accurate timings
for this particular panel ?
> And, pixel clock @74.25MHz is not out
> of the panel specification since edt_etml1010g3dra_timing
> indicates the minimum as 66.3MHz and the maximum as 78.9MHz.
The panel-simple.c already contains timings for this panel, which are
accurate and follow the panel datasheet. If the goal here is to support
approximate panel timings between the currently available three options
(min/typ/max) listed in panel-simple, then that is another discussion
for another patch.
> Furthermore, if "PHYTEC phyBOARD-Pollux i.MX8MP" also supports
> something like MIPI DSI to HDMI, then 74.25MHz panel pixel clock
> rate is more desirable because the LVDS display and the MIPI DSI
> display pipeline with typical 148.5MHz/74.25MHz pixel clock rates
> may use one single "video_pll1" clock.
I actually do have exactly this use case on one system -- one LVDS panel
and one MIPI DSI panel -- the solution is really easy, source the LVDS
pixel clock from Video PLL and the DSI clock from e.g. PLL3 .
> Anyway, I think it is ok to use the patch[1] or assigning
> "video_pll1" clock rate to 506.8MHz in DT(no things like MIPI
> DSI to HDMI in existing DT).
I believe for the current release, it is better to update the Video PLL
clock in this one board DT, because that is minimum impact change
isolated to this board and fixes a real issue where the LVDS panel
worked within specification only by sheer chance.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-12 20:37 ` Marek Vasut
@ 2024-10-19 21:49 ` Kieran Bingham
2024-10-20 2:49 ` Marek Vasut
0 siblings, 1 reply; 24+ messages in thread
From: Kieran Bingham @ 2024-10-19 21:49 UTC (permalink / raw)
To: Alexander Stein, Isaac Scott, Liu Ying, Marek Vasut, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F . Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
Quoting Marek Vasut (2024-10-12 21:37:59)
> On 10/11/24 5:10 AM, Liu Ying wrote:
>
> Hi,
>
> >>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
> >>>>
> >>>> &media_blk_ctrl {
> >>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
> >>>> // there is no need to multiply the clock by * 2
> >>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
> >>>
> >>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
> >>> listed in imx_pll1443x_tbl[].
> >>
> >> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
> >
> > Ack.
> >
> >>
> >>> Does the below patch[1] fix the regression issue? It explicitly sets
> >>> the clock frequency of the panel timing to 74.25MHz.
> >>>
> >>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> >> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
> >
> > At least the patch[1] is legitimate now to override the display
> > timing of the panel because the override mode is something
> > panel-simple.c supports.
>
> It may be possible to override the mode, but why would this be the
> desired if the panel-simple.c already contains valid accurate timings
> for this particular panel ?
I'm confused a little here. Why is it that setting the panel timings in
the DT as per [1] make the display work, while the panel timeings in
panel-simple alone are not enough?
Is there some difference in code path for 'how' the panel timings are
set as to whether they will apply fully or not ?
--
Kieran
>
> > And, pixel clock @74.25MHz is not out
> > of the panel specification since edt_etml1010g3dra_timing
> > indicates the minimum as 66.3MHz and the maximum as 78.9MHz.
>
> The panel-simple.c already contains timings for this panel, which are
> accurate and follow the panel datasheet. If the goal here is to support
> approximate panel timings between the currently available three options
> (min/typ/max) listed in panel-simple, then that is another discussion
> for another patch.
>
> > Furthermore, if "PHYTEC phyBOARD-Pollux i.MX8MP" also supports
> > something like MIPI DSI to HDMI, then 74.25MHz panel pixel clock
> > rate is more desirable because the LVDS display and the MIPI DSI
> > display pipeline with typical 148.5MHz/74.25MHz pixel clock rates
> > may use one single "video_pll1" clock.
>
> I actually do have exactly this use case on one system -- one LVDS panel
> and one MIPI DSI panel -- the solution is really easy, source the LVDS
> pixel clock from Video PLL and the DSI clock from e.g. PLL3 .
>
> > Anyway, I think it is ok to use the patch[1] or assigning
> > "video_pll1" clock rate to 506.8MHz in DT(no things like MIPI
> > DSI to HDMI in existing DT).
> I believe for the current release, it is better to update the Video PLL
> clock in this one board DT, because that is minimum impact change
> isolated to this board and fixes a real issue where the LVDS panel
> worked within specification only by sheer chance.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-19 21:49 ` Kieran Bingham
@ 2024-10-20 2:49 ` Marek Vasut
2024-10-21 11:10 ` Kieran Bingham
2024-10-21 11:48 ` Maxime Ripard
0 siblings, 2 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-20 2:49 UTC (permalink / raw)
To: Kieran Bingham, Alexander Stein, Isaac Scott, Liu Ying, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F.Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
On 10/19/24 11:49 PM, Kieran Bingham wrote:
> Quoting Marek Vasut (2024-10-12 21:37:59)
>> On 10/11/24 5:10 AM, Liu Ying wrote:
>>
>> Hi,
>>
>>>>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>>>>>
>>>>>> &media_blk_ctrl {
>>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>>>>> // there is no need to multiply the clock by * 2
>>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>>>>
>>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>>>>> listed in imx_pll1443x_tbl[].
>>>>
>>>> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
>>>
>>> Ack.
>>>
>>>>
>>>>> Does the below patch[1] fix the regression issue? It explicitly sets
>>>>> the clock frequency of the panel timing to 74.25MHz.
>>>>>
>>>>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
>>>> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
>>>
>>> At least the patch[1] is legitimate now to override the display
>>> timing of the panel because the override mode is something
>>> panel-simple.c supports.
>>
>> It may be possible to override the mode, but why would this be the
>> desired if the panel-simple.c already contains valid accurate timings
>> for this particular panel ?
>
> I'm confused a little here. Why is it that setting the panel timings in
> the DT as per [1] make the display work, while the panel timeings in
> panel-simple alone are not enough?
>
> Is there some difference in code path for 'how' the panel timings are
> set as to whether they will apply fully or not ?
Because [1] sets inaccurate pixel clock of 74.25 MHz, which can be
divided down from random default Video PLL setting of 1039.5 MHz set in
imx8mp.dtsi media_blk_ctrl , 1039.5 / 74.25 = 14 .
The panel-simple pixel clock are 72.4 MHz, to achieve that accurately,
it is necessary to reconfigure the Video PLL frequency to 506.8 MHz ,
which LCDIFv3 can do, but LDB can not, hence it has to be done in DT for
now.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-20 2:49 ` Marek Vasut
@ 2024-10-21 11:10 ` Kieran Bingham
2024-10-21 21:00 ` Marek Vasut
2024-10-21 11:48 ` Maxime Ripard
1 sibling, 1 reply; 24+ messages in thread
From: Kieran Bingham @ 2024-10-21 11:10 UTC (permalink / raw)
To: Alexander Stein, Isaac Scott, Liu Ying, Marek Vasut, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F.Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
Quoting Marek Vasut (2024-10-20 03:49:29)
> On 10/19/24 11:49 PM, Kieran Bingham wrote:
> > Quoting Marek Vasut (2024-10-12 21:37:59)
> >> On 10/11/24 5:10 AM, Liu Ying wrote:
> >>
> >> Hi,
> >>
> >>>>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
> >>>>>>
> >>>>>> &media_blk_ctrl {
> >>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
> >>>>>> // there is no need to multiply the clock by * 2
> >>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
> >>>>>
> >>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
> >>>>> listed in imx_pll1443x_tbl[].
> >>>>
> >>>> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
> >>>
> >>> Ack.
> >>>
> >>>>
> >>>>> Does the below patch[1] fix the regression issue? It explicitly sets
> >>>>> the clock frequency of the panel timing to 74.25MHz.
> >>>>>
> >>>>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> >>>> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
> >>>
> >>> At least the patch[1] is legitimate now to override the display
> >>> timing of the panel because the override mode is something
> >>> panel-simple.c supports.
> >>
> >> It may be possible to override the mode, but why would this be the
> >> desired if the panel-simple.c already contains valid accurate timings
> >> for this particular panel ?
> >
> > I'm confused a little here. Why is it that setting the panel timings in
> > the DT as per [1] make the display work, while the panel timeings in
> > panel-simple alone are not enough?
> >
> > Is there some difference in code path for 'how' the panel timings are
> > set as to whether they will apply fully or not ?
> Because [1] sets inaccurate pixel clock of 74.25 MHz, which can be
> divided down from random default Video PLL setting of 1039.5 MHz set in
> imx8mp.dtsi media_blk_ctrl , 1039.5 / 74.25 = 14 .
>
> The panel-simple pixel clock are 72.4 MHz, to achieve that accurately,
> it is necessary to reconfigure the Video PLL frequency to 506.8 MHz ,
> which LCDIFv3 can do, but LDB can not, hence it has to be done in DT for
> now.
Aha - right - Thanks, I'd missed the part that 74.25 MHz /is not/ the
correct or supported pixel clock for the panel, so it just becomes
'close enough' and lucky that it works...
Now I understand how your proposed :
> >>>>>> &media_blk_ctrl {
> >>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
> >>>>>> // there is no need to multiply the clock by * 2
> >>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
> >>>>>
> >>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
> >>>>> listed in imx_pll1443x_tbl[].
is more accurate. But is that acceptable for DT ? To just hardcode
clocks like that?
Or is this something we'll then remove when the additional patches make
it upstream? (I'm curious on the basis that I thought we treat DT as
'firmware' so if we put this in we expect it to be there forever?)
All of this seems like perhaps it should be in an overlay for the
display too - but given this board comes with this panel as a kit - I
suspect it's fine to keep it all there.
--
Kieran
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-20 2:49 ` Marek Vasut
2024-10-21 11:10 ` Kieran Bingham
@ 2024-10-21 11:48 ` Maxime Ripard
2024-10-21 21:07 ` Marek Vasut
1 sibling, 1 reply; 24+ messages in thread
From: Maxime Ripard @ 2024-10-21 11:48 UTC (permalink / raw)
To: Marek Vasut
Cc: Kieran Bingham, Alexander Stein, Isaac Scott, Liu Ying, dri-devel,
Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F.Hartmann, Maarten Lankhorst, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Stefan Agner, Thomas Zimmermann, imx,
kernel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]
On Sun, Oct 20, 2024 at 04:49:29AM +0200, Marek Vasut wrote:
> On 10/19/24 11:49 PM, Kieran Bingham wrote:
> > Quoting Marek Vasut (2024-10-12 21:37:59)
> > > On 10/11/24 5:10 AM, Liu Ying wrote:
> > >
> > > Hi,
> > >
> > > > > > > This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
> > > > > > >
> > > > > > > &media_blk_ctrl {
> > > > > > > // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
> > > > > > > // there is no need to multiply the clock by * 2
> > > > > > > assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
> > > > > >
> > > > > > This assigns "video_pll1" clock rate to 506.8MHz which is currently not
> > > > > > listed in imx_pll1443x_tbl[].
> > > > >
> > > > > Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
> > > >
> > > > Ack.
> > > >
> > > > >
> > > > > > Does the below patch[1] fix the regression issue? It explicitly sets
> > > > > > the clock frequency of the panel timing to 74.25MHz.
> > > > > >
> > > > > > [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
> > > > > That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
> > > >
> > > > At least the patch[1] is legitimate now to override the display
> > > > timing of the panel because the override mode is something
> > > > panel-simple.c supports.
> > >
> > > It may be possible to override the mode, but why would this be the
> > > desired if the panel-simple.c already contains valid accurate timings
> > > for this particular panel ?
> >
> > I'm confused a little here. Why is it that setting the panel timings in
> > the DT as per [1] make the display work, while the panel timeings in
> > panel-simple alone are not enough?
> >
> > Is there some difference in code path for 'how' the panel timings are
> > set as to whether they will apply fully or not ?
> Because [1] sets inaccurate pixel clock of 74.25 MHz, which can be divided
> down from random default Video PLL setting of 1039.5 MHz set in imx8mp.dtsi
> media_blk_ctrl , 1039.5 / 74.25 = 14 .
>
> The panel-simple pixel clock are 72.4 MHz, to achieve that accurately, it is
> necessary to reconfigure the Video PLL frequency to 506.8 MHz , which
> LCDIFv3 can do, but LDB can not, hence it has to be done in DT for now.
That the clock driver is broken and thus should be fixed through the DT is a
bit backward, don't you think?
AFAIU, the clock can't reach the ideal pixel clock panel-simple has. Do
you have the datasheet for that panel?
If so, using display_timings and shortening/extending the blanking
timings to match the clock that can be provided seems like a more robust
solution.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-21 11:10 ` Kieran Bingham
@ 2024-10-21 21:00 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-21 21:00 UTC (permalink / raw)
To: Kieran Bingham, Alexander Stein, Isaac Scott, Liu Ying, dri-devel
Cc: Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F.Hartmann, Maarten Lankhorst, Maxime Ripard,
Pengutronix Kernel Team, Sascha Hauer, Shawn Guo, Stefan Agner,
Thomas Zimmermann, imx, kernel, linux-arm-kernel
On 10/21/24 1:10 PM, Kieran Bingham wrote:
> Quoting Marek Vasut (2024-10-20 03:49:29)
>> On 10/19/24 11:49 PM, Kieran Bingham wrote:
>>> Quoting Marek Vasut (2024-10-12 21:37:59)
>>>> On 10/11/24 5:10 AM, Liu Ying wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>>>>>>>
>>>>>>>> &media_blk_ctrl {
>>>>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>>>>>>> // there is no need to multiply the clock by * 2
>>>>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>>>>>>
>>>>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>>>>>>> listed in imx_pll1443x_tbl[].
>>>>>>
>>>>>> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
>>>>>
>>>>> Ack.
>>>>>
>>>>>>
>>>>>>> Does the below patch[1] fix the regression issue? It explicitly sets
>>>>>>> the clock frequency of the panel timing to 74.25MHz.
>>>>>>>
>>>>>>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
>>>>>> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
>>>>>
>>>>> At least the patch[1] is legitimate now to override the display
>>>>> timing of the panel because the override mode is something
>>>>> panel-simple.c supports.
>>>>
>>>> It may be possible to override the mode, but why would this be the
>>>> desired if the panel-simple.c already contains valid accurate timings
>>>> for this particular panel ?
>>>
>>> I'm confused a little here. Why is it that setting the panel timings in
>>> the DT as per [1] make the display work, while the panel timeings in
>>> panel-simple alone are not enough?
>>>
>>> Is there some difference in code path for 'how' the panel timings are
>>> set as to whether they will apply fully or not ?
>> Because [1] sets inaccurate pixel clock of 74.25 MHz, which can be
>> divided down from random default Video PLL setting of 1039.5 MHz set in
>> imx8mp.dtsi media_blk_ctrl , 1039.5 / 74.25 = 14 .
>>
>> The panel-simple pixel clock are 72.4 MHz, to achieve that accurately,
>> it is necessary to reconfigure the Video PLL frequency to 506.8 MHz ,
>> which LCDIFv3 can do, but LDB can not, hence it has to be done in DT for
>> now.
>
> Aha - right - Thanks, I'd missed the part that 74.25 MHz /is not/ the
> correct or supported pixel clock for the panel
It is inaccurate, it is still within the spec ...
> , so it just becomes
> 'close enough' and lucky that it works...
... but only by sheer chance, because the Video PLL in imx8mp.dtsi is
accidentally set to frequency that is just close enough to be divisible
to the inaccurate 74.25 MHz .
> Now I understand how your proposed :
>
>>>>>>>> &media_blk_ctrl {
>>>>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>>>>>>> // there is no need to multiply the clock by * 2
>>>>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>>>>>>
>>>>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>>>>>>> listed in imx_pll1443x_tbl[].
>
> is more accurate. But is that acceptable for DT ? To just hardcode
> clocks like that?
I am not happy about it, but it is the best we can do right now.
See these two patches, they might address that part for next cycle:
clk: imx: clk-imx8mp: Allow LDB serializer clock reconfigure parent rate
drm: bridge: ldb: Configure LDB clock in .mode_set
> Or is this something we'll then remove when the additional patches make
> it upstream? (I'm curious on the basis that I thought we treat DT as
> 'firmware' so if we put this in we expect it to be there forever?)
It is already there in imx8mp.dtsi , so we are not making the situation
any worse, rather the opposite.
> All of this seems like perhaps it should be in an overlay for the
> display too - but given this board comes with this panel as a kit - I
> suspect it's fine to keep it all there.
That's a separate topic, but yes, DTOs for displays are a good thing to
have.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
2024-10-21 11:48 ` Maxime Ripard
@ 2024-10-21 21:07 ` Marek Vasut
0 siblings, 0 replies; 24+ messages in thread
From: Marek Vasut @ 2024-10-21 21:07 UTC (permalink / raw)
To: Maxime Ripard
Cc: Kieran Bingham, Alexander Stein, Isaac Scott, Liu Ying, dri-devel,
Daniel Vetter, David Airlie, Fabio Estevam, Lucas Stach,
Lukas F.Hartmann, Maarten Lankhorst, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Stefan Agner, Thomas Zimmermann, imx,
kernel, linux-arm-kernel
On 10/21/24 1:48 PM, Maxime Ripard wrote:
> On Sun, Oct 20, 2024 at 04:49:29AM +0200, Marek Vasut wrote:
>> On 10/19/24 11:49 PM, Kieran Bingham wrote:
>>> Quoting Marek Vasut (2024-10-12 21:37:59)
>>>> On 10/11/24 5:10 AM, Liu Ying wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>>> This Video PLL1 configuration since moved to &media_blk_ctrl {} , but it is still in the imx8mp.dtsi . Therefore, to make your panel work at the correct desired pixel clock frequency instead of some random one inherited from imx8mp.dtsi, add the following to the pollux DT, I believe that will fix the problem and is the correct fix:
>>>>>>>>
>>>>>>>> &media_blk_ctrl {
>>>>>>>> // 506800000 = 72400000 * 7 (for single-link LVDS, this is enough)
>>>>>>>> // there is no need to multiply the clock by * 2
>>>>>>>> assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <500000000>, <506800000>;
>>>>>>>
>>>>>>> This assigns "video_pll1" clock rate to 506.8MHz which is currently not
>>>>>>> listed in imx_pll1443x_tbl[].
>>>>>>
>>>>>> Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates") the 1443x PLLs can be configured to arbitrary rates which for video PLL is desirable as those should produce accurate clock.
>>>>>
>>>>> Ack.
>>>>>
>>>>>>
>>>>>>> Does the below patch[1] fix the regression issue? It explicitly sets
>>>>>>> the clock frequency of the panel timing to 74.25MHz.
>>>>>>>
>>>>>>> [1] https://patchwork.freedesktop.org/patch/616905/?series=139266&rev=1
>>>>>> That patch is wrong, there is an existing entry for this panel in panel-simple.c which is correct and precise, please do not add that kind of imprecise duplicate timings into DT.
>>>>>
>>>>> At least the patch[1] is legitimate now to override the display
>>>>> timing of the panel because the override mode is something
>>>>> panel-simple.c supports.
>>>>
>>>> It may be possible to override the mode, but why would this be the
>>>> desired if the panel-simple.c already contains valid accurate timings
>>>> for this particular panel ?
>>>
>>> I'm confused a little here. Why is it that setting the panel timings in
>>> the DT as per [1] make the display work, while the panel timeings in
>>> panel-simple alone are not enough?
>>>
>>> Is there some difference in code path for 'how' the panel timings are
>>> set as to whether they will apply fully or not ?
>> Because [1] sets inaccurate pixel clock of 74.25 MHz, which can be divided
>> down from random default Video PLL setting of 1039.5 MHz set in imx8mp.dtsi
>> media_blk_ctrl , 1039.5 / 74.25 = 14 .
>>
>> The panel-simple pixel clock are 72.4 MHz, to achieve that accurately, it is
>> necessary to reconfigure the Video PLL frequency to 506.8 MHz , which
>> LCDIFv3 can do, but LDB can not, hence it has to be done in DT for now.
>
> That the clock driver is broken and thus should be fixed through the DT is a
> bit backward, don't you think?
See these two patches, they might address that part for next cycle:
clk: imx: clk-imx8mp: Allow LDB serializer clock reconfigure parent rate
drm: bridge: ldb: Configure LDB clock in .mode_set
For this cycle, fixing up the frequency that is already incorrectly set
in imx8mp.dtsi in board DT is the least impact approach, see
arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz
> AFAIU, the clock can't reach the ideal pixel clock panel-simple has. Do
> you have the datasheet for that panel?
No
> If so, using display_timings and shortening/extending the blanking
> timings to match the clock that can be provided seems like a more robust
> solution.
The PLL has to be configured correctly, see the two patches listed above.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2024-10-22 2:07 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-31 20:27 [PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock Marek Vasut
2024-06-24 9:19 ` Alexander Stein
2024-07-06 0:16 ` Marek Vasut
2024-10-07 17:01 ` Isaac Scott
2024-10-07 18:06 ` Marek Vasut
2024-10-08 10:07 ` Isaac Scott
2024-10-08 14:37 ` Marek Vasut
2024-10-08 21:48 ` Marek Vasut
2024-10-09 9:55 ` Isaac Scott
2024-10-09 15:47 ` Marek Vasut
2024-10-09 15:58 ` Isaac Scott
2024-10-10 0:38 ` Marek Vasut
2024-10-10 5:31 ` Liu Ying
2024-10-10 15:54 ` Isaac Scott
2024-10-10 16:02 ` Isaac Scott
2024-10-10 17:29 ` Marek Vasut
2024-10-11 3:10 ` Liu Ying
2024-10-12 20:37 ` Marek Vasut
2024-10-19 21:49 ` Kieran Bingham
2024-10-20 2:49 ` Marek Vasut
2024-10-21 11:10 ` Kieran Bingham
2024-10-21 21:00 ` Marek Vasut
2024-10-21 11:48 ` Maxime Ripard
2024-10-21 21:07 ` Marek Vasut
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox