Hi Quanyang,
Thank you for the patch.
On Wed, Mar 10, 2021 at 12:59:45PM +0800, quanyang.wang@windriver.com wrote:
From: Quanyang Wang quanyang.wang@windriver.com
The Runtime PM subsystem will force the device "fd4a0000.zynqmp-display" to enter suspend state while booting if the following conditions are met:
- the usage counter is zero (pm_runtime_get_sync hasn't been called yet)
- no 'active' children (no zynqmp-dp-snd-xx node under dpsub node)
- no other device in the same power domain (dpdma node has no "power-domains = <&zynqmp_firmware PD_DP>" property)
So there is a scenario as below:
- DP device enters suspend state <- call zynqmp_gpd_power_off
- zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG
- pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear previous VPLL_FRAC_CFG configuration
- clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG configuration is corrupted
From above, we can see that pm_runtime_get_sync may clear register VPLL_FRAC_CFG configuration and result the failure of clk enabling. Putting pm_runtime_get_sync at the very beginning of the function zynqmp_disp_crtc_atomic_enable can resolve this issue.
Isn't this an issue in the firmware though, which shouldn't clear the previous VPLLF_FRAC_CFG ?
Signed-off-by: Quanyang Wang quanyang.wang@windriver.com
Nonetheless, this change looks good to me, I actually had the same patch in my tree while investigation issues related to the clock rate, so
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Tested-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
I was hoping it would solve the issue I'm experiencing with the DP clock, but that's not the case :-( In a nutshell, when the DP is first started, the clock frequency is incorrect. The following quick & dirty patch fixes the problem:
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c index 74ac0a064eb5..fdbe1b0640aa 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -1439,6 +1439,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
pm_runtime_get_sync(disp->dev);
+ ret = clk_prepare_enable(disp->pclk); + if (!ret) + clk_disable_unprepare(disp->pclk); + zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
ret = clk_prepare_enable(disp->pclk);
The problem doesn't seem to be in the kernel, but on the TF-A or PMU firmware side. Have you experienced this by any chance ?
drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c index 148add0ca1d6..909e6c265406 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -1445,9 +1445,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_display_mode *adjusted_mode = &crtc->state->adjusted_mode; int ret, vrefresh;
- pm_runtime_get_sync(disp->dev);
- zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
- pm_runtime_get_sync(disp->dev); ret = clk_prepare_enable(disp->pclk); if (ret) { dev_err(disp->dev, "failed to enable a pixel clock\n");