Re: [git pull] drm for 4.19-rc1

From: Noralf TrÃnnes
Date: Thu Aug 16 2018 - 04:22:20 EST


Den 16.08.2018 09.16, skrev Daniel Vetter:
On Thu, Aug 16, 2018 at 8:04 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie <airlied@xxxxxxxxx> wrote:
This is the main drm pull request for 4.19.

Rob has some new hardware support for new qualcomm hw that I'll send along
separately. This has the display part of it, the remaining pull is for the
acceleration engine.

This also contains a wound-wait/wait-die mutex rework, Peter has acked it
for merging via my tree.

Otherwise mostly the usual level of activity.
Hey Folks,
Since this branch landed, I've been seeing the following panic on
bootup w/ the HiKey board (which uses the hisilicon/kirin drm driver):

[ 8.088388] Unable to handle kernel read from unreadable memory at
virtual address 0000000000000030
[ 8.088393] Mem abort info:
[ 8.088397] ESR = 0x96000005
[ 8.088402] Exception class = DABT (current EL), IL = 32 bits
[ 8.088406] SET = 0, FnV = 0
[ 8.088410] EA = 0, S1PTW = 0
[ 8.088413] Data abort info:
[ 8.088417] ISV = 0, ISS = 0x00000005
[ 8.088421] CM = 0, WnR = 0
[ 8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
[ 8.088432] [0000000000000030] pgd=0000000000000000, pud=0000000000000000
[ 8.088443] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: G W
4.18.0-07439-gbf1fba4 #633
[ 8.088457] Hardware name: HiKey Development Board (DT)
[ 8.088474] Workqueue: events adv7511_hpd_work
[ 8.088482] pstate: 40400005 (nZcv daif +PAN -UAO)
[ 8.088493] pc : drm_sysfs_hotplug_event+0x40/0x78
[ 8.088499] lr : drm_sysfs_hotplug_event+0x40/0x78
[ 8.088502] sp : ffffff800ba73d20
[ 8.088506] x29: ffffff800ba73d20 x28: 0000000000000000
[ 8.088514] x27: ffffff8009293cd8 x26: ffffffc074e55938
[ 8.088522] x25: 0000000000000000 x24: ffffffc07ff85000
[ 8.088530] x23: ffffffc0742c4a78 x22: ffffffc07ff86c00
[ 8.088537] x21: ffffffc0750d0e00 x20: 0000000000000000
[ 8.088545] x19: ffffff8009009a48 x18: 0000000000000000
[ 8.088552] x17: 0000000000000000 x16: ffffffc074fbde80
[ 8.088560] x15: 0000000000000000 x14: ffffffc005f96c00
[ 8.088568] x13: 00000040770c9000 x12: 0000000034d5d91d
[ 8.088575] x11: 0000000000000000 x10: 0000000000000990
[ 8.088582] x9 : ffffff800ba739b0 x8 : ffffff800913e000
[ 8.088589] x7 : 0000000000000000 x6 : ffffff8009009a48
[ 8.088596] x5 : ffffff80090588d0 x4 : 0000000000000000
[ 8.088602] x3 : ffffff8009009a48 x2 : 0000000000000000
[ 8.088608] x1 : 18701cfc97cf1200 x0 : 0000000000000000
[ 8.120775] Process kworker/5:2 (pid: 1414, stack limit = 0x(____ptrval____))
[ 8.120778] Call trace:
[ 8.120787] drm_sysfs_hotplug_event+0x40/0x78
[ 8.120794] drm_kms_helper_hotplug_event+0x14/0x40
[ 8.120800] adv7511_hpd_work+0x64/0xe0
[ 8.120807] process_one_work+0x12c/0x320
[ 8.120814] worker_thread+0x48/0x458
[ 8.126654] kthread+0xf8/0x128
[ 8.126661] ret_from_fork+0x10/0x18
[ 8.126672] Code: aa0003f4 52800020 a902ffa2 94006637 (f9401a80)
[ 8.135638] ---[ end trace cf7120942e6f40fa ]---

And earlier in boot we see:

[ 4.620909] kirin-drm f4100000.ade: bound f4107800.dsi (ops dsi_ops)
[ 4.627304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4.633935] [drm] No driver support for vblank timestamp query.
[ 4.732910] kirin-drm f4100000.ade: [drm:drm_fb_helper_fbdev_setup]
*ERROR* Failed to set fbdev configuration
[ 4.742948] [drm:kirin_drm_bind] *ERROR* failed to initialize fbdev.
[ 4.749585] kirin-drm f4100000.ade: master bind failed: -22
[ 4.755218] dw-dsi: probe of f4107800.dsi failed with error -22

I've also seen similar trouble w/ the HiKey960 which uses a similar
but still out of tree driver that also utilizes the cma fbhelper code,
which makes me suspect it has to do with the drm/cma-helper changes
below:

Noralf TrÃnnes (15):
drm/file: Don't set master on in-kernel clients
drm: Make ioctls available for in-kernel clients
drm: Begin an API for in-kernel clients
drm/fb-helper: Add generic fbdev emulation .fb_probe function
drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
drm/cma-helper: Use the generic fbdev emulation
drm/debugfs: Add internal client debugfs file
drm/fb-helper: Finish the generic fbdev emulation
drm/tinydrm: Use drm_fbdev_generic_setup()
drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
Though I've not yet had time to bisect this down tonight.

I'll spend some more time on this tomorrow, but wanted to give folks a
heads up in the meantime.
Hm, not immediately seeing what's going boom here. Bisect would indeed
be good, but maybe we need to chase the callchain to figure out where
exactly that -EINVAL is coming from in the reworked code (and why
hikey is the first to hit that, there's lots of cma based drivers
after all).

Call chain deducted from the error messages:
kirin_drm_bind -> kirin_drm_kms_init -> drm_fbdev_cma_init ->
drm_fb_helper_fbdev_setup -> drm_fb_helper_initial_config

If this message turns up when enabling debug messages:

int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂ struct drm_fb_helper_surface_size *sizes)
{
...
ÂÂÂ DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
ÂÂÂ ÂÂÂ ÂÂÂÂÂ sizes->surface_width, sizes->surface_height,
ÂÂÂ ÂÂÂ ÂÂÂÂÂ sizes->surface_bpp);

ÂÂÂ format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth);
ÂÂÂ buffer = drm_client_framebuffer_create(client, sizes->surface_width,
ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂ ÂÂÂÂÂÂ sizes->surface_height, format);
ÂÂÂ if (IS_ERR(buffer))
ÂÂÂ ÂÂÂ return PTR_ERR(buffer);
...

then it's probably drm_client_framebuffer_create() that fails.
That function creates a dumb buffer and is a likely suspect.

Noralf.