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]/ 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
