Re: [PATCH v5 0/3] drm/atomic-helpers: Fix MCDE/R-Car DU regressions

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

On Wed, Dec 03, 2025 at 11:22:29AM +0900, Laurent Pinchart wrote:
> On Tue, Dec 02, 2025 at 10:58:50AM +0200, Tomi Valkeinen wrote:
> > On 02/12/2025 08:34, Laurent Pinchart wrote:
> > > On Sun, Nov 30, 2025 at 01:11:16PM +0100, Linus Walleij wrote:
> > >> This fixes two regressions experienced in the MCDE and
> > >> R-Car DU DRM drivers after
> > >> 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.
> > >>
> > >> This series make it possible to selectively bring back the
> > >> old behaviour with explicit semantics and implements
> > >> the old behaviour as modified commit tails in MCDE and
> > >> R-Car DU.
> > > 
> > > We now have a third platform broken by
> > > c9b1150a68d9362a0827609fc0dc1664c0d8bfe1, see [1]. I think this calls
> > > for a revert, to give us the time to implement a correct solution.
> >
> > Perhaps... It's been very slow or not possible to get feedback regarding
> > (some) of the broken platforms, so I don't think we have a safe way of
> > changing the enable/disable sequence. I think the "correct" solution
> > then is to make this new enable/disable sequence either opt-in, offered
> > by the framework, or just implement it as a custom sequence in the
> > specific drm driver.
> 
> I don't think that's right, sorry. We need to improve the bridge API to
> handle ordering properly. Changes to the commit tail handlers in display
> controller drivers are hacks, they handle issues with the internal DSI
> transmitters, but if you had a LVDS-to-DSI bridge in the pipeline things
> would still break.
> 
> > Reverting c9b1150a68d9362a0827609fc0dc1664c0d8bfe1 will break DSI and
> > OLDI outputs on TI platforms, so we need to implement a fix for those
> > platforms before the revert, and there has been one or two fixes merged
> > for other platforms for this, which most likely also need to get reverted.
> 
> That's 3 vs. 1, so I think breaking DSI and OLDI with a revert is better
> than not reverting the commit. If we can merge a propert solution at the
> same time that's great, but the first target is to restore operation of
> the drivers that got broken.

Yeah, I agree. Could it be possible to flip the custom commit_tail
implementation and instead implement it into tidss while the core
changes are reverted to avoid the regressions and keeping tidss
functional?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]