* [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
@ 2026-01-07 21:48 Hugo Villeneuve
2026-01-08 8:51 ` Geert Uytterhoeven
2026-01-08 9:12 ` Claudiu Beznea
0 siblings, 2 replies; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-07 21:48 UTC (permalink / raw)
To: dri-devel
Cc: linux-renesas-soc, linux-clk, linux-kernel, Claudiu Beznea,
Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi,
when issuing a reboot command, I encounter the following kernel panic:
[ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
[ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
[ 36.183504] Tainted: [M]=MACHINE_CHECK
[ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
[ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
[ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
[ 36.183547] sp : ffff8000813db860
[ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
[ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
[ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
[ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
[ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
[ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
[ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
[ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
[ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
[ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
[ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
[ 36.183665] Tainted: [M]=MACHINE_CHECK
[ 36.183668] Hardware name: devboard1 (DT)
[ 36.183672] Call trace:
[ 36.183675] show_stack+0x18/0x24 (C)
[ 36.183692] dump_stack_lvl+0x34/0x8c
[ 36.183702] dump_stack+0x18/0x24
[ 36.183708] vpanic+0x314/0x35c
[ 36.183716] nmi_panic+0x0/0x64
[ 36.183722] add_taint+0x0/0xbc
[ 36.183728] arm64_serror_panic+0x70/0x80
[ 36.183735] do_serror+0x28/0x68
[ 36.183742] el1h_64_error_handler+0x34/0x50
[ 36.183751] el1h_64_error+0x6c/0x70
[ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
[ 36.183770] mipi_dsi_device_transfer+0x44/0x58
[ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
[ 36.183792] ili9881c_unprepare+0x38/0x88
[ 36.183802] drm_panel_unprepare+0xbc/0x108
[ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
[ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
[ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
[ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
[ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
[ 36.183865] commit_tail+0xa4/0x18c
[ 36.183874] drm_atomic_helper_commit+0x17c/0x194
[ 36.183884] drm_atomic_commit+0x8c/0xcc
[ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
[ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
[ 36.183911] rzg2l_du_shutdown+0x18/0x24
[ 36.183920] platform_shutdown+0x24/0x34
[ 36.183931] device_shutdown+0x128/0x284
[ 36.183938] kernel_restart+0x44/0xa4
[ 36.183950] __do_sys_reboot+0x178/0x270
[ 36.183959] __arm64_sys_reboot+0x24/0x30
[ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
[ 36.183979] do_el0_svc+0x40/0xc0
[ 36.183988] el0_svc+0x3c/0x164
[ 36.183995] el0t_64_sync_handler+0xa0/0xe4
[ 36.184002] el0t_64_sync+0x198/0x19c
[ 36.184020] Kernel Offset: disabled
[ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
[ 36.184028] Memory Limit: none
[ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
After bisecting, here is the first bad commit:
commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
Reverting this change makes the bug disappear.
My limited understanding seems to indicate that the MIPI/DSI host may
no longer be available/on when the panel tries to send MIPI/DSI
commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
--
Hugo Villeneuve
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-07 21:48 [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot Hugo Villeneuve
@ 2026-01-08 8:51 ` Geert Uytterhoeven
2026-01-08 9:12 ` Claudiu Beznea
1 sibling, 0 replies; 15+ messages in thread
From: Geert Uytterhoeven @ 2026-01-08 8:51 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: dri-devel, linux-renesas-soc, linux-clk, linux-kernel,
Claudiu Beznea, Neil Armstrong, Jessica Zhang, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi Hugo,
On Wed, 7 Jan 2026 at 23:06, Hugo Villeneuve <hugo@hugovil.com> wrote:
> when issuing a reboot command, I encounter the following kernel panic:
>
> [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> [ 36.183504] Tainted: [M]=MACHINE_CHECK
> [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> [ 36.183547] sp : ffff8000813db860
> [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> [ 36.183665] Tainted: [M]=MACHINE_CHECK
> [ 36.183668] Hardware name: devboard1 (DT)
> [ 36.183672] Call trace:
> [ 36.183675] show_stack+0x18/0x24 (C)
> [ 36.183692] dump_stack_lvl+0x34/0x8c
> [ 36.183702] dump_stack+0x18/0x24
> [ 36.183708] vpanic+0x314/0x35c
> [ 36.183716] nmi_panic+0x0/0x64
> [ 36.183722] add_taint+0x0/0xbc
> [ 36.183728] arm64_serror_panic+0x70/0x80
> [ 36.183735] do_serror+0x28/0x68
> [ 36.183742] el1h_64_error_handler+0x34/0x50
> [ 36.183751] el1h_64_error+0x6c/0x70
> [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> [ 36.183792] ili9881c_unprepare+0x38/0x88
> [ 36.183802] drm_panel_unprepare+0xbc/0x108
> [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> [ 36.183865] commit_tail+0xa4/0x18c
> [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> [ 36.183884] drm_atomic_commit+0x8c/0xcc
> [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> [ 36.183920] platform_shutdown+0x24/0x34
> [ 36.183931] device_shutdown+0x128/0x284
> [ 36.183938] kernel_restart+0x44/0xa4
> [ 36.183950] __do_sys_reboot+0x178/0x270
> [ 36.183959] __arm64_sys_reboot+0x24/0x30
> [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> [ 36.183979] do_el0_svc+0x40/0xc0
> [ 36.183988] el0_svc+0x3c/0x164
> [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> [ 36.184002] el0t_64_sync+0x198/0x19c
> [ 36.184020] Kernel Offset: disabled
> [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> [ 36.184028] Memory Limit: none
> [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>
> The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
>
> The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
>
> After bisecting, here is the first bad commit:
>
> commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
>
> Reverting this change makes the bug disappear.
>
> My limited understanding seems to indicate that the MIPI/DSI host may
> no longer be available/on when the panel tries to send MIPI/DSI
> commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
Looks like the RZ/G2L driver is missing a pm_runtime_resume_and_get()
call in the shutdown path, or calls pm_runtime_put() too early.
> The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
The drivers for these panel indeed do not make any mipi_dsi_*() calls
from their .unprepare() callbacks.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-07 21:48 [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot Hugo Villeneuve
2026-01-08 8:51 ` Geert Uytterhoeven
@ 2026-01-08 9:12 ` Claudiu Beznea
2026-01-08 15:53 ` Hugo Villeneuve
1 sibling, 1 reply; 15+ messages in thread
From: Claudiu Beznea @ 2026-01-08 9:12 UTC (permalink / raw)
To: Hugo Villeneuve, dri-devel
Cc: linux-renesas-soc, linux-clk, linux-kernel, Claudiu Beznea,
Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi, Hugo,
On 1/7/26 23:48, Hugo Villeneuve wrote:
> Hi,
> when issuing a reboot command, I encounter the following kernel panic:
>
> [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> [ 36.183504] Tainted: [M]=MACHINE_CHECK
> [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> [ 36.183547] sp : ffff8000813db860
> [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> [ 36.183665] Tainted: [M]=MACHINE_CHECK
> [ 36.183668] Hardware name: devboard1 (DT)
> [ 36.183672] Call trace:
> [ 36.183675] show_stack+0x18/0x24 (C)
> [ 36.183692] dump_stack_lvl+0x34/0x8c
> [ 36.183702] dump_stack+0x18/0x24
> [ 36.183708] vpanic+0x314/0x35c
> [ 36.183716] nmi_panic+0x0/0x64
> [ 36.183722] add_taint+0x0/0xbc
> [ 36.183728] arm64_serror_panic+0x70/0x80
> [ 36.183735] do_serror+0x28/0x68
> [ 36.183742] el1h_64_error_handler+0x34/0x50
> [ 36.183751] el1h_64_error+0x6c/0x70
> [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> [ 36.183792] ili9881c_unprepare+0x38/0x88
> [ 36.183802] drm_panel_unprepare+0xbc/0x108
> [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> [ 36.183865] commit_tail+0xa4/0x18c
> [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> [ 36.183884] drm_atomic_commit+0x8c/0xcc
> [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> [ 36.183920] platform_shutdown+0x24/0x34
> [ 36.183931] device_shutdown+0x128/0x284
> [ 36.183938] kernel_restart+0x44/0xa4
> [ 36.183950] __do_sys_reboot+0x178/0x270
> [ 36.183959] __arm64_sys_reboot+0x24/0x30
> [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> [ 36.183979] do_el0_svc+0x40/0xc0
> [ 36.183988] el0_svc+0x3c/0x164
> [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> [ 36.184002] el0t_64_sync+0x198/0x19c
> [ 36.184020] Kernel Offset: disabled
> [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> [ 36.184028] Memory Limit: none
> [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>
> The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
>
> The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
>
> After bisecting, here is the first bad commit:
>
> commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
>
> Reverting this change makes the bug disappear.
>
> My limited understanding seems to indicate that the MIPI/DSI host may
> no longer be available/on when the panel tries to send MIPI/DSI
> commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
>
> The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
Could you please provide the output of command:
cat /sys/kernel/debug/mstop
for both cases?
Also, could you please check if the following diff solves your problem:
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
index 5edd45424562..62957632a96f 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
@@ -1282,6 +1282,10 @@ static ssize_t
rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
value |= SQCH0DSC0AR_FMT_SHORT;
}
+ ret = pm_runtime_resume_and_get(dsi->dev);
+ if (ret)
+ return ret;
+
rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
/*
@@ -1322,6 +1326,8 @@ static ssize_t rzg2l_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
ret = packet.payload_length;
}
+ pm_runtime_put(dsi->dev);
+
return ret;
}
Thank you,
Claudiu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 9:12 ` Claudiu Beznea
@ 2026-01-08 15:53 ` Hugo Villeneuve
2026-01-08 16:44 ` Biju Das
2026-01-09 9:49 ` Claudiu Beznea
0 siblings, 2 replies; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-08 15:53 UTC (permalink / raw)
To: Claudiu Beznea
Cc: dri-devel, linux-renesas-soc, linux-clk, linux-kernel,
Claudiu Beznea, Neil Armstrong, Jessica Zhang, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi Claudiu,
On Thu, 8 Jan 2026 11:12:54 +0200
Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> Hi, Hugo,
>
> On 1/7/26 23:48, Hugo Villeneuve wrote:
> > Hi,
> > when issuing a reboot command, I encounter the following kernel panic:
> >
> > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > [ 36.183547] sp : ffff8000813db860
> > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > [ 36.183668] Hardware name: devboard1 (DT)
> > [ 36.183672] Call trace:
> > [ 36.183675] show_stack+0x18/0x24 (C)
> > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > [ 36.183702] dump_stack+0x18/0x24
> > [ 36.183708] vpanic+0x314/0x35c
> > [ 36.183716] nmi_panic+0x0/0x64
> > [ 36.183722] add_taint+0x0/0xbc
> > [ 36.183728] arm64_serror_panic+0x70/0x80
> > [ 36.183735] do_serror+0x28/0x68
> > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > [ 36.183751] el1h_64_error+0x6c/0x70
> > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > [ 36.183865] commit_tail+0xa4/0x18c
> > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > [ 36.183920] platform_shutdown+0x24/0x34
> > [ 36.183931] device_shutdown+0x128/0x284
> > [ 36.183938] kernel_restart+0x44/0xa4
> > [ 36.183950] __do_sys_reboot+0x178/0x270
> > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > [ 36.183979] do_el0_svc+0x40/0xc0
> > [ 36.183988] el0_svc+0x3c/0x164
> > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > [ 36.184002] el0t_64_sync+0x198/0x19c
> > [ 36.184020] Kernel Offset: disabled
> > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > [ 36.184028] Memory Limit: none
> > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> >
> > The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
> >
> > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> >
> > After bisecting, here is the first bad commit:
> >
> > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
> >
> > Reverting this change makes the bug disappear.
> >
> > My limited understanding seems to indicate that the MIPI/DSI host may
> > no longer be available/on when the panel tries to send MIPI/DSI
> > commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
> >
> > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
>
> Could you please provide the output of command:
>
> cat /sys/kernel/debug/mstop
>
> for both cases?
Here it is for the panel which has the bug:
----------------------------------
MSTOP
clk -------------------------
clk_name cnt cnt off val shared
-------- ----- ----- ----- ------ ------
gic 1 1 0xb80 0x0
ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
dmac_aclk 2 1 0xb80 0x0
dmac_pclk 1 1 0xb80 0x0
ostm0_pclk 0 0 0xb7c 0x10
ostm1_pclk 1 1 0xb7c 0x0
ostm2_pclk 1 1 0xb7c 0x0
mtu_x_mck 0 0 0xb64 0x4
gpt_pclk 1 1 0xb64 0x0
poeg_a_clkp 0 0 0xb64 0x20
poeg_b_clkp 0 0 0xb64 0x40
poeg_c_clkp 0 0 0xb64 0x80
poeg_d_clkp 0 0 0xb64 0x100
wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
gpu_clk 1 1 0xb80 0x0
cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
lcdc_clk_d 3 1 0xb78 0x0
ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
usb0_host 3 1 0xb6c 0x0
usb1_host 0 0 0xb6c 0x80
usb0_func 1 1 0xb6c 0x0
usb_pclk 5 1 0xb6c 0x0
eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
i2c0 0 0 0xb68 0x400
i2c1 0 0 0xb68 0x800
i2c2 0 0 0xb68 0x1000
i2c3 0 0 0xb68 0x2000
scif0 2 1 0xb68 0x0
scif1 0 0 0xb68 0x4
scif2 0 0 0xb68 0x8
scif3 0 0 0xb68 0x10
scif4 0 0 0xb68 0x20
sci0 0 0 0xb68 0x80
sci1 0 0 0xb68 0x100
rspi0 0 0 0xb64 0x4000
rspi1 0 0 0xb64 0x8000
rspi2 0 0 0xb68 0x1
canfd 0 0 0xb68 0x200
gpio 1 1 0xb70 0x0
adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
tsu_pclk 1 1 0xb68 0x0
----------------------------------
I do not have acces to the other panels for the moment to run the same command.
> Also, could you please check if the following diff solves your problem:
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> index 5edd45424562..62957632a96f 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> @@ -1282,6 +1282,10 @@ static ssize_t
> rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> value |= SQCH0DSC0AR_FMT_SHORT;
> }
>
> + ret = pm_runtime_resume_and_get(dsi->dev);
> + if (ret)
> + return ret;
> +
> rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
>
> /*
> @@ -1322,6 +1326,8 @@ static ssize_t rzg2l_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> ret = packet.payload_length;
> }
>
> + pm_runtime_put(dsi->dev);
> +
> return ret;
> }
I confirm that it fixes the bug, altought I assume this is just for testing and is not the "proper" fix.
Thank you for looking into this.
Hugo.
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 15:53 ` Hugo Villeneuve
@ 2026-01-08 16:44 ` Biju Das
2026-01-08 17:51 ` Hugo Villeneuve
2026-01-09 9:49 ` Claudiu Beznea
1 sibling, 1 reply; 15+ messages in thread
From: Biju Das @ 2026-01-08 16:44 UTC (permalink / raw)
To: Hugo Villeneuve, Claudiu.Beznea
Cc: dri-devel, linux-renesas-soc, linux-clk, linux-kernel,
Claudiu Beznea, Neil Armstrong, Jessica Zhang, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Chris Brandt
Hi Hugo Villeneuve,
> -----Original Message-----
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 08 January 2026 15:53
> Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
>
> Hi Claudiu,
>
> On Thu, 8 Jan 2026 11:12:54 +0200
> Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
>
> > Hi, Hugo,
> >
> > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > Hi,
> > > when issuing a reboot command, I encounter the following kernel panic:
> > >
> > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-
> rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > [ 36.183547] sp : ffff8000813db860
> > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-
> rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > [ 36.183668] Hardware name: devboard1 (DT)
> > > [ 36.183672] Call trace:
> > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > [ 36.183702] dump_stack+0x18/0x24
> > > [ 36.183708] vpanic+0x314/0x35c
> > > [ 36.183716] nmi_panic+0x0/0x64
> > > [ 36.183722] add_taint+0x0/0xbc
> > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > [ 36.183735] do_serror+0x28/0x68
> > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > [ 36.183865] commit_tail+0xa4/0x18c
> > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > [ 36.183920] platform_shutdown+0x24/0x34
> > > [ 36.183931] device_shutdown+0x128/0x284
> > > [ 36.183938] kernel_restart+0x44/0xa4
> > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > [ 36.183988] el0_svc+0x3c/0x164
> > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > [ 36.184020] Kernel Offset: disabled
> > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > [ 36.184028] Memory Limit: none
> > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > >
> > > The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is
> present in linux-6.19-rc4.
> > >
> > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > >
> > > After bisecting, here is the first bad commit:
> > >
> > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for
> > > RZ/G2L")
> > >
> > > Reverting this change makes the bug disappear.
> > >
> > > My limited understanding seems to indicate that the MIPI/DSI host
> > > may no longer be available/on when the panel tries to send MIPI/DSI
> > > commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
> > >
> > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> >
> > Could you please provide the output of command:
> >
> > cat /sys/kernel/debug/mstop
> >
> > for both cases?
>
> Here it is for the panel which has the bug:
>
> ----------------------------------
> MSTOP
> clk -------------------------
> clk_name cnt cnt off val shared
> -------- ----- ----- ----- ------ ------
> gic 1 1 0xb80 0x0
> ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> dmac_aclk 2 1 0xb80 0x0
> dmac_pclk 1 1 0xb80 0x0
> ostm0_pclk 0 0 0xb7c 0x10
> ostm1_pclk 1 1 0xb7c 0x0
> ostm2_pclk 1 1 0xb7c 0x0
> mtu_x_mck 0 0 0xb64 0x4
> gpt_pclk 1 1 0xb64 0x0
> poeg_a_clkp 0 0 0xb64 0x20
> poeg_b_clkp 0 0 0xb64 0x40
> poeg_c_clkp 0 0 0xb64 0x80
> poeg_d_clkp 0 0 0xb64 0x100
> wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> gpu_clk 1 1 0xb80 0x0
> cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> dsi_lpclk
> lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> lcdc_clk_d 3 1 0xb78 0x0
> ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> usb0_host 3 1 0xb6c 0x0
> usb1_host 0 0 0xb6c 0x80
> usb0_func 1 1 0xb6c 0x0
> usb_pclk 5 1 0xb6c 0x0
> eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> i2c0 0 0 0xb68 0x400
> i2c1 0 0 0xb68 0x800
> i2c2 0 0 0xb68 0x1000
> i2c3 0 0 0xb68 0x2000
> scif0 2 1 0xb68 0x0
> scif1 0 0 0xb68 0x4
> scif2 0 0 0xb68 0x8
> scif3 0 0 0xb68 0x10
> scif4 0 0 0xb68 0x20
> sci0 0 0 0xb68 0x80
> sci1 0 0 0xb68 0x100
> rspi0 0 0 0xb64 0x4000
> rspi1 0 0 0xb64 0x8000
> rspi2 0 0 0xb68 0x1
> canfd 0 0 0xb68 0x200
> gpio 1 1 0xb70 0x0
> adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> tsu_pclk 1 1 0xb68 0x0
> ----------------------------------
>
> I do not have acces to the other panels for the moment to run the same command.
>
>
> > Also, could you please check if the following diff solves your problem:
> >
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > index 5edd45424562..62957632a96f 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > @@ -1282,6 +1282,10 @@ static ssize_t
> > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > value |= SQCH0DSC0AR_FMT_SHORT;
> > }
> >
> > + ret = pm_runtime_resume_and_get(dsi->dev);
> > + if (ret)
> > + return ret;
> > +
> > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> >
> > /*
> > @@ -1322,6 +1326,8 @@ static ssize_t
> > rzg2l_mipi_dsi_host_transfer(struct
> > mipi_dsi_host *host,
> > ret = packet.payload_length;
> > }
> >
> > + pm_runtime_put(dsi->dev);
> > +
> > return ret;
> > }
>
> I confirm that it fixes the bug, altought I assume this is just for testing and is not the "proper"
> fix.
Pre-MSTOP case during reboot, without clk it is accessing registers)(mstop off always)
it won't crash. But looks like you may have ignored timeout error from [1].
Post MSTOP case, if you access registers with mstop on, it will lead to crash.
and the patch fixes crash.
Basically, you are accessing link register after video is stopped with this panel.
Looks like it is a fix for me.
Better check if there is any timeout error[1] with this patch. if not,
It is proper fix.
[1] https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c#L893
Cheers,
Biju
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 16:44 ` Biju Das
@ 2026-01-08 17:51 ` Hugo Villeneuve
2026-01-08 21:21 ` Biju Das
0 siblings, 1 reply; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-08 17:51 UTC (permalink / raw)
To: Biju Das
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Biju,
On Thu, 8 Jan 2026 16:44:37 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo Villeneuve,
>
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 08 January 2026 15:53
> > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
> >
> > Hi Claudiu,
> >
> > On Thu, 8 Jan 2026 11:12:54 +0200
> > Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> >
> > > Hi, Hugo,
> > >
> > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > Hi,
> > > > when issuing a reboot command, I encounter the following kernel panic:
> > > >
> > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-
> > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > [ 36.183547] sp : ffff8000813db860
> > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-
> > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > [ 36.183672] Call trace:
> > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > [ 36.183702] dump_stack+0x18/0x24
> > > > [ 36.183708] vpanic+0x314/0x35c
> > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > [ 36.183722] add_taint+0x0/0xbc
> > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > [ 36.183735] do_serror+0x28/0x68
> > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > [ 36.184020] Kernel Offset: disabled
> > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > [ 36.184028] Memory Limit: none
> > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > >
> > > > The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is
> > present in linux-6.19-rc4.
> > > >
> > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > >
> > > > After bisecting, here is the first bad commit:
> > > >
> > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for
> > > > RZ/G2L")
> > > >
> > > > Reverting this change makes the bug disappear.
> > > >
> > > > My limited understanding seems to indicate that the MIPI/DSI host
> > > > may no longer be available/on when the panel tries to send MIPI/DSI
> > > > commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
> > > >
> > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > >
> > > Could you please provide the output of command:
> > >
> > > cat /sys/kernel/debug/mstop
> > >
> > > for both cases?
> >
> > Here it is for the panel which has the bug:
> >
> > ----------------------------------
> > MSTOP
> > clk -------------------------
> > clk_name cnt cnt off val shared
> > -------- ----- ----- ----- ------ ------
> > gic 1 1 0xb80 0x0
> > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > dmac_aclk 2 1 0xb80 0x0
> > dmac_pclk 1 1 0xb80 0x0
> > ostm0_pclk 0 0 0xb7c 0x10
> > ostm1_pclk 1 1 0xb7c 0x0
> > ostm2_pclk 1 1 0xb7c 0x0
> > mtu_x_mck 0 0 0xb64 0x4
> > gpt_pclk 1 1 0xb64 0x0
> > poeg_a_clkp 0 0 0xb64 0x20
> > poeg_b_clkp 0 0 0xb64 0x40
> > poeg_c_clkp 0 0 0xb64 0x80
> > poeg_d_clkp 0 0 0xb64 0x100
> > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > gpu_clk 1 1 0xb80 0x0
> > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > dsi_lpclk
> > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > lcdc_clk_d 3 1 0xb78 0x0
> > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > usb0_host 3 1 0xb6c 0x0
> > usb1_host 0 0 0xb6c 0x80
> > usb0_func 1 1 0xb6c 0x0
> > usb_pclk 5 1 0xb6c 0x0
> > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > i2c0 0 0 0xb68 0x400
> > i2c1 0 0 0xb68 0x800
> > i2c2 0 0 0xb68 0x1000
> > i2c3 0 0 0xb68 0x2000
> > scif0 2 1 0xb68 0x0
> > scif1 0 0 0xb68 0x4
> > scif2 0 0 0xb68 0x8
> > scif3 0 0 0xb68 0x10
> > scif4 0 0 0xb68 0x20
> > sci0 0 0 0xb68 0x80
> > sci1 0 0 0xb68 0x100
> > rspi0 0 0 0xb64 0x4000
> > rspi1 0 0 0xb64 0x8000
> > rspi2 0 0 0xb68 0x1
> > canfd 0 0 0xb68 0x200
> > gpio 1 1 0xb70 0x0
> > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > tsu_pclk 1 1 0xb68 0x0
> > ----------------------------------
> >
> > I do not have acces to the other panels for the moment to run the same command.
> >
> >
> > > Also, could you please check if the following diff solves your problem:
> > >
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > index 5edd45424562..62957632a96f 100644
> > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > }
> > >
> > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> > >
> > > /*
> > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > rzg2l_mipi_dsi_host_transfer(struct
> > > mipi_dsi_host *host,
> > > ret = packet.payload_length;
> > > }
> > >
> > > + pm_runtime_put(dsi->dev);
> > > +
> > > return ret;
> > > }
> >
> > I confirm that it fixes the bug, altought I assume this is just for testing and is not the "proper"
> > fix.
>
> Pre-MSTOP case during reboot, without clk it is accessing registers)(mstop off always)
> it won't crash. But looks like you may have ignored timeout error from [1].
In case of a timeout error, it is not really ignored as the proper error
code -ETIMEDOUT will be returned by rzg2l_mipi_dsi_host_transfer() (see log below). The
hardware manual doesn't seem to properly explain how to deal with a
timeout (or I could not find it). Do you have any suggestion on how to
improve this?
>
> Post MSTOP case, if you access registers with mstop on, it will lead to crash.
>
> and the patch fixes crash.
>
> Basically, you are accessing link register after video is stopped with this panel.
> Looks like it is a fix for me.
Ok, like I said I am not an expert on this, but I was just
assuming that there was a better way to ensure that the mipi/dsi
interface was still active until the panel unprepare() function
could do its work. I was looking at some other drivers mipi/dsi
host_transfer() functions and did not see a similar
pm_runtime_resume_and_get() scheme, hence my confusion.
> Better check if there is any timeout error[1] with this patch. if not,
> It is proper fix.
The patch does fixes the kernel panic, but
doesn't allow the panel to be properly unprepared,
as I just noticed the timeout message:
[ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
In my case, for a reboot, this is not a problem, but it may be a problem for systems where it can be suspended (I assume)?
Thank you for your help with this.
Hugo.
>
> [1] https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c#L893
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 17:51 ` Hugo Villeneuve
@ 2026-01-08 21:21 ` Biju Das
2026-01-09 15:04 ` Hugo Villeneuve
0 siblings, 1 reply; 15+ messages in thread
From: Biju Das @ 2026-01-08 21:21 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Hugo,
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 08 January 2026 17:52
> Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
>
> Hi Biju,
>
> On Thu, 8 Jan 2026 16:44:37 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> > Hi Hugo Villeneuve,
> >
> > > -----Original Message-----
> > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > Sent: 08 January 2026 15:53
> > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > reboot
> > >
> > > Hi Claudiu,
> > >
> > > On Thu, 8 Jan 2026 11:12:54 +0200
> > > Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> > >
> > > > Hi, Hugo,
> > > >
> > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > Hi,
> > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > >
> > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> 6.19.0-
> > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > [ 36.183547] sp : ffff8000813db860
> > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> 6.19.0-
> > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > [ 36.183672] Call trace:
> > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > [ 36.184020] Kernel Offset: disabled
> > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > [ 36.184028] Memory Limit: none
> > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > >
> > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > linux-6.17. I also confirm the bug is
> > > present in linux-6.19-rc4.
> > > > >
> > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > >
> > > > > After bisecting, here is the first bad commit:
> > > > >
> > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP
> > > > > for
> > > > > RZ/G2L")
> > > > >
> > > > > Reverting this change makes the bug disappear.
> > > > >
> > > > > My limited understanding seems to indicate that the MIPI/DSI
> > > > > host may no longer be available/on when the panel tries to send
> > > > > MIPI/DSI commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been
> stopped...
> > > > >
> > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > >
> > > > Could you please provide the output of command:
> > > >
> > > > cat /sys/kernel/debug/mstop
> > > >
> > > > for both cases?
> > >
> > > Here it is for the panel which has the bug:
> > >
> > > ----------------------------------
> > > MSTOP
> > > clk -------------------------
> > > clk_name cnt cnt off val shared
> > > -------- ----- ----- ----- ------ ------
> > > gic 1 1 0xb80 0x0
> > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > dmac_aclk 2 1 0xb80 0x0
> > > dmac_pclk 1 1 0xb80 0x0
> > > ostm0_pclk 0 0 0xb7c 0x10
> > > ostm1_pclk 1 1 0xb7c 0x0
> > > ostm2_pclk 1 1 0xb7c 0x0
> > > mtu_x_mck 0 0 0xb64 0x4
> > > gpt_pclk 1 1 0xb64 0x0
> > > poeg_a_clkp 0 0 0xb64 0x20
> > > poeg_b_clkp 0 0 0xb64 0x40
> > > poeg_c_clkp 0 0 0xb64 0x80
> > > poeg_d_clkp 0 0 0xb64 0x100
> > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > gpu_clk 1 1 0xb80 0x0
> > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > dsi_lpclk
> > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > lcdc_clk_d 3 1 0xb78 0x0
> > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > usb0_host 3 1 0xb6c 0x0
> > > usb1_host 0 0 0xb6c 0x80
> > > usb0_func 1 1 0xb6c 0x0
> > > usb_pclk 5 1 0xb6c 0x0
> > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > i2c0 0 0 0xb68 0x400
> > > i2c1 0 0 0xb68 0x800
> > > i2c2 0 0 0xb68 0x1000
> > > i2c3 0 0 0xb68 0x2000
> > > scif0 2 1 0xb68 0x0
> > > scif1 0 0 0xb68 0x4
> > > scif2 0 0 0xb68 0x8
> > > scif3 0 0 0xb68 0x10
> > > scif4 0 0 0xb68 0x20
> > > sci0 0 0 0xb68 0x80
> > > sci1 0 0 0xb68 0x100
> > > rspi0 0 0 0xb64 0x4000
> > > rspi1 0 0 0xb64 0x8000
> > > rspi2 0 0 0xb68 0x1
> > > canfd 0 0 0xb68 0x200
> > > gpio 1 1 0xb70 0x0
> > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > tsu_pclk 1 1 0xb68 0x0
> > > ----------------------------------
> > >
> > > I do not have acces to the other panels for the moment to run the same command.
> > >
> > >
> > > > Also, could you please check if the following diff solves your problem:
> > > >
> > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > index 5edd45424562..62957632a96f 100644
> > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > }
> > > >
> > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> > > >
> > > > /*
> > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > mipi_dsi_host *host,
> > > > ret = packet.payload_length;
> > > > }
> > > >
> > > > + pm_runtime_put(dsi->dev);
> > > > +
> > > > return ret;
> > > > }
> > >
> > > I confirm that it fixes the bug, altought I assume this is just for testing and is not the
> "proper"
> > > fix.
> >
> > Pre-MSTOP case during reboot, without clk it is accessing
> > registers)(mstop off always) it won't crash. But looks like you may have ignored timeout error from
> [1].
>
> In case of a timeout error, it is not really ignored as the proper error code -ETIMEDOUT will be
> returned by rzg2l_mipi_dsi_host_transfer() (see log below). The hardware manual doesn't seem to
> properly explain how to deal with a timeout (or I could not find it). Do you have any suggestion on
> how to improve this?
>
> >
> > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> >
> > and the patch fixes crash.
> >
> > Basically, you are accessing link register after video is stopped with this panel.
> > Looks like it is a fix for me.
>
> Ok, like I said I am not an expert on this, but I was just assuming that there was a better way to
> ensure that the mipi/dsi interface was still active until the panel unprepare() function could do its
> work. I was looking at some other drivers mipi/dsi
> host_transfer() functions and did not see a similar
> pm_runtime_resume_and_get() scheme, hence my confusion.
>
> > Better check if there is any timeout error[1] with this patch. if not,
> > It is proper fix.
>
> The patch does fixes the kernel panic, but doesn't allow the panel to be properly unprepared, as I
> just noticed the timeout message:
>
> [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
>
> In my case, for a reboot, this is not a problem, but it may be a problem for systems where it can be
> suspended (I assume)?
>
> Thank you for your help with this.
Can you please try implement .atomic_post_disable() symmetrical to rzg2l_mipi_dsi_atomic_pre_enable?
Ie, move just rzg2l_mipi_dsi_stop(dsi) from rzg2l_mipi_dsi_atomic_disable() to rzg2l_mipi_dsi_atomic_post_disable()
and check you can send DCS SET_DISPLAY_OFF successfully.
Cheers,
Biju
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 15:53 ` Hugo Villeneuve
2026-01-08 16:44 ` Biju Das
@ 2026-01-09 9:49 ` Claudiu Beznea
2026-01-09 15:47 ` Hugo Villeneuve
1 sibling, 1 reply; 15+ messages in thread
From: Claudiu Beznea @ 2026-01-09 9:49 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: dri-devel, linux-renesas-soc, linux-clk, linux-kernel,
Claudiu Beznea, Neil Armstrong, Jessica Zhang, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi, Hugo,
On 1/8/26 17:53, Hugo Villeneuve wrote:
> Hi Claudiu,
>
> On Thu, 8 Jan 2026 11:12:54 +0200
> Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
>
>> Hi, Hugo,
>>
>> On 1/7/26 23:48, Hugo Villeneuve wrote:
>>> Hi,
>>> when issuing a reboot command, I encounter the following kernel panic:
>>>
>>> [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
>>> [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
>>> [ 36.183504] Tainted: [M]=MACHINE_CHECK
>>> [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
>>> [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>> [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
>>> [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
>>> [ 36.183547] sp : ffff8000813db860
>>> [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
>>> [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
>>> [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
>>> [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
>>> [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
>>> [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
>>> [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
>>> [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
>>> [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
>>> [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
>>> [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
>>> [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
>>> [ 36.183665] Tainted: [M]=MACHINE_CHECK
>>> [ 36.183668] Hardware name: devboard1 (DT)
>>> [ 36.183672] Call trace:
>>> [ 36.183675] show_stack+0x18/0x24 (C)
>>> [ 36.183692] dump_stack_lvl+0x34/0x8c
>>> [ 36.183702] dump_stack+0x18/0x24
>>> [ 36.183708] vpanic+0x314/0x35c
>>> [ 36.183716] nmi_panic+0x0/0x64
>>> [ 36.183722] add_taint+0x0/0xbc
>>> [ 36.183728] arm64_serror_panic+0x70/0x80
>>> [ 36.183735] do_serror+0x28/0x68
>>> [ 36.183742] el1h_64_error_handler+0x34/0x50
>>> [ 36.183751] el1h_64_error+0x6c/0x70
>>> [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
>>> [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
>>> [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
>>> [ 36.183792] ili9881c_unprepare+0x38/0x88
>>> [ 36.183802] drm_panel_unprepare+0xbc/0x108
>>> [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
>>> [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
>>> [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
>>> [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
>>> [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
>>> [ 36.183865] commit_tail+0xa4/0x18c
>>> [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
>>> [ 36.183884] drm_atomic_commit+0x8c/0xcc
>>> [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
>>> [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
>>> [ 36.183911] rzg2l_du_shutdown+0x18/0x24
>>> [ 36.183920] platform_shutdown+0x24/0x34
>>> [ 36.183931] device_shutdown+0x128/0x284
>>> [ 36.183938] kernel_restart+0x44/0xa4
>>> [ 36.183950] __do_sys_reboot+0x178/0x270
>>> [ 36.183959] __arm64_sys_reboot+0x24/0x30
>>> [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
>>> [ 36.183979] do_el0_svc+0x40/0xc0
>>> [ 36.183988] el0_svc+0x3c/0x164
>>> [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
>>> [ 36.184002] el0t_64_sync+0x198/0x19c
>>> [ 36.184020] Kernel Offset: disabled
>>> [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
>>> [ 36.184028] Memory Limit: none
>>> [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>>>
>>> The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
>>>
>>> The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
>>>
>>> After bisecting, here is the first bad commit:
>>>
>>> commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
>>>
>>> Reverting this change makes the bug disappear.
>>>
>>> My limited understanding seems to indicate that the MIPI/DSI host may
>>> no longer be available/on when the panel tries to send MIPI/DSI
>>> commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
>>>
>>> The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
>>
>> Could you please provide the output of command:
>>
>> cat /sys/kernel/debug/mstop
>>
>> for both cases?
>
> Here it is for the panel which has the bug:
>
> ----------------------------------
> MSTOP
> clk -------------------------
> clk_name cnt cnt off val shared
> -------- ----- ----- ----- ------ ------
> gic 1 1 0xb80 0x0
> ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> dmac_aclk 2 1 0xb80 0x0
> dmac_pclk 1 1 0xb80 0x0
> ostm0_pclk 0 0 0xb7c 0x10
> ostm1_pclk 1 1 0xb7c 0x0
> ostm2_pclk 1 1 0xb7c 0x0
> mtu_x_mck 0 0 0xb64 0x4
> gpt_pclk 1 1 0xb64 0x0
> poeg_a_clkp 0 0 0xb64 0x20
> poeg_b_clkp 0 0 0xb64 0x40
> poeg_c_clkp 0 0 0xb64 0x80
> poeg_d_clkp 0 0 0xb64 0x100
> wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> gpu_clk 1 1 0xb80 0x0
> cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
I was expected the MSTOP for these to be set to anythong other than 0x0
here. But I presume, they are somehow set in the reboot process before
exectution reach rzg2l_mipi_dsi_host_transfer(). To be honest, I don't
know the rz-du code.
[...]
>
> I do not have acces to the other panels for the moment to run the same command.
>
>
>> Also, could you please check if the following diff solves your problem:
>>
>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>> b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>> index 5edd45424562..62957632a96f 100644
>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
>> @@ -1282,6 +1282,10 @@ static ssize_t
>> rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
>> value |= SQCH0DSC0AR_FMT_SHORT;
>> }
>>
>> + ret = pm_runtime_resume_and_get(dsi->dev);
>> + if (ret)
>> + return ret;
>> +
>> rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
>>
>> /*
>> @@ -1322,6 +1326,8 @@ static ssize_t rzg2l_mipi_dsi_host_transfer(struct
>> mipi_dsi_host *host,
>> ret = packet.payload_length;
>> }
>>
>> + pm_runtime_put(dsi->dev);
>> +
>> return ret;
>> }
>
> I confirm that it fixes the bug, altought I assume this is just for testing and is not the "proper" fix.
To me, this, or something similar should be done anyway. Previously it
used to work because there was no MSTOP support available.
The MSTOP is now set when all of the clocks sharing it are disabled.
With the MSTOP set, any master accessing a HW block that has MSTOP set
will get sync abort. That wasn't the case previously, when the HW
registers could have been accessed w/o generating such exeception.
Thank you,
Claudiu
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-08 21:21 ` Biju Das
@ 2026-01-09 15:04 ` Hugo Villeneuve
2026-01-09 15:57 ` Biju Das
0 siblings, 1 reply; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-09 15:04 UTC (permalink / raw)
To: Biju Das
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Biju,
On Thu, 8 Jan 2026 21:21:00 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo,
>
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 08 January 2026 17:52
> > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
> >
> > Hi Biju,
> >
> > On Thu, 8 Jan 2026 16:44:37 +0000
> > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > > Hi Hugo Villeneuve,
> > >
> > > > -----Original Message-----
> > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > Sent: 08 January 2026 15:53
> > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > reboot
> > > >
> > > > Hi Claudiu,
> > > >
> > > > On Thu, 8 Jan 2026 11:12:54 +0200
> > > > Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> > > >
> > > > > Hi, Hugo,
> > > > >
> > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > Hi,
> > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > >
> > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > 6.19.0-
> > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > 6.19.0-
> > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > [ 36.183672] Call trace:
> > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > [ 36.184028] Memory Limit: none
> > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > > >
> > > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > > linux-6.17. I also confirm the bug is
> > > > present in linux-6.19-rc4.
> > > > > >
> > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > >
> > > > > > After bisecting, here is the first bad commit:
> > > > > >
> > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP
> > > > > > for
> > > > > > RZ/G2L")
> > > > > >
> > > > > > Reverting this change makes the bug disappear.
> > > > > >
> > > > > > My limited understanding seems to indicate that the MIPI/DSI
> > > > > > host may no longer be available/on when the panel tries to send
> > > > > > MIPI/DSI commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been
> > stopped...
> > > > > >
> > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > > >
> > > > > Could you please provide the output of command:
> > > > >
> > > > > cat /sys/kernel/debug/mstop
> > > > >
> > > > > for both cases?
> > > >
> > > > Here it is for the panel which has the bug:
> > > >
> > > > ----------------------------------
> > > > MSTOP
> > > > clk -------------------------
> > > > clk_name cnt cnt off val shared
> > > > -------- ----- ----- ----- ------ ------
> > > > gic 1 1 0xb80 0x0
> > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > dmac_aclk 2 1 0xb80 0x0
> > > > dmac_pclk 1 1 0xb80 0x0
> > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > mtu_x_mck 0 0 0xb64 0x4
> > > > gpt_pclk 1 1 0xb64 0x0
> > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > gpu_clk 1 1 0xb80 0x0
> > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk
> > > > dsi_lpclk
> > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > usb0_host 3 1 0xb6c 0x0
> > > > usb1_host 0 0 0xb6c 0x80
> > > > usb0_func 1 1 0xb6c 0x0
> > > > usb_pclk 5 1 0xb6c 0x0
> > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > i2c0 0 0 0xb68 0x400
> > > > i2c1 0 0 0xb68 0x800
> > > > i2c2 0 0 0xb68 0x1000
> > > > i2c3 0 0 0xb68 0x2000
> > > > scif0 2 1 0xb68 0x0
> > > > scif1 0 0 0xb68 0x4
> > > > scif2 0 0 0xb68 0x8
> > > > scif3 0 0 0xb68 0x10
> > > > scif4 0 0 0xb68 0x20
> > > > sci0 0 0 0xb68 0x80
> > > > sci1 0 0 0xb68 0x100
> > > > rspi0 0 0 0xb64 0x4000
> > > > rspi1 0 0 0xb64 0x8000
> > > > rspi2 0 0 0xb68 0x1
> > > > canfd 0 0 0xb68 0x200
> > > > gpio 1 1 0xb70 0x0
> > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > tsu_pclk 1 1 0xb68 0x0
> > > > ----------------------------------
> > > >
> > > > I do not have acces to the other panels for the moment to run the same command.
> > > >
> > > >
> > > > > Also, could you please check if the following diff solves your problem:
> > > > >
> > > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > index 5edd45424562..62957632a96f 100644
> > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > }
> > > > >
> > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> > > > >
> > > > > /*
> > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > mipi_dsi_host *host,
> > > > > ret = packet.payload_length;
> > > > > }
> > > > >
> > > > > + pm_runtime_put(dsi->dev);
> > > > > +
> > > > > return ret;
> > > > > }
> > > >
> > > > I confirm that it fixes the bug, altought I assume this is just for testing and is not the
> > "proper"
> > > > fix.
> > >
> > > Pre-MSTOP case during reboot, without clk it is accessing
> > > registers)(mstop off always) it won't crash. But looks like you may have ignored timeout error from
> > [1].
> >
> > In case of a timeout error, it is not really ignored as the proper error code -ETIMEDOUT will be
> > returned by rzg2l_mipi_dsi_host_transfer() (see log below). The hardware manual doesn't seem to
> > properly explain how to deal with a timeout (or I could not find it). Do you have any suggestion on
> > how to improve this?
> >
> > >
> > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > >
> > > and the patch fixes crash.
> > >
> > > Basically, you are accessing link register after video is stopped with this panel.
> > > Looks like it is a fix for me.
> >
> > Ok, like I said I am not an expert on this, but I was just assuming that there was a better way to
> > ensure that the mipi/dsi interface was still active until the panel unprepare() function could do its
> > work. I was looking at some other drivers mipi/dsi
> > host_transfer() functions and did not see a similar
> > pm_runtime_resume_and_get() scheme, hence my confusion.
> >
> > > Better check if there is any timeout error[1] with this patch. if not,
> > > It is proper fix.
> >
> > The patch does fixes the kernel panic, but doesn't allow the panel to be properly unprepared, as I
> > just noticed the timeout message:
> >
> > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> >
> > In my case, for a reboot, this is not a problem, but it may be a problem for systems where it can be
> > suspended (I assume)?
> >
> > Thank you for your help with this.
>
> Can you please try implement .atomic_post_disable() symmetrical to rzg2l_mipi_dsi_atomic_pre_enable?
>
> Ie, move just rzg2l_mipi_dsi_stop(dsi) from rzg2l_mipi_dsi_atomic_disable() to rzg2l_mipi_dsi_atomic_post_disable()
>
> and check you can send DCS SET_DISPLAY_OFF successfully.
I reverted the previous fix (pm_runtime_resume_and_get), and implemented
.atomic_post_disable as you suggested, and this works great: the bug is
no longer present and I do not see timeout errors:
[ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 537.734544] systemd-shutdown[1]: Rebooting.
[ 538.520174] rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry
[ 538.547848] ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry
[ 538.564524] rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry
[ 538.574016] reboot: Restarting system
Hugo.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 9:49 ` Claudiu Beznea
@ 2026-01-09 15:47 ` Hugo Villeneuve
0 siblings, 0 replies; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-09 15:47 UTC (permalink / raw)
To: Claudiu Beznea
Cc: dri-devel, linux-renesas-soc, linux-clk, linux-kernel,
Claudiu Beznea, Neil Armstrong, Jessica Zhang, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Biju Das Biju Das, Chris Brandt
Hi Claudiu,
On Fri, 9 Jan 2026 11:49:23 +0200
Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> Hi, Hugo,
>
> On 1/8/26 17:53, Hugo Villeneuve wrote:
> > Hi Claudiu,
> >
> > On Thu, 8 Jan 2026 11:12:54 +0200
> > Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote:
> >
> >> Hi, Hugo,
> >>
> >> On 1/7/26 23:48, Hugo Villeneuve wrote:
> >>> Hi,
> >>> when issuing a reboot command, I encounter the following kernel panic:
> >>>
> >>> [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> >>> [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> >>> [ 36.183504] Tainted: [M]=MACHINE_CHECK
> >>> [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> >>> [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> >>> [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> >>> [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> >>> [ 36.183547] sp : ffff8000813db860
> >>> [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> >>> [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> >>> [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> >>> [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> >>> [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> >>> [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> >>> [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> >>> [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> >>> [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> >>> [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> >>> [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> >>> [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M 6.19.0-rc4-arm64-renesas-00019-g067a81578add #62 NONE
> >>> [ 36.183665] Tainted: [M]=MACHINE_CHECK
> >>> [ 36.183668] Hardware name: devboard1 (DT)
> >>> [ 36.183672] Call trace:
> >>> [ 36.183675] show_stack+0x18/0x24 (C)
> >>> [ 36.183692] dump_stack_lvl+0x34/0x8c
> >>> [ 36.183702] dump_stack+0x18/0x24
> >>> [ 36.183708] vpanic+0x314/0x35c
> >>> [ 36.183716] nmi_panic+0x0/0x64
> >>> [ 36.183722] add_taint+0x0/0xbc
> >>> [ 36.183728] arm64_serror_panic+0x70/0x80
> >>> [ 36.183735] do_serror+0x28/0x68
> >>> [ 36.183742] el1h_64_error_handler+0x34/0x50
> >>> [ 36.183751] el1h_64_error+0x6c/0x70
> >>> [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> >>> [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> >>> [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> >>> [ 36.183792] ili9881c_unprepare+0x38/0x88
> >>> [ 36.183802] drm_panel_unprepare+0xbc/0x108
> >>> [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> >>> [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> >>> [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> >>> [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> >>> [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> >>> [ 36.183865] commit_tail+0xa4/0x18c
> >>> [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> >>> [ 36.183884] drm_atomic_commit+0x8c/0xcc
> >>> [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> >>> [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> >>> [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> >>> [ 36.183920] platform_shutdown+0x24/0x34
> >>> [ 36.183931] device_shutdown+0x128/0x284
> >>> [ 36.183938] kernel_restart+0x44/0xa4
> >>> [ 36.183950] __do_sys_reboot+0x178/0x270
> >>> [ 36.183959] __arm64_sys_reboot+0x24/0x30
> >>> [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> >>> [ 36.183979] do_el0_svc+0x40/0xc0
> >>> [ 36.183988] el0_svc+0x3c/0x164
> >>> [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> >>> [ 36.184002] el0t_64_sync+0x198/0x19c
> >>> [ 36.184020] Kernel Offset: disabled
> >>> [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> >>> [ 36.184028] Memory Limit: none
> >>> [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> >>>
> >>> The problem is present since linux-6.18-rc1, but not in linux-6.17. I also confirm the bug is present in linux-6.19-rc4.
> >>>
> >>> The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> >>>
> >>> After bisecting, here is the first bad commit:
> >>>
> >>> commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
> >>>
> >>> Reverting this change makes the bug disappear.
> >>>
> >>> My limited understanding seems to indicate that the MIPI/DSI host may
> >>> no longer be available/on when the panel tries to send MIPI/DSI
> >>> commands in ili9881c_unprepare(), maybe because the MIPI/DSI clock has been stopped...
> >>>
> >>> The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> >>
> >> Could you please provide the output of command:
> >>
> >> cat /sys/kernel/debug/mstop
> >>
> >> for both cases?
> >
> > Here it is for the panel which has the bug:
> >
> > ----------------------------------
> > MSTOP
> > clk -------------------------
> > clk_name cnt cnt off val shared
> > -------- ----- ----- ----- ------ ------
> > gic 1 1 0xb80 0x0
> > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > dmac_aclk 2 1 0xb80 0x0
> > dmac_pclk 1 1 0xb80 0x0
> > ostm0_pclk 0 0 0xb7c 0x10
> > ostm1_pclk 1 1 0xb7c 0x0
> > ostm2_pclk 1 1 0xb7c 0x0
> > mtu_x_mck 0 0 0xb64 0x4
> > gpt_pclk 1 1 0xb64 0x0
> > poeg_a_clkp 0 0 0xb64 0x20
> > poeg_b_clkp 0 0 0xb64 0x40
> > poeg_c_clkp 0 0 0xb64 0x80
> > poeg_d_clkp 0 0 0xb64 0x100
> > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > gpu_clk 1 1 0xb80 0x0
> > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
>
> > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
> > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk dsi_vclk dsi_lpclk
>
> I was expected the MSTOP for these to be set to anythong other than 0x0
> here. But I presume, they are somehow set in the reboot process before
> exectution reach rzg2l_mipi_dsi_host_transfer(). To be honest, I don't
> know the rz-du code.
Maybe Biju can shed some light on this?
>
> [...]
>
> >
> > I do not have acces to the other panels for the moment to run the same command.
> >
> >
> >> Also, could you please check if the following diff solves your problem:
> >>
> >> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >> b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >> index 5edd45424562..62957632a96f 100644
> >> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >> @@ -1282,6 +1282,10 @@ static ssize_t
> >> rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> >> value |= SQCH0DSC0AR_FMT_SHORT;
> >> }
> >>
> >> + ret = pm_runtime_resume_and_get(dsi->dev);
> >> + if (ret)
> >> + return ret;
> >> +
> >> rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> >>
> >> /*
> >> @@ -1322,6 +1326,8 @@ static ssize_t rzg2l_mipi_dsi_host_transfer(struct
> >> mipi_dsi_host *host,
> >> ret = packet.payload_length;
> >> }
> >>
> >> + pm_runtime_put(dsi->dev);
> >> +
> >> return ret;
> >> }
> >
> > I confirm that it fixes the bug, altought I assume this is just for testing and is not the "proper" fix.
>
> To me, this, or something similar should be done anyway. Previously it
> used to work because there was no MSTOP support available.
>
> The MSTOP is now set when all of the clocks sharing it are disabled.
> With the MSTOP set, any master accessing a HW block that has MSTOP set
> will get sync abort. That wasn't the case previously, when the HW
> registers could have been accessed w/o generating such exeception.
>
> Thank you,
> Claudiu
>
--
Hugo Villeneuve
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 15:04 ` Hugo Villeneuve
@ 2026-01-09 15:57 ` Biju Das
2026-01-09 15:59 ` Hugo Villeneuve
0 siblings, 1 reply; 15+ messages in thread
From: Biju Das @ 2026-01-09 15:57 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Hugo,
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Hugo Villeneuve
> Sent: 09 January 2026 15:05
> Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
>
> Hi Biju,
>
> On Thu, 8 Jan 2026 21:21:00 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> > Hi Hugo,
> >
> > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > Sent: 08 January 2026 17:52
> > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > reboot
> > >
> > > Hi Biju,
> > >
> > > On Thu, 8 Jan 2026 16:44:37 +0000
> > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > >
> > > > Hi Hugo Villeneuve,
> > > >
> > > > > -----Original Message-----
> > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > Sent: 08 January 2026 15:53
> > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > > reboot
> > > > >
> > > > > Hi Claudiu,
> > > > >
> > > > > On Thu, 8 Jan 2026 11:12:54 +0200 Claudiu Beznea
> > > > > <claudiu.beznea@tuxon.dev> wrote:
> > > > >
> > > > > > Hi, Hugo,
> > > > > >
> > > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > > Hi,
> > > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > > >
> > > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > 6.19.0-
> > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > 6.19.0-
> > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > > [ 36.183672] Call trace:
> > > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > > [ 36.184028] Memory Limit: none
> > > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > > > >
> > > > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > > > linux-6.17. I also confirm the bug is
> > > > > present in linux-6.19-rc4.
> > > > > > >
> > > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > > >
> > > > > > > After bisecting, here is the first bad commit:
> > > > > > >
> > > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add
> > > > > > > MSTOP for
> > > > > > > RZ/G2L")
> > > > > > >
> > > > > > > Reverting this change makes the bug disappear.
> > > > > > >
> > > > > > > My limited understanding seems to indicate that the MIPI/DSI
> > > > > > > host may no longer be available/on when the panel tries to
> > > > > > > send MIPI/DSI commands in ili9881c_unprepare(), maybe
> > > > > > > because the MIPI/DSI clock has been
> > > stopped...
> > > > > > >
> > > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > > > >
> > > > > > Could you please provide the output of command:
> > > > > >
> > > > > > cat /sys/kernel/debug/mstop
> > > > > >
> > > > > > for both cases?
> > > > >
> > > > > Here it is for the panel which has the bug:
> > > > >
> > > > > ----------------------------------
> > > > > MSTOP
> > > > > clk -------------------------
> > > > > clk_name cnt cnt off val shared
> > > > > -------- ----- ----- ----- ------ ------
> > > > > gic 1 1 0xb80 0x0
> > > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > dmac_aclk 2 1 0xb80 0x0
> > > > > dmac_pclk 1 1 0xb80 0x0
> > > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > > mtu_x_mck 0 0 0xb64 0x4
> > > > > gpt_pclk 1 1 0xb64 0x0
> > > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > gpu_clk 1 1 0xb80 0x0
> > > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> dsi_vclk
> > > > > dsi_lpclk
> > > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > usb0_host 3 1 0xb6c 0x0
> > > > > usb1_host 0 0 0xb6c 0x80
> > > > > usb0_func 1 1 0xb6c 0x0
> > > > > usb_pclk 5 1 0xb6c 0x0
> > > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > i2c0 0 0 0xb68 0x400
> > > > > i2c1 0 0 0xb68 0x800
> > > > > i2c2 0 0 0xb68 0x1000
> > > > > i2c3 0 0 0xb68 0x2000
> > > > > scif0 2 1 0xb68 0x0
> > > > > scif1 0 0 0xb68 0x4
> > > > > scif2 0 0 0xb68 0x8
> > > > > scif3 0 0 0xb68 0x10
> > > > > scif4 0 0 0xb68 0x20
> > > > > sci0 0 0 0xb68 0x80
> > > > > sci1 0 0 0xb68 0x100
> > > > > rspi0 0 0 0xb64 0x4000
> > > > > rspi1 0 0 0xb64 0x8000
> > > > > rspi2 0 0 0xb68 0x1
> > > > > canfd 0 0 0xb68 0x200
> > > > > gpio 1 1 0xb70 0x0
> > > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > tsu_pclk 1 1 0xb68 0x0
> > > > > ----------------------------------
> > > > >
> > > > > I do not have acces to the other panels for the moment to run the same command.
> > > > >
> > > > >
> > > > > > Also, could you please check if the following diff solves your problem:
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > index 5edd45424562..62957632a96f 100644
> > > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > > }
> > > > > >
> > > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> > > > > >
> > > > > > /*
> > > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > > mipi_dsi_host *host,
> > > > > > ret = packet.payload_length;
> > > > > > }
> > > > > >
> > > > > > + pm_runtime_put(dsi->dev);
> > > > > > +
> > > > > > return ret;
> > > > > > }
> > > > >
> > > > > I confirm that it fixes the bug, altought I assume this is just
> > > > > for testing and is not the
> > > "proper"
> > > > > fix.
> > > >
> > > > Pre-MSTOP case during reboot, without clk it is accessing
> > > > registers)(mstop off always) it won't crash. But looks like you
> > > > may have ignored timeout error from
> > > [1].
> > >
> > > In case of a timeout error, it is not really ignored as the proper
> > > error code -ETIMEDOUT will be returned by
> > > rzg2l_mipi_dsi_host_transfer() (see log below). The hardware manual
> > > doesn't seem to properly explain how to deal with a timeout (or I could not find it). Do you have
> any suggestion on how to improve this?
> > >
> > > >
> > > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > > >
> > > > and the patch fixes crash.
> > > >
> > > > Basically, you are accessing link register after video is stopped with this panel.
> > > > Looks like it is a fix for me.
> > >
> > > Ok, like I said I am not an expert on this, but I was just assuming
> > > that there was a better way to ensure that the mipi/dsi interface
> > > was still active until the panel unprepare() function could do its
> > > work. I was looking at some other drivers mipi/dsi
> > > host_transfer() functions and did not see a similar
> > > pm_runtime_resume_and_get() scheme, hence my confusion.
> > >
> > > > Better check if there is any timeout error[1] with this patch. if
> > > > not, It is proper fix.
> > >
> > > The patch does fixes the kernel panic, but doesn't allow the panel
> > > to be properly unprepared, as I just noticed the timeout message:
> > >
> > > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> > >
> > > In my case, for a reboot, this is not a problem, but it may be a
> > > problem for systems where it can be suspended (I assume)?
> > >
> > > Thank you for your help with this.
> >
> > Can you please try implement .atomic_post_disable() symmetrical to rzg2l_mipi_dsi_atomic_pre_enable?
> >
> > Ie, move just rzg2l_mipi_dsi_stop(dsi) from
> > rzg2l_mipi_dsi_atomic_disable() to
> > rzg2l_mipi_dsi_atomic_post_disable()
> >
> > and check you can send DCS SET_DISPLAY_OFF successfully.
>
> I reverted the previous fix (pm_runtime_resume_and_get), and implemented .atomic_post_disable as you
> suggested, and this works great: the bug is no longer present and I do not see timeout errors:
>
> [ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
> [ 537.734544] systemd-shutdown[1]: Rebooting.
> [ 538.520174] rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry [ 538.547848]
> ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry [ 538.564524] rzg2l-mipi-dsi 10850000.dsi:
> rzg2l_mipi_dsi_atomic_post_disable(): entry [ 538.574016] reboot: Restarting system
Great!
Cheers,
Biju
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 15:57 ` Biju Das
@ 2026-01-09 15:59 ` Hugo Villeneuve
2026-01-09 16:03 ` Biju Das
0 siblings, 1 reply; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-09 15:59 UTC (permalink / raw)
To: Biju Das
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Biju,
On Fri, 9 Jan 2026 15:57:17 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo,
>
> > -----Original Message-----
> > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Hugo Villeneuve
> > Sent: 09 January 2026 15:05
> > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
> >
> > Hi Biju,
> >
> > On Thu, 8 Jan 2026 21:21:00 +0000
> > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > > Hi Hugo,
> > >
> > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > Sent: 08 January 2026 17:52
> > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > reboot
> > > >
> > > > Hi Biju,
> > > >
> > > > On Thu, 8 Jan 2026 16:44:37 +0000
> > > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > >
> > > > > Hi Hugo Villeneuve,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > Sent: 08 January 2026 15:53
> > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > > > reboot
> > > > > >
> > > > > > Hi Claudiu,
> > > > > >
> > > > > > On Thu, 8 Jan 2026 11:12:54 +0200 Claudiu Beznea
> > > > > > <claudiu.beznea@tuxon.dev> wrote:
> > > > > >
> > > > > > > Hi, Hugo,
> > > > > > >
> > > > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > > > Hi,
> > > > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > > > >
> > > > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > 6.19.0-
> > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > 6.19.0-
> > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > > > [ 36.183672] Call trace:
> > > > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > > > [ 36.184028] Memory Limit: none
> > > > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > > > > >
> > > > > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > > > > linux-6.17. I also confirm the bug is
> > > > > > present in linux-6.19-rc4.
> > > > > > > >
> > > > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > > > >
> > > > > > > > After bisecting, here is the first bad commit:
> > > > > > > >
> > > > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add
> > > > > > > > MSTOP for
> > > > > > > > RZ/G2L")
> > > > > > > >
> > > > > > > > Reverting this change makes the bug disappear.
> > > > > > > >
> > > > > > > > My limited understanding seems to indicate that the MIPI/DSI
> > > > > > > > host may no longer be available/on when the panel tries to
> > > > > > > > send MIPI/DSI commands in ili9881c_unprepare(), maybe
> > > > > > > > because the MIPI/DSI clock has been
> > > > stopped...
> > > > > > > >
> > > > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > > > > >
> > > > > > > Could you please provide the output of command:
> > > > > > >
> > > > > > > cat /sys/kernel/debug/mstop
> > > > > > >
> > > > > > > for both cases?
> > > > > >
> > > > > > Here it is for the panel which has the bug:
> > > > > >
> > > > > > ----------------------------------
> > > > > > MSTOP
> > > > > > clk -------------------------
> > > > > > clk_name cnt cnt off val shared
> > > > > > -------- ----- ----- ----- ------ ------
> > > > > > gic 1 1 0xb80 0x0
> > > > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > dmac_aclk 2 1 0xb80 0x0
> > > > > > dmac_pclk 1 1 0xb80 0x0
> > > > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > > > mtu_x_mck 0 0 0xb64 0x4
> > > > > > gpt_pclk 1 1 0xb64 0x0
> > > > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs sdhi0_aclk
> > > > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs sdhi1_aclk
> > > > > > gpu_clk 1 1 0xb80 0x0
> > > > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > dsi_vclk
> > > > > > dsi_lpclk
> > > > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > usb0_host 3 1 0xb6c 0x0
> > > > > > usb1_host 0 0 0xb6c 0x80
> > > > > > usb0_func 1 1 0xb6c 0x0
> > > > > > usb_pclk 5 1 0xb6c 0x0
> > > > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > i2c0 0 0 0xb68 0x400
> > > > > > i2c1 0 0 0xb68 0x800
> > > > > > i2c2 0 0 0xb68 0x1000
> > > > > > i2c3 0 0 0xb68 0x2000
> > > > > > scif0 2 1 0xb68 0x0
> > > > > > scif1 0 0 0xb68 0x4
> > > > > > scif2 0 0 0xb68 0x8
> > > > > > scif3 0 0 0xb68 0x10
> > > > > > scif4 0 0 0xb68 0x20
> > > > > > sci0 0 0 0xb68 0x80
> > > > > > sci1 0 0 0xb68 0x100
> > > > > > rspi0 0 0 0xb64 0x4000
> > > > > > rspi1 0 0 0xb64 0x8000
> > > > > > rspi2 0 0 0xb68 0x1
> > > > > > canfd 0 0 0xb68 0x200
> > > > > > gpio 1 1 0xb70 0x0
> > > > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > tsu_pclk 1 1 0xb68 0x0
> > > > > > ----------------------------------
> > > > > >
> > > > > > I do not have acces to the other panels for the moment to run the same command.
> > > > > >
> > > > > >
> > > > > > > Also, could you please check if the following diff solves your problem:
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > index 5edd45424562..62957632a96f 100644
> > > > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > > > }
> > > > > > >
> > > > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR, value);
> > > > > > >
> > > > > > > /*
> > > > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > > > mipi_dsi_host *host,
> > > > > > > ret = packet.payload_length;
> > > > > > > }
> > > > > > >
> > > > > > > + pm_runtime_put(dsi->dev);
> > > > > > > +
> > > > > > > return ret;
> > > > > > > }
> > > > > >
> > > > > > I confirm that it fixes the bug, altought I assume this is just
> > > > > > for testing and is not the
> > > > "proper"
> > > > > > fix.
> > > > >
> > > > > Pre-MSTOP case during reboot, without clk it is accessing
> > > > > registers)(mstop off always) it won't crash. But looks like you
> > > > > may have ignored timeout error from
> > > > [1].
> > > >
> > > > In case of a timeout error, it is not really ignored as the proper
> > > > error code -ETIMEDOUT will be returned by
> > > > rzg2l_mipi_dsi_host_transfer() (see log below). The hardware manual
> > > > doesn't seem to properly explain how to deal with a timeout (or I could not find it). Do you have
> > any suggestion on how to improve this?
> > > >
> > > > >
> > > > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > > > >
> > > > > and the patch fixes crash.
> > > > >
> > > > > Basically, you are accessing link register after video is stopped with this panel.
> > > > > Looks like it is a fix for me.
> > > >
> > > > Ok, like I said I am not an expert on this, but I was just assuming
> > > > that there was a better way to ensure that the mipi/dsi interface
> > > > was still active until the panel unprepare() function could do its
> > > > work. I was looking at some other drivers mipi/dsi
> > > > host_transfer() functions and did not see a similar
> > > > pm_runtime_resume_and_get() scheme, hence my confusion.
> > > >
> > > > > Better check if there is any timeout error[1] with this patch. if
> > > > > not, It is proper fix.
> > > >
> > > > The patch does fixes the kernel panic, but doesn't allow the panel
> > > > to be properly unprepared, as I just noticed the timeout message:
> > > >
> > > > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> > > >
> > > > In my case, for a reboot, this is not a problem, but it may be a
> > > > problem for systems where it can be suspended (I assume)?
> > > >
> > > > Thank you for your help with this.
> > >
> > > Can you please try implement .atomic_post_disable() symmetrical to rzg2l_mipi_dsi_atomic_pre_enable?
> > >
> > > Ie, move just rzg2l_mipi_dsi_stop(dsi) from
> > > rzg2l_mipi_dsi_atomic_disable() to
> > > rzg2l_mipi_dsi_atomic_post_disable()
> > >
> > > and check you can send DCS SET_DISPLAY_OFF successfully.
> >
> > I reverted the previous fix (pm_runtime_resume_and_get), and implemented .atomic_post_disable as you
> > suggested, and this works great: the bug is no longer present and I do not see timeout errors:
> >
> > [ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
> > [ 537.734544] systemd-shutdown[1]: Rebooting.
> > [ 538.520174] rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry [ 538.547848]
> > ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry [ 538.564524] rzg2l-mipi-dsi 10850000.dsi:
> > rzg2l_mipi_dsi_atomic_post_disable(): entry [ 538.574016] reboot: Restarting system
>
> Great!
Will you send a patch for this?
Thank you,
Hugo.
--
Hugo Villeneuve
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 15:59 ` Hugo Villeneuve
@ 2026-01-09 16:03 ` Biju Das
2026-01-09 16:06 ` Hugo Villeneuve
0 siblings, 1 reply; 15+ messages in thread
From: Biju Das @ 2026-01-09 16:03 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Hugo,
> -----Original Message-----
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 09 January 2026 16:00
> Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
>
> Hi Biju,
>
> On Fri, 9 Jan 2026 15:57:17 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> > Hi Hugo,
> >
> > > -----Original Message-----
> > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf
> > > Of Hugo Villeneuve
> > > Sent: 09 January 2026 15:05
> > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > reboot
> > >
> > > Hi Biju,
> > >
> > > On Thu, 8 Jan 2026 21:21:00 +0000
> > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > >
> > > > Hi Hugo,
> > > >
> > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > Sent: 08 January 2026 17:52
> > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > > reboot
> > > > >
> > > > > Hi Biju,
> > > > >
> > > > > On Thu, 8 Jan 2026 16:44:37 +0000 Biju Das
> > > > > <biju.das.jz@bp.renesas.com> wrote:
> > > > >
> > > > > > Hi Hugo Villeneuve,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > > Sent: 08 January 2026 15:53
> > > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic
> > > > > > > on reboot
> > > > > > >
> > > > > > > Hi Claudiu,
> > > > > > >
> > > > > > > On Thu, 8 Jan 2026 11:12:54 +0200 Claudiu Beznea
> > > > > > > <claudiu.beznea@tuxon.dev> wrote:
> > > > > > >
> > > > > > > > Hi, Hugo,
> > > > > > > >
> > > > > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > > > > Hi,
> > > > > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > > > > >
> > > > > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > 6.19.0-
> > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > 6.19.0-
> > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > > > > [ 36.183672] Call trace:
> > > > > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > > > > [ 36.184028] Memory Limit: none
> > > > > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > > > > > >
> > > > > > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > > > > > linux-6.17. I also confirm the bug is
> > > > > > > present in linux-6.19-rc4.
> > > > > > > > >
> > > > > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > > > > >
> > > > > > > > > After bisecting, here is the first bad commit:
> > > > > > > > >
> > > > > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add
> > > > > > > > > MSTOP for
> > > > > > > > > RZ/G2L")
> > > > > > > > >
> > > > > > > > > Reverting this change makes the bug disappear.
> > > > > > > > >
> > > > > > > > > My limited understanding seems to indicate that the
> > > > > > > > > MIPI/DSI host may no longer be available/on when the
> > > > > > > > > panel tries to send MIPI/DSI commands in
> > > > > > > > > ili9881c_unprepare(), maybe because the MIPI/DSI clock
> > > > > > > > > has been
> > > > > stopped...
> > > > > > > > >
> > > > > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > > > > > >
> > > > > > > > Could you please provide the output of command:
> > > > > > > >
> > > > > > > > cat /sys/kernel/debug/mstop
> > > > > > > >
> > > > > > > > for both cases?
> > > > > > >
> > > > > > > Here it is for the panel which has the bug:
> > > > > > >
> > > > > > > ----------------------------------
> > > > > > > MSTOP
> > > > > > > clk -------------------------
> > > > > > > clk_name cnt cnt off val shared
> > > > > > > -------- ----- ----- ----- ------ ------
> > > > > > > gic 1 1 0xb80 0x0
> > > > > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > dmac_aclk 2 1 0xb80 0x0
> > > > > > > dmac_pclk 1 1 0xb80 0x0
> > > > > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > > > > mtu_x_mck 0 0 0xb64 0x4
> > > > > > > gpt_pclk 1 1 0xb64 0x0
> > > > > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> sdhi0_aclk
> > > > > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> sdhi0_aclk
> > > > > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> sdhi0_aclk
> > > > > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> sdhi0_aclk
> > > > > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> sdhi1_aclk
> > > > > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> sdhi1_aclk
> > > > > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> sdhi1_aclk
> > > > > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> sdhi1_aclk
> > > > > > > gpu_clk 1 1 0xb80 0x0
> > > > > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > dsi_vclk
> > > > > > > dsi_lpclk
> > > > > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > usb0_host 3 1 0xb6c 0x0
> > > > > > > usb1_host 0 0 0xb6c 0x80
> > > > > > > usb0_func 1 1 0xb6c 0x0
> > > > > > > usb_pclk 5 1 0xb6c 0x0
> > > > > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > i2c0 0 0 0xb68 0x400
> > > > > > > i2c1 0 0 0xb68 0x800
> > > > > > > i2c2 0 0 0xb68 0x1000
> > > > > > > i2c3 0 0 0xb68 0x2000
> > > > > > > scif0 2 1 0xb68 0x0
> > > > > > > scif1 0 0 0xb68 0x4
> > > > > > > scif2 0 0 0xb68 0x8
> > > > > > > scif3 0 0 0xb68 0x10
> > > > > > > scif4 0 0 0xb68 0x20
> > > > > > > sci0 0 0 0xb68 0x80
> > > > > > > sci1 0 0 0xb68 0x100
> > > > > > > rspi0 0 0 0xb64 0x4000
> > > > > > > rspi1 0 0 0xb64 0x8000
> > > > > > > rspi2 0 0 0xb68 0x1
> > > > > > > canfd 0 0 0xb68 0x200
> > > > > > > gpio 1 1 0xb70 0x0
> > > > > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > tsu_pclk 1 1 0xb68 0x0
> > > > > > > ----------------------------------
> > > > > > >
> > > > > > > I do not have acces to the other panels for the moment to run the same command.
> > > > > > >
> > > > > > >
> > > > > > > > Also, could you please check if the following diff solves your problem:
> > > > > > > >
> > > > > > > > diff --git
> > > > > > > > a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > index 5edd45424562..62957632a96f 100644
> > > > > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > > > > }
> > > > > > > >
> > > > > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > > > > + if (ret)
> > > > > > > > + return ret;
> > > > > > > > +
> > > > > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR,
> > > > > > > > value);
> > > > > > > >
> > > > > > > > /*
> > > > > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > > > > mipi_dsi_host *host,
> > > > > > > > ret = packet.payload_length;
> > > > > > > > }
> > > > > > > >
> > > > > > > > + pm_runtime_put(dsi->dev);
> > > > > > > > +
> > > > > > > > return ret;
> > > > > > > > }
> > > > > > >
> > > > > > > I confirm that it fixes the bug, altought I assume this is
> > > > > > > just for testing and is not the
> > > > > "proper"
> > > > > > > fix.
> > > > > >
> > > > > > Pre-MSTOP case during reboot, without clk it is accessing
> > > > > > registers)(mstop off always) it won't crash. But looks like
> > > > > > you may have ignored timeout error from
> > > > > [1].
> > > > >
> > > > > In case of a timeout error, it is not really ignored as the
> > > > > proper error code -ETIMEDOUT will be returned by
> > > > > rzg2l_mipi_dsi_host_transfer() (see log below). The hardware
> > > > > manual doesn't seem to properly explain how to deal with a
> > > > > timeout (or I could not find it). Do you have
> > > any suggestion on how to improve this?
> > > > >
> > > > > >
> > > > > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > > > > >
> > > > > > and the patch fixes crash.
> > > > > >
> > > > > > Basically, you are accessing link register after video is stopped with this panel.
> > > > > > Looks like it is a fix for me.
> > > > >
> > > > > Ok, like I said I am not an expert on this, but I was just
> > > > > assuming that there was a better way to ensure that the mipi/dsi
> > > > > interface was still active until the panel unprepare() function
> > > > > could do its work. I was looking at some other drivers mipi/dsi
> > > > > host_transfer() functions and did not see a similar
> > > > > pm_runtime_resume_and_get() scheme, hence my confusion.
> > > > >
> > > > > > Better check if there is any timeout error[1] with this patch.
> > > > > > if not, It is proper fix.
> > > > >
> > > > > The patch does fixes the kernel panic, but doesn't allow the
> > > > > panel to be properly unprepared, as I just noticed the timeout message:
> > > > >
> > > > > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> > > > >
> > > > > In my case, for a reboot, this is not a problem, but it may be a
> > > > > problem for systems where it can be suspended (I assume)?
> > > > >
> > > > > Thank you for your help with this.
> > > >
> > > > Can you please try implement .atomic_post_disable() symmetrical to
> rzg2l_mipi_dsi_atomic_pre_enable?
> > > >
> > > > Ie, move just rzg2l_mipi_dsi_stop(dsi) from
> > > > rzg2l_mipi_dsi_atomic_disable() to
> > > > rzg2l_mipi_dsi_atomic_post_disable()
> > > >
> > > > and check you can send DCS SET_DISPLAY_OFF successfully.
> > >
> > > I reverted the previous fix (pm_runtime_resume_and_get), and
> > > implemented .atomic_post_disable as you suggested, and this works great: the bug is no longer
> present and I do not see timeout errors:
> > >
> > > [ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
> > > [ 537.734544] systemd-shutdown[1]: Rebooting.
> > > [ 538.520174] rzg2l-mipi-dsi 10850000.dsi:
> > > rzg2l_mipi_dsi_atomic_disable(): entry [ 538.547848] ili9881c-dsi 10850000.dsi.0:
> ili9881c_unprepare(): entry [ 538.564524] rzg2l-mipi-dsi 10850000.dsi:
> > > rzg2l_mipi_dsi_atomic_post_disable(): entry [ 538.574016] reboot:
> > > Restarting system
> >
> > Great!
>
> Will you send a patch for this?
Please feel free to send the patch, as you have the hardware to test it.
I will add my Tb tag after testing your patch on my bridge setup.
Cheers,
Biju
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 16:03 ` Biju Das
@ 2026-01-09 16:06 ` Hugo Villeneuve
2026-01-09 16:14 ` Biju Das
0 siblings, 1 reply; 15+ messages in thread
From: Hugo Villeneuve @ 2026-01-09 16:06 UTC (permalink / raw)
To: Biju Das
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Biju,
On Fri, 9 Jan 2026 16:03:29 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo,
>
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 09 January 2026 16:00
> > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
> >
> > Hi Biju,
> >
> > On Fri, 9 Jan 2026 15:57:17 +0000
> > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > > Hi Hugo,
> > >
> > > > -----Original Message-----
> > > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf
> > > > Of Hugo Villeneuve
> > > > Sent: 09 January 2026 15:05
> > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > reboot
> > > >
> > > > Hi Biju,
> > > >
> > > > On Thu, 8 Jan 2026 21:21:00 +0000
> > > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > >
> > > > > Hi Hugo,
> > > > >
> > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > Sent: 08 January 2026 17:52
> > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > > > reboot
> > > > > >
> > > > > > Hi Biju,
> > > > > >
> > > > > > On Thu, 8 Jan 2026 16:44:37 +0000 Biju Das
> > > > > > <biju.das.jz@bp.renesas.com> wrote:
> > > > > >
> > > > > > > Hi Hugo Villeneuve,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > > > Sent: 08 January 2026 15:53
> > > > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic
> > > > > > > > on reboot
> > > > > > > >
> > > > > > > > Hi Claudiu,
> > > > > > > >
> > > > > > > > On Thu, 8 Jan 2026 11:12:54 +0200 Claudiu Beznea
> > > > > > > > <claudiu.beznea@tuxon.dev> wrote:
> > > > > > > >
> > > > > > > > > Hi, Hugo,
> > > > > > > > >
> > > > > > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > > > > > >
> > > > > > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > > 6.19.0-
> > > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > > 6.19.0-
> > > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > > > > > [ 36.183672] Call trace:
> > > > > > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > > > > > [ 36.184028] Memory Limit: none
> > > > > > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> > > > > > > > > >
> > > > > > > > > > The problem is present since linux-6.18-rc1, but not in
> > > > > > > > > > linux-6.17. I also confirm the bug is
> > > > > > > > present in linux-6.19-rc4.
> > > > > > > > > >
> > > > > > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > > > > > >
> > > > > > > > > > After bisecting, here is the first bad commit:
> > > > > > > > > >
> > > > > > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044: Add
> > > > > > > > > > MSTOP for
> > > > > > > > > > RZ/G2L")
> > > > > > > > > >
> > > > > > > > > > Reverting this change makes the bug disappear.
> > > > > > > > > >
> > > > > > > > > > My limited understanding seems to indicate that the
> > > > > > > > > > MIPI/DSI host may no longer be available/on when the
> > > > > > > > > > panel tries to send MIPI/DSI commands in
> > > > > > > > > > ili9881c_unprepare(), maybe because the MIPI/DSI clock
> > > > > > > > > > has been
> > > > > > stopped...
> > > > > > > > > >
> > > > > > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the bug.
> > > > > > > > >
> > > > > > > > > Could you please provide the output of command:
> > > > > > > > >
> > > > > > > > > cat /sys/kernel/debug/mstop
> > > > > > > > >
> > > > > > > > > for both cases?
> > > > > > > >
> > > > > > > > Here it is for the panel which has the bug:
> > > > > > > >
> > > > > > > > ----------------------------------
> > > > > > > > MSTOP
> > > > > > > > clk -------------------------
> > > > > > > > clk_name cnt cnt off val shared
> > > > > > > > -------- ----- ----- ----- ------ ------
> > > > > > > > gic 1 1 0xb80 0x0
> > > > > > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > > dmac_aclk 2 1 0xb80 0x0
> > > > > > > > dmac_pclk 1 1 0xb80 0x0
> > > > > > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > > > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > > > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > > > > > mtu_x_mck 0 0 0xb64 0x4
> > > > > > > > gpt_pclk 1 1 0xb64 0x0
> > > > > > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > > > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > > > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > > > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > > > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > sdhi0_aclk
> > > > > > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > sdhi0_aclk
> > > > > > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > sdhi0_aclk
> > > > > > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > sdhi0_aclk
> > > > > > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > sdhi1_aclk
> > > > > > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > sdhi1_aclk
> > > > > > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > sdhi1_aclk
> > > > > > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > sdhi1_aclk
> > > > > > > > gpu_clk 1 1 0xb80 0x0
> > > > > > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk dsi_pclk
> > > > dsi_vclk
> > > > > > > > dsi_lpclk
> > > > > > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > > > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > > usb0_host 3 1 0xb6c 0x0
> > > > > > > > usb1_host 0 0 0xb6c 0x80
> > > > > > > > usb0_func 1 1 0xb6c 0x0
> > > > > > > > usb_pclk 5 1 0xb6c 0x0
> > > > > > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > > i2c0 0 0 0xb68 0x400
> > > > > > > > i2c1 0 0 0xb68 0x800
> > > > > > > > i2c2 0 0 0xb68 0x1000
> > > > > > > > i2c3 0 0 0xb68 0x2000
> > > > > > > > scif0 2 1 0xb68 0x0
> > > > > > > > scif1 0 0 0xb68 0x4
> > > > > > > > scif2 0 0 0xb68 0x8
> > > > > > > > scif3 0 0 0xb68 0x10
> > > > > > > > scif4 0 0 0xb68 0x20
> > > > > > > > sci0 0 0 0xb68 0x80
> > > > > > > > sci1 0 0 0xb68 0x100
> > > > > > > > rspi0 0 0 0xb64 0x4000
> > > > > > > > rspi1 0 0 0xb64 0x8000
> > > > > > > > rspi2 0 0 0xb68 0x1
> > > > > > > > canfd 0 0 0xb68 0x200
> > > > > > > > gpio 1 1 0xb70 0x0
> > > > > > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > > tsu_pclk 1 1 0xb68 0x0
> > > > > > > > ----------------------------------
> > > > > > > >
> > > > > > > > I do not have acces to the other panels for the moment to run the same command.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Also, could you please check if the following diff solves your problem:
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > index 5edd45424562..62957632a96f 100644
> > > > > > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > > > > > + if (ret)
> > > > > > > > > + return ret;
> > > > > > > > > +
> > > > > > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR,
> > > > > > > > > value);
> > > > > > > > >
> > > > > > > > > /*
> > > > > > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > > > > > mipi_dsi_host *host,
> > > > > > > > > ret = packet.payload_length;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + pm_runtime_put(dsi->dev);
> > > > > > > > > +
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > >
> > > > > > > > I confirm that it fixes the bug, altought I assume this is
> > > > > > > > just for testing and is not the
> > > > > > "proper"
> > > > > > > > fix.
> > > > > > >
> > > > > > > Pre-MSTOP case during reboot, without clk it is accessing
> > > > > > > registers)(mstop off always) it won't crash. But looks like
> > > > > > > you may have ignored timeout error from
> > > > > > [1].
> > > > > >
> > > > > > In case of a timeout error, it is not really ignored as the
> > > > > > proper error code -ETIMEDOUT will be returned by
> > > > > > rzg2l_mipi_dsi_host_transfer() (see log below). The hardware
> > > > > > manual doesn't seem to properly explain how to deal with a
> > > > > > timeout (or I could not find it). Do you have
> > > > any suggestion on how to improve this?
> > > > > >
> > > > > > >
> > > > > > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > > > > > >
> > > > > > > and the patch fixes crash.
> > > > > > >
> > > > > > > Basically, you are accessing link register after video is stopped with this panel.
> > > > > > > Looks like it is a fix for me.
> > > > > >
> > > > > > Ok, like I said I am not an expert on this, but I was just
> > > > > > assuming that there was a better way to ensure that the mipi/dsi
> > > > > > interface was still active until the panel unprepare() function
> > > > > > could do its work. I was looking at some other drivers mipi/dsi
> > > > > > host_transfer() functions and did not see a similar
> > > > > > pm_runtime_resume_and_get() scheme, hence my confusion.
> > > > > >
> > > > > > > Better check if there is any timeout error[1] with this patch.
> > > > > > > if not, It is proper fix.
> > > > > >
> > > > > > The patch does fixes the kernel panic, but doesn't allow the
> > > > > > panel to be properly unprepared, as I just noticed the timeout message:
> > > > > >
> > > > > > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> > > > > >
> > > > > > In my case, for a reboot, this is not a problem, but it may be a
> > > > > > problem for systems where it can be suspended (I assume)?
> > > > > >
> > > > > > Thank you for your help with this.
> > > > >
> > > > > Can you please try implement .atomic_post_disable() symmetrical to
> > rzg2l_mipi_dsi_atomic_pre_enable?
> > > > >
> > > > > Ie, move just rzg2l_mipi_dsi_stop(dsi) from
> > > > > rzg2l_mipi_dsi_atomic_disable() to
> > > > > rzg2l_mipi_dsi_atomic_post_disable()
> > > > >
> > > > > and check you can send DCS SET_DISPLAY_OFF successfully.
> > > >
> > > > I reverted the previous fix (pm_runtime_resume_and_get), and
> > > > implemented .atomic_post_disable as you suggested, and this works great: the bug is no longer
> > present and I do not see timeout errors:
> > > >
> > > > [ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
> > > > [ 537.734544] systemd-shutdown[1]: Rebooting.
> > > > [ 538.520174] rzg2l-mipi-dsi 10850000.dsi:
> > > > rzg2l_mipi_dsi_atomic_disable(): entry [ 538.547848] ili9881c-dsi 10850000.dsi.0:
> > ili9881c_unprepare(): entry [ 538.564524] rzg2l-mipi-dsi 10850000.dsi:
> > > > rzg2l_mipi_dsi_atomic_post_disable(): entry [ 538.574016] reboot:
> > > > Restarting system
> > >
> > > Great!
> >
> > Will you send a patch for this?
>
> Please feel free to send the patch, as you have the hardware to test it.
>
> I will add my Tb tag after testing your patch on my bridge setup.
Ok, will do.
Can you also check on what Claudiu mentioned about MSTOP values for
this driver?
Thank you,
Hugo.
--
Hugo Villeneuve
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
2026-01-09 16:06 ` Hugo Villeneuve
@ 2026-01-09 16:14 ` Biju Das
0 siblings, 0 replies; 15+ messages in thread
From: Biju Das @ 2026-01-09 16:14 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Claudiu.Beznea, dri-devel, linux-renesas-soc, linux-clk,
linux-kernel, Claudiu Beznea, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Chris Brandt
Hi Hugo,
> -----Original Message-----
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 09 January 2026 16:06
> Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot
>
> Hi Biju,
>
> On Fri, 9 Jan 2026 16:03:29 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> > Hi Hugo,
> >
> > > -----Original Message-----
> > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > Sent: 09 January 2026 16:00
> > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > reboot
> > >
> > > Hi Biju,
> > >
> > > On Fri, 9 Jan 2026 15:57:17 +0000
> > > Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > >
> > > > Hi Hugo,
> > > >
> > > > > -----Original Message-----
> > > > > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On
> > > > > Behalf Of Hugo Villeneuve
> > > > > Sent: 09 January 2026 15:05
> > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic on
> > > > > reboot
> > > > >
> > > > > Hi Biju,
> > > > >
> > > > > On Thu, 8 Jan 2026 21:21:00 +0000 Biju Das
> > > > > <biju.das.jz@bp.renesas.com> wrote:
> > > > >
> > > > > > Hi Hugo,
> > > > > >
> > > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > > Sent: 08 January 2026 17:52
> > > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel panic
> > > > > > > on reboot
> > > > > > >
> > > > > > > Hi Biju,
> > > > > > >
> > > > > > > On Thu, 8 Jan 2026 16:44:37 +0000 Biju Das
> > > > > > > <biju.das.jz@bp.renesas.com> wrote:
> > > > > > >
> > > > > > > > Hi Hugo Villeneuve,
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > > > > > > > Sent: 08 January 2026 15:53
> > > > > > > > > Subject: Re: [BUG] drm/panel: ilitek-ili9881c: kernel
> > > > > > > > > panic on reboot
> > > > > > > > >
> > > > > > > > > Hi Claudiu,
> > > > > > > > >
> > > > > > > > > On Thu, 8 Jan 2026 11:12:54 +0200 Claudiu Beznea
> > > > > > > > > <claudiu.beznea@tuxon.dev> wrote:
> > > > > > > > >
> > > > > > > > > > Hi, Hugo,
> > > > > > > > > >
> > > > > > > > > > On 1/7/26 23:48, Hugo Villeneuve wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > > when issuing a reboot command, I encounter the following kernel panic:
> > > > > > > > > > >
> > > > > > > > > > > [ 36.183478] SError Interrupt on CPU1, code 0x00000000be000011 -- SError
> > > > > > > > > > > [ 36.183492] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > > > 6.19.0-
> > > > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > > > [ 36.183504] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > > > [ 36.183507] Hardware name: Gecko ECO2 nxtpad (DT)
> > > > > > > > > > > [ 36.183512] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > > > > [ 36.183519] pc : rzg2l_mipi_dsi_host_transfer+0x114/0x458
> > > > > > > > > > > [ 36.183538] lr : rzg2l_mipi_dsi_host_transfer+0x98/0x458
> > > > > > > > > > > [ 36.183547] sp : ffff8000813db860
> > > > > > > > > > > [ 36.183550] x29: ffff8000813db890 x28: ffff800080c602c0 x27: ffff000009dd7450
> > > > > > > > > > > [ 36.183563] x26: ffff800080c5fcc0 x25: ffff000009dd7450 x24: ffff800080e1f7a8
> > > > > > > > > > > [ 36.183573] x23: ffff000009dd7400 x22: 0000000000000000 x21: ffff000009dd7430
> > > > > > > > > > > [ 36.183582] x20: ffff8000813db8e8 x19: 0000000002050028 x18: 00000000ffffffff
> > > > > > > > > > > [ 36.183592] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000813db220
> > > > > > > > > > > [ 36.183602] x14: 0000000000000000 x13: ffff800081255bc0 x12: 00000000000009a2
> > > > > > > > > > > [ 36.183611] x11: 0000000000000336 x10: ffff8000812b28d0 x9 : ffff800081255bc0
> > > > > > > > > > > [ 36.183621] x8 : ffff800081399000 x7 : ffff00000a042600 x6 : 0000000000000000
> > > > > > > > > > > [ 36.183631] x5 : 0000000000000805 x4 : 0000000002000000 x3 : 0000000000000028
> > > > > > > > > > > [ 36.183640] x2 : 0000000049627000 x1 : ffff800080c60b40 x0 : ffff800081780000
> > > > > > > > > > > [ 36.183652] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > > > > > > > > > [ 36.183657] CPU: 1 UID: 0 PID: 1 Comm: systemd-shutdow Tainted: G M
> > > > > > > 6.19.0-
> > > > > > > > > rc4-arm64-renesas-00019-g067a81578add #62 NONE
> > > > > > > > > > > [ 36.183665] Tainted: [M]=MACHINE_CHECK
> > > > > > > > > > > [ 36.183668] Hardware name: devboard1 (DT)
> > > > > > > > > > > [ 36.183672] Call trace:
> > > > > > > > > > > [ 36.183675] show_stack+0x18/0x24 (C)
> > > > > > > > > > > [ 36.183692] dump_stack_lvl+0x34/0x8c
> > > > > > > > > > > [ 36.183702] dump_stack+0x18/0x24
> > > > > > > > > > > [ 36.183708] vpanic+0x314/0x35c
> > > > > > > > > > > [ 36.183716] nmi_panic+0x0/0x64
> > > > > > > > > > > [ 36.183722] add_taint+0x0/0xbc
> > > > > > > > > > > [ 36.183728] arm64_serror_panic+0x70/0x80
> > > > > > > > > > > [ 36.183735] do_serror+0x28/0x68
> > > > > > > > > > > [ 36.183742] el1h_64_error_handler+0x34/0x50
> > > > > > > > > > > [ 36.183751] el1h_64_error+0x6c/0x70
> > > > > > > > > > > [ 36.183758] rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
> > > > > > > > > > > [ 36.183770] mipi_dsi_device_transfer+0x44/0x58
> > > > > > > > > > > [ 36.183781] mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
> > > > > > > > > > > [ 36.183792] ili9881c_unprepare+0x38/0x88
> > > > > > > > > > > [ 36.183802] drm_panel_unprepare+0xbc/0x108
> > > > > > > > > > > [ 36.183814] panel_bridge_atomic_post_disable+0x50/0x60
> > > > > > > > > > > [ 36.183823] drm_atomic_bridge_call_post_disable+0x24/0x4c
> > > > > > > > > > > [ 36.183835] drm_atomic_bridge_chain_post_disable+0xa8/0x100
> > > > > > > > > > > [ 36.183845] drm_atomic_helper_commit_modeset_disables+0x2fc/0x5f8
> > > > > > > > > > > [ 36.183856] drm_atomic_helper_commit_tail_rpm+0x24/0x7c
> > > > > > > > > > > [ 36.183865] commit_tail+0xa4/0x18c
> > > > > > > > > > > [ 36.183874] drm_atomic_helper_commit+0x17c/0x194
> > > > > > > > > > > [ 36.183884] drm_atomic_commit+0x8c/0xcc
> > > > > > > > > > > [ 36.183892] drm_atomic_helper_disable_all+0x200/0x210
> > > > > > > > > > > [ 36.183901] drm_atomic_helper_shutdown+0xa8/0x150
> > > > > > > > > > > [ 36.183911] rzg2l_du_shutdown+0x18/0x24
> > > > > > > > > > > [ 36.183920] platform_shutdown+0x24/0x34
> > > > > > > > > > > [ 36.183931] device_shutdown+0x128/0x284
> > > > > > > > > > > [ 36.183938] kernel_restart+0x44/0xa4
> > > > > > > > > > > [ 36.183950] __do_sys_reboot+0x178/0x270
> > > > > > > > > > > [ 36.183959] __arm64_sys_reboot+0x24/0x30
> > > > > > > > > > > [ 36.183968] invoke_syscall.constprop.0+0x50/0xe4
> > > > > > > > > > > [ 36.183979] do_el0_svc+0x40/0xc0
> > > > > > > > > > > [ 36.183988] el0_svc+0x3c/0x164
> > > > > > > > > > > [ 36.183995] el0t_64_sync_handler+0xa0/0xe4
> > > > > > > > > > > [ 36.184002] el0t_64_sync+0x198/0x19c
> > > > > > > > > > > [ 36.184020] Kernel Offset: disabled
> > > > > > > > > > > [ 36.184022] CPU features: 0x200000,00020001,4000c501,0400720b
> > > > > > > > > > > [ 36.184028] Memory Limit: none
> > > > > > > > > > > [ 36.495305] ---[ end Kernel panic - not syncing: Asynchronous SError
> Interrupt ]---
> > > > > > > > > > >
> > > > > > > > > > > The problem is present since linux-6.18-rc1, but not
> > > > > > > > > > > in linux-6.17. I also confirm the bug is
> > > > > > > > > present in linux-6.19-rc4.
> > > > > > > > > > >
> > > > > > > > > > > The bug seems to be happening in rzg2l_mipi_dsi_host_transfer().
> > > > > > > > > > >
> > > > > > > > > > > After bisecting, here is the first bad commit:
> > > > > > > > > > >
> > > > > > > > > > > commit 56de5e305d4b ("clk: renesas: r9a07g044:
> > > > > > > > > > > Add MSTOP for
> > > > > > > > > > > RZ/G2L")
> > > > > > > > > > >
> > > > > > > > > > > Reverting this change makes the bug disappear.
> > > > > > > > > > >
> > > > > > > > > > > My limited understanding seems to indicate that the
> > > > > > > > > > > MIPI/DSI host may no longer be available/on when the
> > > > > > > > > > > panel tries to send MIPI/DSI commands in
> > > > > > > > > > > ili9881c_unprepare(), maybe because the MIPI/DSI
> > > > > > > > > > > clock has been
> > > > > > > stopped...
> > > > > > > > > > >
> > > > > > > > > > > The exact same board with two other panels (jd9365da and st7703) doesn't have the
> bug.
> > > > > > > > > >
> > > > > > > > > > Could you please provide the output of command:
> > > > > > > > > >
> > > > > > > > > > cat /sys/kernel/debug/mstop
> > > > > > > > > >
> > > > > > > > > > for both cases?
> > > > > > > > >
> > > > > > > > > Here it is for the panel which has the bug:
> > > > > > > > >
> > > > > > > > > ----------------------------------
> > > > > > > > > MSTOP
> > > > > > > > > clk -------------------------
> > > > > > > > > clk_name cnt cnt off val shared
> > > > > > > > > -------- ----- ----- ----- ------ ------
> > > > > > > > > gic 1 1 0xb80 0x0
> > > > > > > > > ia55_clk 2 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > > > ia55_pclk 1 2 0xb70 0x0 ia55_pclk ia55_clk
> > > > > > > > > dmac_aclk 2 1 0xb80 0x0
> > > > > > > > > dmac_pclk 1 1 0xb80 0x0
> > > > > > > > > ostm0_pclk 0 0 0xb7c 0x10
> > > > > > > > > ostm1_pclk 1 1 0xb7c 0x0
> > > > > > > > > ostm2_pclk 1 1 0xb7c 0x0
> > > > > > > > > mtu_x_mck 0 0 0xb64 0x4
> > > > > > > > > gpt_pclk 1 1 0xb64 0x0
> > > > > > > > > poeg_a_clkp 0 0 0xb64 0x20
> > > > > > > > > poeg_b_clkp 0 0 0xb64 0x40
> > > > > > > > > poeg_c_clkp 0 0 0xb64 0x80
> > > > > > > > > poeg_d_clkp 0 0 0xb64 0x100
> > > > > > > > > wdt0_pclk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > > > wdt0_clk 1 2 0xb7c 0x0 wdt0_pclk wdt0_clk
> > > > > > > > > wdt1_pclk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > > > wdt1_clk 0 0 0xb7c 0x8 wdt1_pclk wdt1_clk
> > > > > > > > > spi_clk2 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > > > spi_clk 0 0 0xb64 0x2 spi_clk2 spi_clk
> > > > > > > > > sdhi0_imclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > > sdhi0_aclk
> > > > > > > > > sdhi0_imclk2 2 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > > sdhi0_aclk
> > > > > > > > > sdhi0_clk_hs 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > > sdhi0_aclk
> > > > > > > > > sdhi0_aclk 1 4 0xb6c 0x0 sdhi0_imclk sdhi0_imclk2 sdhi0_clk_hs
> > > sdhi0_aclk
> > > > > > > > > sdhi1_imclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > > sdhi1_aclk
> > > > > > > > > sdhi1_imclk2 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > > sdhi1_aclk
> > > > > > > > > sdhi1_clk_hs 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > > sdhi1_aclk
> > > > > > > > > sdhi1_aclk 0 0 0xb6c 0x2 sdhi1_imclk sdhi1_imclk2 sdhi1_clk_hs
> > > sdhi1_aclk
> > > > > > > > > gpu_clk 1 1 0xb80 0x0
> > > > > > > > > cru_sysclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > > cru_vclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > > cru_pclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > > cru_aclk 0 0 0xb78 0x8 cru_sysclk cru_vclk cru_pclk cru_aclk
> > > > > > > > > dsi_pll_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > dsi_sys_clk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > dsi_aclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > dsi_pclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > dsi_vclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > dsi_lpclk 1 6 0xb78 0x0 dsi_pll_clk dsi_sys_clk dsi_aclk
> dsi_pclk
> > > > > dsi_vclk
> > > > > > > > > dsi_lpclk
> > > > > > > > > lcdc_a 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > > > lcdc_p 3 1 0xb78 0x0 lcdc_a lcdc_p
> > > > > > > > > lcdc_clk_d 3 1 0xb78 0x0
> > > > > > > > > ssi0_pclk 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > > > ssi0_sfr 0 0 0xb64 0x400 ssi0_pclk ssi0_sfr
> > > > > > > > > ssi1_pclk 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > > > ssi1_sfr 0 0 0xb64 0x800 ssi1_pclk ssi1_sfr
> > > > > > > > > ssi2_pclk 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > > > ssi2_sfr 0 0 0xb64 0x1000 ssi2_pclk ssi2_sfr
> > > > > > > > > ssi3_pclk 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > > > ssi3_sfr 0 0 0xb64 0x2000 ssi3_pclk ssi3_sfr
> > > > > > > > > usb0_host 3 1 0xb6c 0x0
> > > > > > > > > usb1_host 0 0 0xb6c 0x80
> > > > > > > > > usb0_func 1 1 0xb6c 0x0
> > > > > > > > > usb_pclk 5 1 0xb6c 0x0
> > > > > > > > > eth0_axi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > > > eth0_chi 0 0 0xb6c 0x4 eth0_axi eth0_chi
> > > > > > > > > eth1_axi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > > > eth1_chi 0 0 0xb6c 0x8 eth1_axi eth1_chi
> > > > > > > > > i2c0 0 0 0xb68 0x400
> > > > > > > > > i2c1 0 0 0xb68 0x800
> > > > > > > > > i2c2 0 0 0xb68 0x1000
> > > > > > > > > i2c3 0 0 0xb68 0x2000
> > > > > > > > > scif0 2 1 0xb68 0x0
> > > > > > > > > scif1 0 0 0xb68 0x4
> > > > > > > > > scif2 0 0 0xb68 0x8
> > > > > > > > > scif3 0 0 0xb68 0x10
> > > > > > > > > scif4 0 0 0xb68 0x20
> > > > > > > > > sci0 0 0 0xb68 0x80
> > > > > > > > > sci1 0 0 0xb68 0x100
> > > > > > > > > rspi0 0 0 0xb64 0x4000
> > > > > > > > > rspi1 0 0 0xb64 0x8000
> > > > > > > > > rspi2 0 0 0xb68 0x1
> > > > > > > > > canfd 0 0 0xb68 0x200
> > > > > > > > > gpio 1 1 0xb70 0x0
> > > > > > > > > adc_adclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > > > adc_pclk 0 0 0xb68 0x4000 adc_adclk adc_pclk
> > > > > > > > > tsu_pclk 1 1 0xb68 0x0
> > > > > > > > > ----------------------------------
> > > > > > > > >
> > > > > > > > > I do not have acces to the other panels for the moment to run the same command.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Also, could you please check if the following diff solves your problem:
> > > > > > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > > index 5edd45424562..62957632a96f 100644
> > > > > > > > > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> > > > > > > > > > @@ -1282,6 +1282,10 @@ static ssize_t
> > > > > > > > > > rzg2l_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> > > > > > > > > > value |= SQCH0DSC0AR_FMT_SHORT;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > + ret = pm_runtime_resume_and_get(dsi->dev);
> > > > > > > > > > + if (ret)
> > > > > > > > > > + return ret;
> > > > > > > > > > +
> > > > > > > > > > rzg2l_mipi_dsi_link_write(dsi, SQCH0DSC0AR,
> > > > > > > > > > value);
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > > @@ -1322,6 +1326,8 @@ static ssize_t
> > > > > > > > > > rzg2l_mipi_dsi_host_transfer(struct
> > > > > > > > > > mipi_dsi_host *host,
> > > > > > > > > > ret = packet.payload_length;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > + pm_runtime_put(dsi->dev);
> > > > > > > > > > +
> > > > > > > > > > return ret;
> > > > > > > > > > }
> > > > > > > > >
> > > > > > > > > I confirm that it fixes the bug, altought I assume this
> > > > > > > > > is just for testing and is not the
> > > > > > > "proper"
> > > > > > > > > fix.
> > > > > > > >
> > > > > > > > Pre-MSTOP case during reboot, without clk it is accessing
> > > > > > > > registers)(mstop off always) it won't crash. But looks
> > > > > > > > like you may have ignored timeout error from
> > > > > > > [1].
> > > > > > >
> > > > > > > In case of a timeout error, it is not really ignored as the
> > > > > > > proper error code -ETIMEDOUT will be returned by
> > > > > > > rzg2l_mipi_dsi_host_transfer() (see log below). The hardware
> > > > > > > manual doesn't seem to properly explain how to deal with a
> > > > > > > timeout (or I could not find it). Do you have
> > > > > any suggestion on how to improve this?
> > > > > > >
> > > > > > > >
> > > > > > > > Post MSTOP case, if you access registers with mstop on, it will lead to crash.
> > > > > > > >
> > > > > > > > and the patch fixes crash.
> > > > > > > >
> > > > > > > > Basically, you are accessing link register after video is stopped with this panel.
> > > > > > > > Looks like it is a fix for me.
> > > > > > >
> > > > > > > Ok, like I said I am not an expert on this, but I was just
> > > > > > > assuming that there was a better way to ensure that the
> > > > > > > mipi/dsi interface was still active until the panel
> > > > > > > unprepare() function could do its work. I was looking at
> > > > > > > some other drivers mipi/dsi
> > > > > > > host_transfer() functions and did not see a similar
> > > > > > > pm_runtime_resume_and_get() scheme, hence my confusion.
> > > > > > >
> > > > > > > > Better check if there is any timeout error[1] with this patch.
> > > > > > > > if not, It is proper fix.
> > > > > > >
> > > > > > > The patch does fixes the kernel panic, but doesn't allow the
> > > > > > > panel to be properly unprepared, as I just noticed the timeout message:
> > > > > > >
> > > > > > > [ 39.321153] ili9881c-dsi 10850000.dsi.0: sending DCS SET_DISPLAY_OFF failed: -110
> > > > > > >
> > > > > > > In my case, for a reboot, this is not a problem, but it may
> > > > > > > be a problem for systems where it can be suspended (I assume)?
> > > > > > >
> > > > > > > Thank you for your help with this.
> > > > > >
> > > > > > Can you please try implement .atomic_post_disable()
> > > > > > symmetrical to
> > > rzg2l_mipi_dsi_atomic_pre_enable?
> > > > > >
> > > > > > Ie, move just rzg2l_mipi_dsi_stop(dsi) from
> > > > > > rzg2l_mipi_dsi_atomic_disable() to
> > > > > > rzg2l_mipi_dsi_atomic_post_disable()
> > > > > >
> > > > > > and check you can send DCS SET_DISPLAY_OFF successfully.
> > > > >
> > > > > I reverted the previous fix (pm_runtime_resume_and_get), and
> > > > > implemented .atomic_post_disable as you suggested, and this
> > > > > works great: the bug is no longer
> > > present and I do not see timeout errors:
> > > > >
> > > > > [ 537.727556] systemd-shutdown[1]: Syncing filesystems and block devices.
> > > > > [ 537.734544] systemd-shutdown[1]: Rebooting.
> > > > > [ 538.520174] rzg2l-mipi-dsi 10850000.dsi:
> > > > > rzg2l_mipi_dsi_atomic_disable(): entry [ 538.547848] ili9881c-dsi 10850000.dsi.0:
> > > ili9881c_unprepare(): entry [ 538.564524] rzg2l-mipi-dsi 10850000.dsi:
> > > > > rzg2l_mipi_dsi_atomic_post_disable(): entry [ 538.574016] reboot:
> > > > > Restarting system
> > > >
> > > > Great!
> > >
> > > Will you send a patch for this?
> >
> > Please feel free to send the patch, as you have the hardware to test it.
> >
> > I will add my Tb tag after testing your patch on my bridge setup.
>
> Ok, will do.
>
> Can you also check on what Claudiu mentioned about MSTOP values for this driver?
MSTOP is working as expected that is the reason you got abort during reboot.
If there is an issue with mstop usage count, you won't get abort.
All the clocks are turned off and usage count of mstop becomes 0 during reboot
and mstop set to 1.
Cheers,
Biju
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2026-01-09 16:14 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-01-07 21:48 [BUG] drm/panel: ilitek-ili9881c: kernel panic on reboot Hugo Villeneuve
2026-01-08 8:51 ` Geert Uytterhoeven
2026-01-08 9:12 ` Claudiu Beznea
2026-01-08 15:53 ` Hugo Villeneuve
2026-01-08 16:44 ` Biju Das
2026-01-08 17:51 ` Hugo Villeneuve
2026-01-08 21:21 ` Biju Das
2026-01-09 15:04 ` Hugo Villeneuve
2026-01-09 15:57 ` Biju Das
2026-01-09 15:59 ` Hugo Villeneuve
2026-01-09 16:03 ` Biju Das
2026-01-09 16:06 ` Hugo Villeneuve
2026-01-09 16:14 ` Biju Das
2026-01-09 9:49 ` Claudiu Beznea
2026-01-09 15:47 ` Hugo Villeneuve
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®