On Mon, 23 Feb 2026 at 15:40, David Heidelberg <[email protected]> wrote: > > On 06/12/2025 05:25, Dmitry Baryshkov wrote: > > On Tue, Nov 25, 2025 at 09:29:39PM +0100, David Heidelberg via B4 Relay > > wrote: > >> From: David Heidelberg <[email protected]> > >> > >> Introduce enable(), disable() and reset() functions. > >> > >> The enable() and disable() callbacks keep the symmetry in the commands > >> sent to the panel and also make a clearer distinction between panel > >> initialization and configuration. > > > > This also makes those to to be executed after starting the DSI stream. > > Is it fine? > > > > Hello Dmitry, > > I was wondering how the exact workflow looks, does this snippet reflect > real world? > > - The path ordering should be : > - prepare() > - (host/controller sets up link & starts sending video / enables bridge, > etc.) > - enable() > - disable() > - (host/controller stops video / disables bridge, etc.) > - unprepare() > - > - So: prepare happens before the display pipeline is driving, and enable > happens after the pipeline is ready and stable. > I assume in case of poorly written host or bridge drive it may not work > like this, but in general it should? > > If this workflow is correct, would it make sense I would incorporate the > phases between into the prepare/unprepare kernel docs?
There is a very precise definition of the DSI host lifecycle. Please take a look and notice that for DSI hosts there are two different points: - the DSI link is started in LP mode, letting the host send commands to the DSI sink. - the video / CMD stream is started For multiple reasons those two stages are separate. > > Thanks > David > > [...] -- With best wishes Dmitry
