Re: [PATCH] drm/panel: move some dsi commands from unprepare to disable

[Stephan Gerhold <stephan@gerhold.net>]

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@gerhold.net> 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@samsung.com>
> > 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@samsung.com>
> >      [treding: rewrite changelog, add kerneldoc]
> >      Signed-off-by: Thierry Reding <treding@nvidia.com>
> > 
> > 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