Re: [PATCH] drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds
From: Icenowy Zheng
Date: Tue Apr 28 2026 - 12:47:46 EST
在 2026-04-28二的 08:56 -0700,Doug Anderson写道:
> Hi,
>
> On Tue, Apr 28, 2026 at 8:53 AM Icenowy Zheng
> <zhengxingda@xxxxxxxxxxx> wrote:
> >
> > 在 2026-04-28二的 08:48 -0700,Doug Anderson写道:
> > > Hi,
> > >
> > > On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng
> > > <zhengxingda@xxxxxxxxxxx> wrote:
> > > >
> > > > 在 2026-04-27一的 11:24 -0700,Doug Anderson写道:
> > > > > Hi,
> > > > >
> > > > > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > > > > <zhengxingda@xxxxxxxxxxx> wrote:
> > > > > >
> > > > > > When preparing the panel, it seems that it always expects
> > > > > > commands
> > > > > > to be
> > > > > > transferred in LP mode. However, the disable function
> > > > > > removes
> > > > > > the
> > > > > > MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
> > > > > >
> > > > > > As the unprepare function contains no DSI commands, re-
> > > > > > adding
> > > > > > the
> > > > > > flag
> > > > > > just after disabling the panel should be safe. Add the code
> > > > > > re-
> > > > > > adding
> > > > > > the flag after the two commands for disabling the panel are
> > > > > > sent.
> > > > > >
> > > > > > This fixes screen unblanking (after blanking once) on
> > > > > > mt8188-geralt-ciri-sku1 device.
> > > > > >
> > > > > > Cc: stable@xxxxxxxxxxxxxxx # 6.11+
> > > > > > Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out
> > > > > > as
> > > > > > separate driver")
> > > > >
> > > > > This "Fixes" looks wrong. The bug was still there even before
> > > > > the
> > > > > driver was broken out. ...and it looks like the driver that
> > > > > this
> > > > > was
> > > > > broken out of (panel-boe-tv101wum-nl6.c) still has the same
> > > > > bug?
> > > >
> > > > Yes, but I think the fix shouldn't be propagated to the other
> > > > driver
> > > > because of the same reason with breaking out the original
> > > > driver.
> > >
> > > ...but doesn't all the same logic apply to the other driver?
> > > Nothing
> > > ever adds MIPI_DSI_MODE_LPM back in.
> > >
> > > Even if you don't fix the other driver yourself right now, the
> > > proper
> > > "Fixes" tag is when the problem was introduced, not when the
> > > driver
> > > forked out.
> >
> > I think the Fixes tag should point to where the driver is forked
> > out,
> > and if I'm going to send a patch for panel-boe-tv101wum-nl6, it
> > will
> > has a Fixes tag pointing to the further commit affecting that
> > driver.
>
> You're free to have your own opinion, but that doesn't match my
> understanding of the Fixes tag. If you can convince Neil or some
> other
> drm-misc committer to land your changes with the Fixes tag as you
> have
> it, then I won't object, but I won't land it. Best of luck!
I checked the forking commit, and the forking process doesn't involve
moving a `dsi->mode_flags &= ~MIPI_DSI_MODE_LPM` clause from the panel-
boe-tv101wum-nl6 driver to the panel-himax-hx83102 driver, which means
that this clause in the new driver is new, and shouldn't be trivially
backported to the old driver (because this process will affect other
non-hx83102 panels in that driver). Even if the unblanking issue exists
before the forking point, the specific code fixed by this commit is
created by the forking point (just by copying), instead of the previous
commit introducing the starry panel or the initial addition of the LPM
masking code to panel-boe-tv101wum-nl6 .
In addition, this isn't a regression fix, so Fixes tag is only
informative for backporting. The previous paragraph has already proved
that pointing it further isn't meaningful for backporting.
>
> -Doug