Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CALAqxLVrZXRT875-AxN=jt_kSD5=Nb9SuCW4PEsVL=pQkT_ugw@mail.gmail.com>
References: <CAPM=9txqtcX42eSYjkyJLL8mmzomXRRHi7iWmW=BYgk=CAagZg@mail.gmail.com>
 <CALAqxLXt3MOc=W_gnsR=D=Um5RPsK+6sTKDbSiqro_53ZbXfQQ@mail.gmail.com>
 <CAKMK7uFb0jXVm4gGr_TR07mhT924sTORGXZVNzx4rdTe3Pj94Q@mail.gmail.com>
 <CALAqxLWq-wgbc+aS0p45rvxmPj3KicsOV5ucCB-tcKWr74uqCQ@mail.gmail.com>
 <CAKMK7uEbfa24DaDbWjxgerzH69q-niHS5==z6NqJd3Yxi0q+7A@mail.gmail.com> <CALAqxLVrZXRT875-AxN=jt_kSD5=Nb9SuCW4PEsVL=pQkT_ugw@mail.gmail.com>
From:   Daniel Vetter <daniel@ffwll.ch>
Date:   Fri, 17 Aug 2018 00:16:34 +0200
Message-ID: <CAKMK7uHrCAQpUhd2D4PpiizascLwP1kYgMM6cZv3B8OGez66Sw@mail.gmail.com>
Subject: Re: [git pull] drm for 4.19-rc1
To:     John Stultz <john.stultz@linaro.org>
Cc:     Dave Airlie <airlied@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 16, 2018 at 11:21 PM, John Stultz <john.stultz@linaro.org> wrot=
e:
> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Thu, Aug 16, 2018 at 10:38 PM, John Stultz <john.stultz@linaro.org> w=
rote:
>>> On Thu, Aug 16, 2018 at 12:16 AM, Daniel Vetter <daniel@ffwll.ch> wrote=
:
>>>> On Thu, Aug 16, 2018 at 8:04 AM, John Stultz <john.stultz@linaro.org> =
wrote:
>>>>> On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie <airlied@gmail.com> wrot=
e:
>>>>>> 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 f=
or the
>>>>>> acceleration engine.
>>>>>>
>>>>>> This also contains a wound-wait/wait-die mutex rework, Peter has ack=
ed 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 =3D 0x96000005
>>>>> [    8.088402]   Exception class =3D DABT (current EL), IL =3D 32 bit=
s
>>>>> [    8.088406]   SET =3D 0, FnV =3D 0
>>>>> [    8.088410]   EA =3D 0, S1PTW =3D 0
>>>>> [    8.088413] Data abort info:
>>>>> [    8.088417]   ISV =3D 0, ISS =3D 0x00000005
>>>>> [    8.088421]   CM =3D 0, WnR =3D 0
>>>>> [    8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp =3D (____ptrv=
al____)
>>>>> [    8.088432] [0000000000000030] pgd=3D0000000000000000, pud=3D00000=
00000000000
>>>>> [    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 =3D 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_op=
s)
>>>>> [    4.627304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2=
013).
>>>>> [    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 fbde=
v.
>>>>> [    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=C3=B8nnes (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).
>>>
>>> So I can confirm reverting:
>>> 85b5bafb86e6 ("drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs(=
)")
>>> and
>>> 894a677f4b3e ("drm/cma-helper: Use the generic fbdev emulation")
>>>
>>> makes things work again.
>>>
>>> Though without the reverts, I was digging to understand what was
>>> failing, and it seems when we call into
>>> drm_client_framebuffer_create(), as Noralf suggested, we're eventually
>>> failing at drm_internal_framebuffer_create() when checking
>>> config->max_height.  The kirin driver is somewhat limited w/ max
>>> width/height values at 2048 each.
>>>
>>> Though I'm on a 1920x1080 monitor (max resolution supported by the
>>> board), it seems we're trying to allocate a 1920x2160 buffer? I know
>>> Android tries to allocate 2x Y for page-flipping, but I'm not sure yet
>>> why the old code didn't hit this problem.
>>>
>>> Unfortunately bumping the max width/height values to 4096 cause the
>>> system to hard hang as userspace starts up (and setting it to
>>> 2048/2160 does the same).
>>>
>>> So yea, I'm going to continue to dig at the hard-hang issue, and
>>> hopefully we can just  bump the max width/height, but if there are
>>> other suggestions, please let me know.
>>
>> You happen to have set drm_fb_overalloc respectively
>> CONFIG_DRM_FBDEV_OVERALLOC? Was added so that mali blob can pageflip,
>> would explain what's going on at least.
>
> Yep. CONFIG_DRM_FBDEV_OVERALLOC is set to 200.

So ->max_height is indeed the limit (or should be, minus driver bugs)
for framebuffers. That's enforced in drm_framebuffer_create_internal
for everything (both ioctl and should also for all internal callers),
except the cma helpers never made sure this is correct. So I'd call
this a bugfix.

Now the question is whether the fbdev page-flipping actually worked on
older kernels for you or not ...
-Daniel
--=20
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch