Hi Linus,

On 12/3/2025 5:02 AM, Linus Walleij wrote:
> commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1
> "drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"
> caused a series of regressions in all panels that send
> DSI commands in their .prepare() and .unprepare()
> callbacks when used with MCDE.
> 
> As the CRTC is no longer online at bridge_pre_enable()
> and gone at brige_post_disable() which maps to the panel
> bridge .prepare()/.unprepare() callbacks, any CRTC that
> enable/disable the DSI transmitter in it's enable/disable
> callbacks will be unable to send any DSI commands in the
> .prepare() and .unprepare() callbacks.
> 
> However the MCDE driver definitely need the CRTC to be
> enabled during .prepare()/.unprepare().
> 
> Solve this by implementing a custom commit tail function
> in the MCDE driver that always enables the CRTC first
> and disables it last, using the newly exported helpers.
> 
> Link: 
> https://lore.kernel.org/dri-devel/[email protected]/
> Link: 
> https://lore.kernel.org/all/20251107230517.471894-1-marek.vasut%2Brenesas%40mailbox.org/
> Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and 
> post-disable")
> Tested-by: Marek Vasut <[email protected]>
> Reviewed-by: Maxime Ripard <[email protected]>
> Signed-off-by: Linus Walleij <[email protected]>
> ---
>  drivers/gpu/drm/mcde/mcde_drv.c | 45 
> ++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 

The bridge document says: "The display pipe (i.e. clocks and timing
signals) feeding this bridge will not yet be running when the 
@atomic_pre_enable is called."

Therefore, your approach seems to be merely a workaround and does not
meet the current requirements of the bridge.

And document also says: "The bridge can assume that the display pipe
(i.e. clocks and timing signals) feeding it is running when 
@atomic_enable callback is called."

If DSI commands need to wait for the display pipe (CRTC) to be ready,
why not perform them inside @atomic_enable instead of @atomic_pre_enable?

-- 
Best, 
Chaoyi

Reply via email to