Re: [PATCH] drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds

[Doug Anderson]

Hi,

On Tue, Apr 28, 2026 at 9:12 AM Icenowy Zheng <zhengxingda@xxxxxxxxxxx> wrote:
>
> 在 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 general in Linux drivers support more than one device. If you have
a fix for a driver, then you make the fix. You don't couch your fix
with "if (this_is_the_device_i_tested) do_my_fix()"

Said another way, if we hadn't forked support of this panel into a
separate driver, then you'd _have_ to be fixing to
panel-boe-tv101wum-nl6 driver, correct? You wouldn't add a special
case just for your panel--you'd fix it for the whole driver.

Another argument here is that someone could (conceivably) still have
an old kernel built from before the driver forked out. Maybe they care
about supporting "panel-himax-hx83102" panels on their old kernel.
They'd want the fix tagged so that they could find it.


> 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.

Sure, it's not a regression, but it's still a fix for a bug in the
panel driver. I don't know why someone wouldn't want to backport it if
they were using this panel.

-Doug