On Thu, Jun 15, 2023 at 09:49:27AM +0200, Neil Armstrong wrote: > On 14/06/2023 22:58, Linus Walleij wrote: > > On Tue, Jun 13, 2023 at 11:08 PM Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > > > > > I'm still quite confused about what exactly is supposed to be in > > > (un)prepare and what in enable/disable. I've seen some related > > > discussion every now and then but it's still quite inconsistent across > > > different panel drivers... Can someone clarify this? > > > > It is somewhat clarified in commit 45527d435c5e39b6eec4aa0065a562e7cf05d503 > > that added the callbacks: > > > > Author: Ajay Kumar <ajaykumar.rs@xxxxxxxxxxx> > > Date: Fri Jul 18 02:13:48 2014 +0530 > > > > drm/panel: add .prepare() and .unprepare() functions > > > > Panels often require an initialization sequence that consists of three > > steps: a) powering up the panel, b) starting transmission of video data > > and c) enabling the panel (e.g. turn on backlight). This is usually > > necessary to avoid visual glitches at the beginning of video data > > transmission. > > > > Similarly, the shutdown sequence is typically done in three steps as > > well: a) disable the panel (e.g. turn off backlight), b) cease video > > data transmission and c) power down the panel. > > > > Currently drivers can only implement .enable() and .disable() functions, > > which is not enough to implement the above sequences. This commit adds a > > second pair of functions, .prepare() and .unprepare() to allow more > > fine-grained control over when the above steps are performed. > > > > Signed-off-by: Ajay Kumar <ajaykumar.rs@xxxxxxxxxxx> > > [treding: rewrite changelog, add kerneldoc] > > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > > > > My interpretation is that .enable/.disable is for enabling/disabling > > backlight and well, make things show up on the display, and that > > happens quickly. > > > > prepare/unprepare is for everything else setting up/tearing down > > the data transmission pipeline. > > > > In the clock subsystem the enable/disable could be called in fastpath > > and prepare/unprepare only from slowpath so e.g an IRQ handler > > can gate a simple gated clock. This semantic seems to have nothing > > to do with the display semantic. :/ > > It had to do, .prepare is called when the DSI link is at LP11 state > before it has switched to the VIDEO mode, and .unprepare is the > reverse when VIDEO mode has been disabled and before the DSI link > is totally disabled. > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L938 > > then > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L855 > > but Doug has started changing this starting with MSM DSI driver, leading to > current panel drivers not working anymore with the current DSI init mode > and requires setting pre_enable_prev_first for only some DSI hosts > who switched out of set_mode(). > Hm, do I understand you correctly that setting bridge->pre_enable_prev_first / panel->prepare_prev_first should work as an alternative to $subject patch, at least for the MSM DSI driver? With it DSI commands should be possible to be sent in .unprepare()? Thanks, Stephan
