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
signature.asc
Description: PGP signature
