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 :( So I believe your current patch to the mcde makes sense, because you are indeed requiring the CRTC to be enabled at the hardware level. But for other platforms, you may need to distinguish whether this is a software dependency order problem caused by changes to the bridge enable order. > In essence, Tomi remarked that drivers should be able to send DSI > commands at atomic_pre_enable() which is for example > mapped to the .prepare() callback in the DSI panel bridge. > And he has a good point in this, I just converted the few panel > drivers that I was affected by, but there are many more such > and probably some bridges as well. > > Yours, > Linus Walleij > > -- Best, Chaoyi
