| Message ID | 20250111192738.308889-4-aradhya.bhatia@linux.dev (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | drm/bridge: cdns-dsi: Fix the color-shift issue | expand |
On Sun, Jan 12, 2025 at 12:57:29AM +0530, Aradhya Bhatia wrote: > From: Aradhya Bhatia <a-bhatia1@ti.com> > > The driver code doesn't have a de-initialization path as yet, and so it > does not clear the phy_initialized flag while suspending. This is a > problem because after resume the driver looks at this flag to determine > if a Phy re-initialization is required or not. It is in fact required > because the hardware is resuming from a suspend, but the driver does not > carry out any re-initialization causing the D-Phy to not work at all. > > Add the counterpart of phy_power_on(), that is phy_power_off() from the > _bridge_disable() and clear the flags so that the Phy can be initialized > again when required. > > Move the Phy initialization from _bridge_enable() to _resume(), and > de-initialize during the _suspend() - so that the phy_{init, exit}() > take place once every resume/suspend cycle. Is it okay to call phy_init() before writing MCTL_DPHY_CFG0 ? > > The order of calls still remains the same. phy_init() needs to be called > before phy_power_on() - which happens still. What this patch changes is > the frequency of the phy_init() call. Instead of it being called once > every bridge enable/disable cycle, it is now being called once every > resume/suspend cycle. This move has been considered safe after numerous > tests with the hardware. > > Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") > Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> > --- > drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-)
Thank you for reviewing the patches, Dmitry. On 1/13/25 15:10, Dmitry Baryshkov wrote: > On Sun, Jan 12, 2025 at 12:57:29AM +0530, Aradhya Bhatia wrote: >> From: Aradhya Bhatia <a-bhatia1@ti.com> >> >> The driver code doesn't have a de-initialization path as yet, and so it >> does not clear the phy_initialized flag while suspending. This is a >> problem because after resume the driver looks at this flag to determine >> if a Phy re-initialization is required or not. It is in fact required >> because the hardware is resuming from a suspend, but the driver does not >> carry out any re-initialization causing the D-Phy to not work at all. >> >> Add the counterpart of phy_power_on(), that is phy_power_off() from the >> _bridge_disable() and clear the flags so that the Phy can be initialized >> again when required. >> >> Move the Phy initialization from _bridge_enable() to _resume(), and >> de-initialize during the _suspend() - so that the phy_{init, exit}() >> take place once every resume/suspend cycle. > > Is it okay to call phy_init() before writing MCTL_DPHY_CFG0 ? The phy_init() is a no-op when we look at the D-Phy driver, which does not implement the _init() hook at all. So, in this case, all phy_init() call ever manages to do is book-keeping. Book-keeping that isn't required to be done every time we do a bridge enable/disable. But despite the no-op nature of the call, I guess it would still not make sense to call it before the reset assert done in MCTL_DPHY_CFG0. Instead of moving it to resume(), I can keep phy_init() as is, and add phy_exit() in the bridge disable path, instead of the suspend path. Regards Aradhya > >> >> The order of calls still remains the same. phy_init() needs to be called >> before phy_power_on() - which happens still. What this patch changes is >> the frequency of the phy_init() call. Instead of it being called once >> every bridge enable/disable cycle, it is now being called once every >> resume/suspend cycle. This move has been considered safe after numerous >> tests with the hardware. >> >> Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> >> --- >> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) >
On Mon, Jan 13, 2025 at 09:09:11PM +0530, Aradhya Bhatia wrote: > Thank you for reviewing the patches, Dmitry. > > On 1/13/25 15:10, Dmitry Baryshkov wrote: > > On Sun, Jan 12, 2025 at 12:57:29AM +0530, Aradhya Bhatia wrote: > >> From: Aradhya Bhatia <a-bhatia1@ti.com> > >> > >> The driver code doesn't have a de-initialization path as yet, and so it > >> does not clear the phy_initialized flag while suspending. This is a > >> problem because after resume the driver looks at this flag to determine > >> if a Phy re-initialization is required or not. It is in fact required > >> because the hardware is resuming from a suspend, but the driver does not > >> carry out any re-initialization causing the D-Phy to not work at all. > >> > >> Add the counterpart of phy_power_on(), that is phy_power_off() from the > >> _bridge_disable() and clear the flags so that the Phy can be initialized > >> again when required. > >> > >> Move the Phy initialization from _bridge_enable() to _resume(), and > >> de-initialize during the _suspend() - so that the phy_{init, exit}() > >> take place once every resume/suspend cycle. > > > > Is it okay to call phy_init() before writing MCTL_DPHY_CFG0 ? > > The phy_init() is a no-op when we look at the D-Phy driver, which does > not implement the _init() hook at all. So, in this case, all phy_init() > call ever manages to do is book-keeping. Book-keeping that isn't > required to be done every time we do a bridge enable/disable. > But despite the no-op nature of the call, I guess it would still not > make sense to call it before the reset assert done in MCTL_DPHY_CFG0. Yes, please. > Instead of moving it to resume(), I can keep phy_init() as is, and add > phy_exit() in the bridge disable path, instead of the suspend path. > > > Regards > Aradhya > > > > >> > >> The order of calls still remains the same. phy_init() needs to be called > >> before phy_power_on() - which happens still. What this patch changes is > >> the frequency of the phy_init() call. Instead of it being called once > >> every bridge enable/disable cycle, it is now being called once every > >> resume/suspend cycle. This move has been considered safe after numerous > >> tests with the hardware. > >> > >> Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework") > >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > >> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> > >> --- > >> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 10 ++++++++-- > >> 1 file changed, 8 insertions(+), 2 deletions(-) > >
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 056583e81155..47550891427c 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -672,6 +672,10 @@ static void cdns_dsi_bridge_disable(struct drm_bridge *bridge) if (dsi->platform_ops && dsi->platform_ops->disable) dsi->platform_ops->disable(dsi); + phy_power_off(dsi->dphy); + dsi->link_initialized = false; + dsi->phy_initialized = false; + pm_runtime_put(dsi->base.dev); } @@ -698,7 +702,6 @@ static void cdns_dsi_hs_init(struct cdns_dsi *dsi) DPHY_CMN_PDN | DPHY_PLL_PDN, dsi->regs + MCTL_DPHY_CFG0); - phy_init(dsi->dphy); phy_set_mode(dsi->dphy, PHY_MODE_MIPI_DPHY); phy_configure(dsi->dphy, &output->phy_opts); phy_power_on(dsi->dphy); @@ -1120,6 +1123,8 @@ static int __maybe_unused cdns_dsi_resume(struct device *dev) clk_prepare_enable(dsi->dsi_p_clk); clk_prepare_enable(dsi->dsi_sys_clk); + phy_init(dsi->dphy); + return 0; } @@ -1127,10 +1132,11 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev) { struct cdns_dsi *dsi = dev_get_drvdata(dev); + phy_exit(dsi->dphy); + clk_disable_unprepare(dsi->dsi_sys_clk); clk_disable_unprepare(dsi->dsi_p_clk); reset_control_assert(dsi->dsi_p_rst); - dsi->link_initialized = false; return 0; }