Re: [PATCH v7 03/12] drm/bridge: cdns-dsi: Fix phy de-init and flag it so

[Aradhya Bhatia <aradhya.bhatia@linux.dev>]

Hi Tomi,

On 1/14/25 18:00, Tomi Valkeinen wrote:
> Hi,
> 
> On 14/01/2025 07:56, Aradhya Bhatia wrote:
>> From: Aradhya Bhatia <a-bhatia1@ti.com>
>>
>> The driver code doesn't have a Phy 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.
>>
>> Call the counterparts of phy_init() and phy_power_on(), that are
>> phy_exit() and phy_power_off(), from _bridge_disable(), and clear the
>> flags so that the Phy can be initialized again when required.
>>
>> 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 | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
>> b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
>> index 056583e81155..039c5eb7fb66 100644
>> --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
>> +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
>> @@ -672,6 +672,11 @@ static void cdns_dsi_bridge_disable(struct
>> drm_bridge *bridge)
>>       if (dsi->platform_ops && dsi->platform_ops->disable)
>>           dsi->platform_ops->disable(dsi);
>>   +    dsi->phy_initialized = false;
>> +    dsi->link_initialized = false;
>> +    phy_power_off(dsi->dphy);
>> +    phy_exit(dsi->dphy);
>> +
> 
> The phy related lines are counterparts to what's done in
> cdns_dsi_hs_init(), right? Maybe add cdns_dsi_hs_uninit(),
> 
> But is the phy_initialized even needed? phy_initialized() is called from
> cdns_dsi_bridge_enable() and cdns_dsi_bridge_pre_enable(). Won't the
> call in cdns_dsi_bridge_enable() be always skipped, as
> cdns_dsi_bridge_pre_enable() already set phy_initialized?

Yes, that is how the behavior has been. The initialization calls inside
the _bridge_enable() end-up getting skipped.

My first thought after reading your comments was to remove the init
calls entirely from the _bridge_pre_enable(), and drop the
phy_initialized flag too, and let _bridge_enable() only handle the init.
The _bridge_enable() will anyway get renamed to _bridge_pre_enable(),
while the existing _bridge_pre_enable() will get dropped, by the last
patch of this series.

But since this patch is intended as a fix, it will get applied to
previous versions while that last patch of the series won't... and then
we may end up having init calls only from _bridge_enable() for the older
versions.
Also, given all the fixes in the series, there is a possibility that an
older-version of the driver might become functional (except for the
color shift issue).

My question then is, would it be a cause for concern if all the init
calls are handled from the _bridge_enable() only?

(one of the potential concerns detailed below)

> 
> Same question for cdns_dsi_init_link(), although that's also called from
> cdns_dsi_transfer(), so we probably need dsi->link_initialized.
> 

Don't you think we'd need the phy to also be initialized for the DCS
command to work?

Usually, since DSI is among the initial bridges to get pre_enabled, the
Link and Phy are both initialized by the time cdns_dsi_transfer() is
called. So, even if cdns_dsi_transfer() doesn't call for
cdns_dsi_hs_init(), it is able to work fine.

If DCS commands do indeed require the cdns_dsi_hs_init(), then shifting
it to _bridge_enable() (like I suggested above) would be problematic
without fixing it here.


Regards
Aradhya

> 
>>       pm_runtime_put(dsi->base.dev);
>>   }
>>   @@ -1130,7 +1135,6 @@ static int __maybe_unused
>> cdns_dsi_suspend(struct device *dev)
>>       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;
>>   }
>>   
>