dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drm/bridge: cdns-dsi: Fix issue with phy init
@ 2022-11-15  8:39 Rahul T R
  2022-11-30  8:56 ` Tomi Valkeinen
  0 siblings, 1 reply; 2+ messages in thread
From: Rahul T R @ 2022-11-15  8:39 UTC (permalink / raw)
  To: dri-devel
  Cc: neil.armstrong, jonas, tomi.valkeinen, sjakhade, linux-kernel,
	jernej.skrabec, robert.foss, andrzej.hajda, jpawar, Rahul T R,
	Laurent.pinchart

Phy is not being initialized after suspend resume. Fix this by setting
phy_initialized flag to false in suspend callback

Signed-off-by: Rahul T R <r-ravikumar@ti.com>
---
 drivers/gpu/drm/bridge/cdns-dsi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c
index 20bece84ff8c..1a988f53424a 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -1187,6 +1187,7 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev)
 	clk_disable_unprepare(dsi->dsi_p_clk);
 	reset_control_assert(dsi->dsi_p_rst);
 	dsi->link_initialized = false;
+	dsi->phy_initialized = false;
 	return 0;
 }
 
-- 
2.38.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] drm/bridge: cdns-dsi: Fix issue with phy init
  2022-11-15  8:39 [PATCH] drm/bridge: cdns-dsi: Fix issue with phy init Rahul T R
@ 2022-11-30  8:56 ` Tomi Valkeinen
  0 siblings, 0 replies; 2+ messages in thread
From: Tomi Valkeinen @ 2022-11-30  8:56 UTC (permalink / raw)
  To: Rahul T R, dri-devel
  Cc: neil.armstrong, jonas, jpawar, linux-kernel, jernej.skrabec,
	robert.foss, andrzej.hajda, sjakhade, Laurent.pinchart

Hi,

On 15/11/2022 10:39, Rahul T R wrote:
> Phy is not being initialized after suspend resume. Fix this by setting
> phy_initialized flag to false in suspend callback
> 
> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
> ---
>   drivers/gpu/drm/bridge/cdns-dsi.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 20bece84ff8c..1a988f53424a 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -1187,6 +1187,7 @@ static int __maybe_unused cdns_dsi_suspend(struct device *dev)
>   	clk_disable_unprepare(dsi->dsi_p_clk);
>   	reset_control_assert(dsi->dsi_p_rst);
>   	dsi->link_initialized = false;
> +	dsi->phy_initialized = false;
>   	return 0;
>   }
>   

I'm not familiar with the IP, but the code related to enable/disable 
looks a bit odd.

Why does cdns_dsi_bridge_enable() do:
	cdns_dsi_hs_init(dsi);
	cdns_dsi_init_link(dsi);
but then in cdns_dsi_bridge_pre_enable():
	cdns_dsi_init_link(dsi);
	cdns_dsi_hs_init(dsi);

Doesn't the order matter? Why are the same functions called in both places?

cdns_dsi_hs_init() seems to do enabling, like locking the PLL. But 
there's no counterpart, hs_uninit(). I see cdns_dsi_bridge_disable() 
doing some clearing of the registers, so perhaps that's where the 
disabling happens. But cdns_dsi_hs_init() is called from the pre-enable, 
and post-disable doesn't do anything else but pm_runtime_put().

More or less the same comments apply to cdns_dsi_init_link(), but it's a 
bit worse as it's also called in cdns_dsi_transfer(), and then there's 
no uninit counterpart that I can see.

Well, maybe both functions are only doing configuration, not enabling 
this as such, and so it's fine to just turn off the IP without any 
uninit step. If that's the case, then probably this patch is fine.

  Tomi


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-11-30  8:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-15  8:39 [PATCH] drm/bridge: cdns-dsi: Fix issue with phy init Rahul T R
2022-11-30  8:56 ` Tomi Valkeinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).