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

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

[Icenowy Zheng]

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@vger.kernel.org # 6.11+
Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 drivers/gpu/drm/panel/panel-himax-hx83102.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c
index 8b2a68ee851e3..a5e5c9ea7a73f 100644
--- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
+++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
@@ -937,6 +937,8 @@ static int hx83102_disable(struct drm_panel *panel)
 	mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
 	mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
 
+	dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
 	mipi_dsi_msleep(&dsi_ctx, 150);
 
 	return dsi_ctx.accum_err;
-- 
2.52.0

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

[Neil Armstrong]

On 4/25/26 18:57, Icenowy Zheng 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@vger.kernel.org # 6.11+
> Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver")
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
>   drivers/gpu/drm/panel/panel-himax-hx83102.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-himax-hx83102.c b/drivers/gpu/drm/panel/panel-himax-hx83102.c
> index 8b2a68ee851e3..a5e5c9ea7a73f 100644
> --- a/drivers/gpu/drm/panel/panel-himax-hx83102.c
> +++ b/drivers/gpu/drm/panel/panel-himax-hx83102.c
> @@ -937,6 +937,8 @@ static int hx83102_disable(struct drm_panel *panel)
>   	mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
>   	mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
>   
> +	dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
>   	mipi_dsi_msleep(&dsi_ctx, 150);
>   
>   	return dsi_ctx.accum_err;

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Thanks,
Neil

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

[Doug Anderson]

Hi,

On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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?

-Doug

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

[Icenowy Zheng]

在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> Hi,
> 
> On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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.

I have a device with a panel driven by the nl6 driver (device is
mt8183-kukui-kodama-sku32, panel is boe,tv101wum-n53), it shows the
same DSI timeout error message with ciri sku1, but the screen do come
back to life when unblanking. Maybe this fix should propagate there,
but I need more confirmation.

Thanks,
Icenowy

> 
> -Doug

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

[Doug Anderson]

Hi,

On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> > Hi,
> >
> > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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.

-Doug

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

[Icenowy Zheng]

在 2026-04-28二的 08:48 -0700，Doug Anderson写道：
> Hi,
> 
> On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > 
> > 在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> > > Hi,
> > > 
> > > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > > <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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.

Thanks,
Icenowy

> 
> -Doug

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

[Doug Anderson]

Hi,

On Tue, Apr 28, 2026 at 8:53 AM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> 在 2026-04-28二的 08:48 -0700，Doug Anderson写道：
> > Hi,
> >
> > On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > >
> > > 在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> > > > Hi,
> > > >
> > > > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > > > <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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!

-Doug

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

[Icenowy Zheng]

在 2026-04-28二的 08:56 -0700，Doug Anderson写道：
> Hi,
> 
> On Tue, Apr 28, 2026 at 8:53 AM Icenowy Zheng
> <zhengxingda@iscas.ac.cn> wrote:
> > 
> > 在 2026-04-28二的 08:48 -0700，Doug Anderson写道：
> > > Hi,
> > > 
> > > On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng
> > > <zhengxingda@iscas.ac.cn> wrote:
> > > > 
> > > > 在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> > > > > Hi,
> > > > > 
> > > > > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > > > > <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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

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@iscas.ac.cn> wrote:
>
> 在 2026-04-28二的 08:56 -0700，Doug Anderson写道：
> > Hi,
> >
> > On Tue, Apr 28, 2026 at 8:53 AM Icenowy Zheng
> > <zhengxingda@iscas.ac.cn> wrote:
> > >
> > > 在 2026-04-28二的 08:48 -0700，Doug Anderson写道：
> > > > Hi,
> > > >
> > > > On Mon, Apr 27, 2026 at 10:49 PM Icenowy Zheng
> > > > <zhengxingda@iscas.ac.cn> wrote:
> > > > >
> > > > > 在 2026-04-27一的 11:24 -0700，Doug Anderson写道：
> > > > > > Hi,
> > > > > >
> > > > > > On Sat, Apr 25, 2026 at 9:58 AM Icenowy Zheng
> > > > > > <zhengxingda@iscas.ac.cn> 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@vger.kernel.org # 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

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

[Doug Anderson]

Hi,

On Tue, Apr 28, 2026 at 1:52 PM Doug Anderson <dianders@chromium.org> wrote:
>
> > > > > > > > Cc: stable@vger.kernel.org # 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.

I see you've now also got a fix for panel-boe-tv101wum-nl6.c [1]. If
that patch also lands, then IMO this becomes fine.

[1] https://lore.kernel.org/r/20260503091708.1079962-1-zhengxingda@iscas.ac.cn/

Reviewed-by: Douglas Anderson <dianders@chromium.org>

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

[Neil Armstrong]

Hi,

On Sun, 26 Apr 2026 00:57:51 +0800, Icenowy Zheng 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.
> 
> [...]

Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes)

[1/1] drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmds
      https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/2d4e80271f784aa0c7b17676e9762c7e8156be1c

-- 
Neil