Hi Tomi,
On Tuesday, 6 November 2018 14:47:51 EET Tomi Valkeinen wrote:
On 06/11/18 11:22, Tomi Valkeinen wrote:
On 05/11/18 23:46, Laurent Pinchart wrote:
On Monday, 5 November 2018 22:14:46 EET Tony Lindgren wrote:
- Laurent Pinchart laurent.pinchart@ideasonboard.com [181105 19:23]:
This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM issues at module load and unload time" series. It demonstrates what I think is the proper long term fix for the issue addressed by patch 4/4. Due to its nature, I don't think this patch should be applied for v4.20 as it qualifies for very careful testing, hence my proposal to fix the runtime PM problem with 4/4 and to queue this patch for v4.21.
To me this seems like a less risky fix compared to conditional runtime PM calls in patch 4. Conditional calls with usecounts seem to always break one way or another.. So would be nice to go with this one if possible.
If Tomi is fine with this, and after careful testing, I have no issue with merging this patch squashed with 4/4 for 4.20-rc.
I didn't try it yet, but it makes sense and looks good to me, so I think we should try to go with this one instead of the 4/4.
I've tested the patch on both Pandaboard and AM57xx EVM without any noticing any issue. I would appreciate if you could test it as well before we deem it fit for v4.20.
Btw, Peter also reported this one on linux-next on beagle-xm:
Ops, didn't notice that was an internal pastebin. Here's the crash:
[ 180.053192] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 [ 180.060913] pgd = 42d2749f [ 180.063629] [fa050040] *pgd=48011452(bad) [ 180.067687] Internal error: : 1028 [#1] PREEMPT SMP ARM [ 180.072937] Modules linked in: [ 180.076019] CPU: 0 PID: 3072 Comm: halt Not tainted 4.19.0-rc8-next-20181019-00090-gec9a27467a7f #2 [ 180.085083] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 180.091400] PC is at dss_set_dac_pwrdn_bgz+0x4/0x18 [ 180.096313] LR is at venc_display_disable+0x2c/0x50 [ 180.101196] pc : [<c0558e98>] lr : [<c0564d94>] psr: 60070013 [ 180.107513] sp : da405e30 ip : db3b4d80 fp : c0b619d4 [ 180.112762] r10: c0b619e4 r9 : c0e76760 r8 : db1cf844 [ 180.118011] r7 : c0ea8870 r6 : db758000 r5 : db758008 r4 : db758060 [ 180.124542] r3 : fa050c00 r2 : fa050000 r1 : 00000000 r0 : db709c00 [ 180.131103] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 180.138275] Control: 10c5387d Table: 9a138019 DAC: 00000051 [ 180.144042] Process halt (pid: 3072, stack limit = 0x785a09e7) [ 180.149902] Stack: (0xda405e30 to 0xda406000)
[snip]
[ 180.277587] [<c0558e98>] (dss_set_dac_pwrdn_bgz) from [<c0564d94>] (venc_display_disable+0x2c/0x50) [ 180.286682] [<c0564d94>] (venc_display_disable) from [<c05735d4>] (tvc_disable+0x28/0x34) [ 180.294921] [<c05735d4>] (tvc_disable) from [<c05585dc>] (dss_shutdown+0x34/0x38) [ 180.302429] [<c05585dc>] (dss_shutdown) from [<c058a3f4>] (device_shutdown+0x160/0x20c) [ 180.310485] [<c058a3f4>] (device_shutdown) from [<c0156b44>] (kernel_power_off+0x2c/0x70) [ 180.318695] [<c0156b44>] (kernel_power_off) from [<c0156d00>] (sys_reboot+0x130/0x1e8) [ 180.326660] [<c0156d00>] (sys_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x54) [ 180.334350] Exception stack(0xda405fa8 to 0xda405ff0) [ 180.339447] 5fa0: 00000000 00000002 fee1dead 28121969 4321fedc 00022958 [ 180.347656] 5fc0: 00000000 00000002 00000000 00000058 00000000 00000001 00000000 00000000 [ 180.355865] 5fe0: 50313900 beb4ec78 00011158 b6e4e39c [ 180.360961] Code: e5821040 e12fff1e e7f001f2 e5902004 (e5923040) [ 180.367065] ---[ end trace 8d96f3954c4321c5 ]--- [ 180.371856] In-band Error seen by MPU at address 0 [ 180.376739] ------------[ cut here ]------------ [ 180.381408] WARNING: CPU: 0 PID: 3072 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xac/0x118 [ 180.390411] Modules linked in: [ 180.393463] CPU: 0 PID: 3072 Comm: halt Tainted: G D 4.19.0-rc8-next-20181019-00090-gec9a27467a7f
I dove into my boxes of development board and managed to find a Beagleboard- xM. After dusting it and being amazed it was still working, I tested v4.20-rc1 and couldn't reproduce the above issue, neither with nor without the regression fixes.