All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm
Date: Wed, 07 Nov 2018 15:27:32 +0200	[thread overview]
Message-ID: <4537562.ONtPKgIl9F@avalon> (raw)
In-Reply-To: <1f9771e7-0504-017d-863a-13604c24ef5d@ti.com>

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:
> > 
> > http://horus.dhcp.ti.com:7777/epowaxifuk.go
> 
> 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.

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2018-11-07 13:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 15:10 [PATCH v2 0/4] omapdrm: Fix runtime PM issues at module load and unload time Laurent Pinchart
2018-11-05 15:10 ` [PATCH v2 1/4] drm/omap: Populate DSS children in omapdss driver Laurent Pinchart
2018-11-05 20:00   ` Tony Lindgren
2018-11-05 15:10 ` [PATCH v2 2/4] drm/omap: hdmi4: Ensure the device is active during bind Laurent Pinchart
2018-11-05 20:02   ` Tony Lindgren
2018-11-05 21:45     ` Laurent Pinchart
2018-11-05 15:10 ` [PATCH v2 3/4] drm/omap: dsi: Ensure the device is active during probe Laurent Pinchart
2018-11-05 20:11   ` Tony Lindgren
2018-11-05 15:10 ` [PATCH v2 4/4] drm/omap: Work around missing DISPC in runtime PM handlers Laurent Pinchart
2018-11-05 19:23 ` [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm Laurent Pinchart
2018-11-05 20:14   ` Tony Lindgren
2018-11-05 21:46     ` Laurent Pinchart
2018-11-06  9:22       ` Tomi Valkeinen
2018-11-06 12:47         ` Tomi Valkeinen
2018-11-07 13:27           ` Laurent Pinchart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4537562.ONtPKgIl9F@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.