Re: [git pull] drm for 4.19-rc1

2018-08-17 Thread Daniel Vetter
On Fri, Aug 17, 2018 at 12:22 AM, John Stultz  wrote:
> On Thu, Aug 16, 2018 at 3:16 PM, Daniel Vetter  wrote:
>> On Thu, Aug 16, 2018 at 11:21 PM, John Stultz  wrote:
>>> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter  wrote:
 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.
>
> Sure.  I'm really not sure where the max_height=2048 comes from (and
> if its the real limitation or a vendor guessed value - the hikey960
> driver I have uses the same), but yea, the old code wasn't checking
> it.

So in a way the limit is not entirely correct, since it's enforced for
drm_framebuffer, not for the underlying memory object. Assuming you
keep alignment correct (which is not exposed to userspace) you can
overallocate that and scan the drm_framebuffer over it. But the fbdev
helpers don't do that.

We also don't have separate limits for fb sizes and max scanout.
Though the later is supposed to be filtered in the various mode_valid
callbacks, not through max_*.

>> Now the question is whether the fbdev page-flipping actually worked on
>> older kernels for you or not ...
>
> It sure seems to work ok with the changes reverted.   Any suggestion
> on how to check this?

No idea. I didn't type a testcase for it, wasn't my feature :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread John Stultz
On Thu, Aug 16, 2018 at 3:16 PM, Daniel Vetter  wrote:
> On Thu, Aug 16, 2018 at 11:21 PM, John Stultz  wrote:
>> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter  wrote:
>>> 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.

Sure.  I'm really not sure where the max_height=2048 comes from (and
if its the real limitation or a vendor guessed value - the hikey960
driver I have uses the same), but yea, the old code wasn't checking
it.

> Now the question is whether the fbdev page-flipping actually worked on
> older kernels for you or not ...

It sure seems to work ok with the changes reverted.   Any suggestion
on how to check this?

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread Daniel Vetter
On Thu, Aug 16, 2018 at 11:21 PM, John Stultz  wrote:
> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter  wrote:
>> On Thu, Aug 16, 2018 at 10:38 PM, John Stultz  wrote:
>>> On Thu, Aug 16, 2018 at 12:16 AM, Daniel Vetter  wrote:
 On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  
 wrote:
