Hi, On 04/12/2025 04:07, Chaoyi Chen wrote: > On 12/4/2025 7:13 AM, Linus Walleij wrote: >> On Wed, Dec 3, 2025 at 7:27 AM Chaoyi Chen <[email protected]> >> wrote: >> >>> 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? >> >> That was exactly what the v1 and v2 versions of this patch set was >> doing, and it was (politely) NACKed, and that is why we are >> here. >> https://lore.kernel.org/dri-devel/[email protected]/ >> https://lore.kernel.org/dri-devel/[email protected]/ >> > > Hmm, I'm afraid there really isn't a common solution at this point. > > The logical enable order of the CRTC, bridge, and panel may be > different from the actual physical enable order. And there is no > mechanism to change this order :(
I'm not sure what you mean with logical and physical enable orders... But the fact seems to be that during enable sequence different platforms, bridges and panels either 1) specifically require an incoming stream from the crtc 2) specifically prohibit that, or 3) don't care. And we don't have any means to deal with this. In this series Linus changes the platforms' crtc to behave in a particular way. But if you would connect a bridge or panel to those platforms, which specifically does not want incoming stream during pre_enable, those wouldn't work. In any case, we need to get the current setups working. I made a quick test series which: - Reverts c9b1150a68d9362a0827609fc0dc1664c0d8bfe1 - Applies patch 1 from this series (with some conflict fixes due to the above revert) - Implements "pre-enable-before-crtc-enable" for tidss This works ok, afaics, and resembles very much the platform patches in this series. That is a smaller series, and has the potential benefit that if there are other platforms that have gotten broken but no one has noticed, they would again get fixed. Thoughts? Shall I send it, or shall we just go with this series? One more point: even if the platforms in this series get fixed by enabling the crtc first, I'm not sure if anyone else but Linus studied the platforms to see if it would be possible for the DSI (or DP in one case, if I recall right) to work without enabling the DRM crtc. I think optimally the control bus should work independently from the video data bus. E.g. one should be able to do DSI commands any time after the DSI peripheral has been attached to the bridge, even outside the enable sequence. This could be possible by just enabling some clock on the crtc side, or perhaps enabling some bypass clock mode. Of course, there could also be other reasons to require/prohibit the video stream... Tomi
