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@xxxxxx>
>>
>> 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@xxxxxx>
>> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@xxxxxxxxx>
>> ---
>> 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;
>> }
>>
>
