Hello Tomi, On 12/4/2025 9:54 PM, Tomi Valkeinen wrote: > 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. >
Yes, that's exactly what I meant. I'm referring to the fact that the enable sequence is fixed in terms of code logic, but different hardware may have different requirements. > 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? > Sounds good. I think we should compare the two to see which one is better. So please send it. > 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... Yep, it all comes down to the hardware design. Different designs can naturally have different requirements. -- Best, Chaoyi