> On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
> [8.088393] Mem abort info:
> [8.088397]   ESR = 0x9605
> [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 = 0x0005
> [8.088421]   CM = 0, WnR = 0
> [8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
> [8.088432] [0030] pgd=, 
> pud=
> [8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
>4.18.0-07439-gbf1fba4 #633
> [8.088457] Hardware name: HiKey Development Board (DT)
> [8.088474] Workqueue: events adv7511_hpd_work
> [8.088482] pstate: 4045 (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 : ff800ba73d20
> [8.088506] x29: ff800ba73d20 x28: 
> [8.088514] x27: ff8009293cd8 x26: ffc074e55938
> [8.088522] x25:  x24: ffc07ff85000
> [8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
> [8.088537] x21: ffc0750d0e00 x20: 
> [8.088545] x19: ff8009009a48 x18: 
> [8.088552] x17:  x16: ffc074fbde80
> [8.088560] x15:  x14: ffc005f96c00
> [8.088568] x13: 0040770c9000 x12: 34d5d91d
> [8.088575] x11:  x10: 0990
> [8.088582] x9 : ff800ba739b0 x8 : ff800913e000
> [8.088589] x7 :  x6 : ff8009009a48
> [8.088596] x5 : ff80090588d0 x4 : 
> [8.088602] x3 : ff8009009a48 x2 : 
> [8.088608] x1 : 18701cfc97cf1200 x0 : 
> [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 f410.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 f410.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 f410.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 

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread John Stultz
On Thu, Aug 16, 2018 at 1:38 PM, John Stultz  wrote:
>
> 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.

So still digging on the hard hang after bumping the max_height value.
It seems to trigger as the display is being initialized by userland,
so if I boot with the HDMI cable unplugged the kernel boots fine (as
userland error loops looking for a display). Then when I hotplug the
HDMI cable it will hang. Booting with drm_debug=0xe,  (and doing the
HDMI hotplug after bootup) I see:

[   63.172368] [drm:dsi_encoder_phy_mode_valid] OK!
[   63.185522] [drm:drm_calc_timestamping_constants] crtc 29: hwmode:
htotal 2200, vtotal 1125, vdisplay 1080
[   63.195213] [drm:drm_calc_timestamping_constants] crtc 29: clock
148500 kHz framedur 1666 linedur 14814
[   63.205114] [drm:ade_ldi_set_mode.isra.9] set mode: 1920x1080
[   63.212529] [drm:ade_ldi_set_mode.isra.9] set mode: 1920x1080
[   63.218333] [drm:ade_plane_atomic_update] channel1: src:(0,
0)-1920x1080, crtc:(0, 0)-1920x1080
[   63.218346] [drm:ade_plane_atomic_update] rdma1: (y=0,
height=1080), stride=7680, paddr=0x77d0
[   63.236111] [drm:ade_plane_atomic_update] addr=0x77d0,
fb:1920x2160, pixel_format=2(XR24 little-endian (0x34325258))
[   63.238695] Mali<2>:
[   63.247032] [drm:ade_plane_atomic_update] clip1: clip_left=0, clip_right=0
[   63.247053] [drm:drm_vblank_enable] enabling vblank on crtc 0, ret: 0
[   63.249319] Session 0x74ACAE00 with pid 2249 was granted higher priority.
[   63.256253] [drm:ade_dump_regs] [rdma1]: reload(0)
[   63.273400] [drm:drm_handle_vblank] vblank event on 1, current 1
[   63.274362] [drm:ade_dump_regs] [rdma1]: reg_ctrl(0x0002)
[   63.286201] [drm:ade_dump_regs] [rdma1]: reg_addr(0x77d0)
[   63.286208] [drm:ade_dump_regs] [rdma1]: reg_size(0x04381e00)
[   63.286214] [drm:ade_dump_regs] [rdma1]: reg_stride(0x1e00)
[   63.286221] [drm:ade_dump_regs] [rdma1]: reg_space(0x007e9000)
[   63.286227] [drm:ade_dump_regs] [rdma1]: reg_en(0x)
[   63.286234] [drm:ade_dump_regs] [clip1]: reload(0)
[   63.286248] [drm:ade_dump_regs] [clip1]: reg_clip_disable(0x0001)
[   63.326460] [drm:ade_dump_regs] [clip1]: reg_clip_size0(0x077f0437)
[   63.332786] [drm:ade_dump_regs] [clip1]: reg_clip_size1(0x)
[   63.339102] [drm:ade_dump_regs] [overlay ch0]: reg_ch_xy0(0x)
[   63.345596] [drm:ade_dump_regs] [overlay ch0]: reg_ch_xy1(0x077f0437)
[   63.350809] init: Received control message 'start' for 'bootanim'
from pid: 2249 (/system/bin/surfaceflinger)
[   63.352091] [drm:ade_dump_regs] [overlay ch0]: reg_ch_ctl(0x107f806c)
[   63.362726] init: starting service 'bootanim'...
[   63.368494] [drm:ade_dump_regs] [overlay2]: reload(0)
[   63.368506] [drm:ade_dump_regs] [overlay2]: reg_ctl(0x)
[   63.384170] [drm:ade_dump_regs] ovly_ctl(0x0002)
[   63.390826] [drm:dsi_encoder_enable] htot=2200, hfp=88, hbp=148, hsw=44
[   63.397502] [drm:dsi_encoder_enable] vtol=1125, vfp=4, vbp=36, vsw=5
[   63.403902] [drm:dsi_encoder_enable] hsa_time=33, hbp_time=111,
hline_time=1650
[   63.411250] [drm:dsi_encoder_enable] lanes=4, pixel_clk=144000 kHz,
bytes_freq=108000 kHz
[   63.428238] [drm:drm_mode_object_put] OBJ ID: 31 (5)


Not always, but sometimes as it hangs I'll see:
 [drm:vblank_disable_fn] disabling vblank on crtc 0

And sometimes I'll also see:
Insufficient stack space to handle exception!

So I'm not sure if there's a screaming interrupt or what (nor am I
sure what from the problematic changes would cause that change
either).

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread John Stultz
On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter  wrote:
> On Thu, Aug 16, 2018 at 10:38 PM, John Stultz  wrote:
>> On Thu, Aug 16, 2018 at 12:16 AM, Daniel Vetter  wrote:
>>> On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  wrote:
 On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
 [8.088393] Mem abort info:
 [8.088397]   ESR = 0x9605
 [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 = 0x0005
 [8.088421]   CM = 0, WnR = 0
 [8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
 [8.088432] [0030] pgd=, 
 pud=
 [8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
 [8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
4.18.0-07439-gbf1fba4 #633
 [8.088457] Hardware name: HiKey Development Board (DT)
 [8.088474] Workqueue: events adv7511_hpd_work
 [8.088482] pstate: 4045 (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 : ff800ba73d20
 [8.088506] x29: ff800ba73d20 x28: 
 [8.088514] x27: ff8009293cd8 x26: ffc074e55938
 [8.088522] x25:  x24: ffc07ff85000
 [8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
 [8.088537] x21: ffc0750d0e00 x20: 
 [8.088545] x19: ff8009009a48 x18: 
 [8.088552] x17:  x16: ffc074fbde80
 [8.088560] x15:  x14: ffc005f96c00
 [8.088568] x13: 0040770c9000 x12: 34d5d91d
 [8.088575] x11:  x10: 0990
 [8.088582] x9 : ff800ba739b0 x8 : ff800913e000
 [8.088589] x7 :  x6 : ff8009009a48
 [8.088596] x5 : ff80090588d0 x4 : 
 [8.088602] x3 : ff8009009a48 x2 : 
 [8.088608] x1 : 18701cfc97cf1200 x0 : 
 [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 f410.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 f410.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 f410.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 

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread Daniel Vetter
On Thu, Aug 16, 2018 at 10:38 PM, John Stultz  wrote:
> On Thu, Aug 16, 2018 at 12:16 AM, Daniel Vetter  wrote:
>> On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  wrote:
>>> On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
>>> [8.088393] Mem abort info:
>>> [8.088397]   ESR = 0x9605
>>> [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 = 0x0005
>>> [8.088421]   CM = 0, WnR = 0
>>> [8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
>>> [8.088432] [0030] pgd=, pud=
>>> [8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
>>> [8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
>>>4.18.0-07439-gbf1fba4 #633
>>> [8.088457] Hardware name: HiKey Development Board (DT)
>>> [8.088474] Workqueue: events adv7511_hpd_work
>>> [8.088482] pstate: 4045 (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 : ff800ba73d20
>>> [8.088506] x29: ff800ba73d20 x28: 
>>> [8.088514] x27: ff8009293cd8 x26: ffc074e55938
>>> [8.088522] x25:  x24: ffc07ff85000
>>> [8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
>>> [8.088537] x21: ffc0750d0e00 x20: 
>>> [8.088545] x19: ff8009009a48 x18: 
>>> [8.088552] x17:  x16: ffc074fbde80
>>> [8.088560] x15:  x14: ffc005f96c00
>>> [8.088568] x13: 0040770c9000 x12: 34d5d91d
>>> [8.088575] x11:  x10: 0990
>>> [8.088582] x9 : ff800ba739b0 x8 : ff800913e000
>>> [8.088589] x7 :  x6 : ff8009009a48
>>> [8.088596] x5 : ff80090588d0 x4 : 
>>> [8.088602] x3 : ff8009009a48 x2 : 
>>> [8.088608] x1 : 18701cfc97cf1200 x0 : 
>>> [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 f410.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 f410.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 f410.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.
>>>

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread John Stultz
On Thu, Aug 16, 2018 at 12:16 AM, Daniel Vetter  wrote:
> On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  wrote:
>> On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
>> [8.088393] Mem abort info:
>> [8.088397]   ESR = 0x9605
>> [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 = 0x0005
>> [8.088421]   CM = 0, WnR = 0
>> [8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
>> [8.088432] [0030] pgd=, pud=
>> [8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
>> [8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
>>4.18.0-07439-gbf1fba4 #633
>> [8.088457] Hardware name: HiKey Development Board (DT)
>> [8.088474] Workqueue: events adv7511_hpd_work
>> [8.088482] pstate: 4045 (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 : ff800ba73d20
>> [8.088506] x29: ff800ba73d20 x28: 
>> [8.088514] x27: ff8009293cd8 x26: ffc074e55938
>> [8.088522] x25:  x24: ffc07ff85000
>> [8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
>> [8.088537] x21: ffc0750d0e00 x20: 
>> [8.088545] x19: ff8009009a48 x18: 
>> [8.088552] x17:  x16: ffc074fbde80
>> [8.088560] x15:  x14: ffc005f96c00
>> [8.088568] x13: 0040770c9000 x12: 34d5d91d
>> [8.088575] x11:  x10: 0990
>> [8.088582] x9 : ff800ba739b0 x8 : ff800913e000
>> [8.088589] x7 :  x6 : ff8009009a48
>> [8.088596] x5 : ff80090588d0 x4 : 
>> [8.088602] x3 : ff8009009a48 x2 : 
>> [8.088608] x1 : 18701cfc97cf1200 x0 : 
>> [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 f410.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 f410.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 f410.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 

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread Noralf Trønnes


Den 16.08.2018 09.16, skrev Daniel Vetter:

On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  wrote:

On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
[8.088393] Mem abort info:
[8.088397]   ESR = 0x9605
[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 = 0x0005
[8.088421]   CM = 0, WnR = 0
[8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[8.088432] [0030] pgd=, pud=
[8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
[8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
4.18.0-07439-gbf1fba4 #633
[8.088457] Hardware name: HiKey Development Board (DT)
[8.088474] Workqueue: events adv7511_hpd_work
[8.088482] pstate: 4045 (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 : ff800ba73d20
[8.088506] x29: ff800ba73d20 x28: 
[8.088514] x27: ff8009293cd8 x26: ffc074e55938
[8.088522] x25:  x24: ffc07ff85000
[8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
[8.088537] x21: ffc0750d0e00 x20: 
[8.088545] x19: ff8009009a48 x18: 
[8.088552] x17:  x16: ffc074fbde80
[8.088560] x15:  x14: ffc005f96c00
[8.088568] x13: 0040770c9000 x12: 34d5d91d
[8.088575] x11:  x10: 0990
[8.088582] x9 : ff800ba739b0 x8 : ff800913e000
[8.088589] x7 :  x6 : ff8009009a48
[8.088596] x5 : ff80090588d0 x4 : 
[8.088602] x3 : ff8009009a48 x2 : 
[8.088608] x1 : 18701cfc97cf1200 x0 : 
[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 f410.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 f410.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 f410.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 

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread Daniel Vetter
On Thu, Aug 16, 2018 at 8:04 AM, John Stultz  wrote:
> On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
> [8.088393] Mem abort info:
> [8.088397]   ESR = 0x9605
> [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 = 0x0005
> [8.088421]   CM = 0, WnR = 0
> [8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
> [8.088432] [0030] pgd=, pud=
> [8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
>4.18.0-07439-gbf1fba4 #633
> [8.088457] Hardware name: HiKey Development Board (DT)
> [8.088474] Workqueue: events adv7511_hpd_work
> [8.088482] pstate: 4045 (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 : ff800ba73d20
> [8.088506] x29: ff800ba73d20 x28: 
> [8.088514] x27: ff8009293cd8 x26: ffc074e55938
> [8.088522] x25:  x24: ffc07ff85000
> [8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
> [8.088537] x21: ffc0750d0e00 x20: 
> [8.088545] x19: ff8009009a48 x18: 
> [8.088552] x17:  x16: ffc074fbde80
> [8.088560] x15:  x14: ffc005f96c00
> [8.088568] x13: 0040770c9000 x12: 34d5d91d
> [8.088575] x11:  x10: 0990
> [8.088582] x9 : ff800ba739b0 x8 : ff800913e000
> [8.088589] x7 :  x6 : ff8009009a48
> [8.088596] x5 : ff80090588d0 x4 : 
> [8.088602] x3 : ff8009009a48 x2 : 
> [8.088608] x1 : 18701cfc97cf1200 x0 : 
> [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 f410.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 f410.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 f410.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 

Re: [git pull] drm for 4.19-rc1

2018-08-16 Thread John Stultz
On Tue, Aug 14, 2018 at 7:53 PM, Dave Airlie  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 0030
[8.088393] Mem abort info:
[8.088397]   ESR = 0x9605
[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 = 0x0005
[8.088421]   CM = 0, WnR = 0
[8.088427] user pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[8.088432] [0030] pgd=, pud=
[8.088443] Internal error: Oops: 9605 [#1] PREEMPT SMP
[8.088453] CPU: 5 PID: 1414 Comm: kworker/5:2 Tainted: GW
   4.18.0-07439-gbf1fba4 #633
[8.088457] Hardware name: HiKey Development Board (DT)
[8.088474] Workqueue: events adv7511_hpd_work
[8.088482] pstate: 4045 (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 : ff800ba73d20
[8.088506] x29: ff800ba73d20 x28: 
[8.088514] x27: ff8009293cd8 x26: ffc074e55938
[8.088522] x25:  x24: ffc07ff85000
[8.088530] x23: ffc0742c4a78 x22: ffc07ff86c00
[8.088537] x21: ffc0750d0e00 x20: 
[8.088545] x19: ff8009009a48 x18: 
[8.088552] x17:  x16: ffc074fbde80
[8.088560] x15:  x14: ffc005f96c00
[8.088568] x13: 0040770c9000 x12: 34d5d91d
[8.088575] x11:  x10: 0990
[8.088582] x9 : ff800ba739b0 x8 : ff800913e000
[8.088589] x7 :  x6 : ff8009009a48
[8.088596] x5 : ff80090588d0 x4 : 
[8.088602] x3 : ff8009009a48 x2 : 
[8.088608] x1 : 18701cfc97cf1200 x0 : 
[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 f410.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 f410.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 f410.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.

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel