Hi, On 05/12/2025 10:32, Maxime Ripard wrote: > 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? Yep, I have a WIP series. I'll send it today.
Tomi
