Hi, On 18/11/2025 15:41, Linus Walleij wrote: > On Mon, Nov 10, 2025 at 4:16 PM Tomi Valkeinen > <[email protected]> wrote: > >>> So what is needed is for .enable on the preceding bridge to have >>> been called first. >> >> Marek sent >> >> https://lore.kernel.org/all/20251107230517.471894-1-marek.vasut%2Brenesas%40mailbox.org/ >> >> Linus, I don't know if we want to go there or not, but could you see if >> that solves the problem on mcde? > > It does, after some fiddling and adding a custom helper > for this usecase. I just sent the patch.
Ok, great. >> If Marek's patch helps, we could go with it, or we could also try to >> apply it the other way around: revert the order back for, but add a new >> drm_atomic_helper_commit_modeset_enables variant, where the crtc is >> enabled after bridge pre_enables. > > Marek's patch helps, if applied and then with my additional > patch on top. > > Can you apply them both if this fix is acceptable? I'm trying to find time to do some hacking today or tomorrow wrt. this. The questions I have: - Should we 1) keep the current upstream sequence as default, and specific drivers can opt to use new helpers that make sure the crtc is enabled early (like your patch), or 2) revert the sequence changes from Aradhya, restoring the crtc-enabled-first style, and add new helpers that handle the sequence in the new way, as it is currently in upstream. - These patches only deal with the enable side. Disable side was also changed in Aradhya's patch. I guess that has not been a problem, but it worries me a bit if the enable and disable sequences are not mirroring each other. Tomi
