Re: [PATCH] drm/bridge: cdns-dsi: Fix issue with phy init

[Tomi Valkeinen]

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@xxxxxx>
> ---
>   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