PL111 regression in v4.19-rc1

PL111 regression in v4.19-rc1

[Linus Walleij]

Hi folks,

I'm seeing this on all PL111 systems (several ARM reference
designs and Nomadik) with v4.19-rc1:

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:516
drm_gem_cma_create+0x13c/0x158
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0+ #135
Hardware name: ARM-Versatile (Device Tree Support)
[<c001c4e0>] (unwind_backtrace) from [<c0019198>] (show_stack+0x10/0x14)
[<c0019198>] (show_stack) from [<c0024528>] (__warn+0xcc/0xf4)
[<c0024528>] (__warn) from [<c0024664>] (warn_slowpath_null+0x3c/0x48)
[<c0024664>] (warn_slowpath_null) from [<c0259710>]
(drm_gem_cma_create+0x13c/0x158)
[<c0259710>] (drm_gem_cma_create) from [<c0234700>]
(drm_fbdev_cma_create+0x58/0x248)
[<c0234700>] (drm_fbdev_cma_create) from [<c0233d3c>]
(__drm_fb_helper_initial_config_and_unlock+0x1c8/0x450)
[<c0233d3c>] (__drm_fb_helper_initial_config_and_unlock) from
[<c023450c>] (drm_fb_cma_fbdev_init_with_funcs+0x8c/0x114)
[<c023450c>] (drm_fb_cma_fbdev_init_with_funcs) from [<c025d23c>]
(pl111_amba_probe+0x3c8/0x4a4)
[<c025d23c>] (pl111_amba_probe) from [<c01f3c64>] (amba_probe+0xd8/0x154)
[<c01f3c64>] (amba_probe) from [<c02637e4>] (driver_probe_device+0x25c/0x310)
[<c02637e4>] (driver_probe_device) from [<c0263968>] (__driver_attach+0xd0/0xd4)
[<c0263968>] (__driver_attach) from [<c0261b30>] (bus_for_each_dev+0x70/0xb4)
[<c0261b30>] (bus_for_each_dev) from [<c0262c74>] (bus_add_driver+0x170/0x204)
[<c0262c74>] (bus_add_driver) from [<c0264278>] (driver_register+0x74/0x108)
[<c0264278>] (driver_register) from [<c000abf8>] (do_one_initcall+0x48/0x1a0)
[<c000abf8>] (do_one_initcall) from [<c04fedc0>]
(kernel_init_freeable+0x104/0x1c4)
[<c04fedc0>] (kernel_init_freeable) from [<c03e0f04>] (kernel_init+0x8/0xf0)
[<c03e0f04>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc781ffb0 to 0xc781fff8)
ffa0:                                     00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
---[ end trace 63124893aa47fae0 ]---
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_cma_fbdev_init_with_funcs] *ERROR*
Failed to set fbdev configuration.
[drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0

I am trying to bisect but it is really painful because the kernel simply
does not compile on a lot of bisect points :(

Any hints? Eric is PL111 working for you?

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

Re: PL111 regression in v4.19-rc1

[Noralf Trønnes]

Hi Linus,

Den 27.08.2018 14.12, skrev Linus Walleij:
> Hi folks,
>
> I'm seeing this on all PL111 systems (several ARM reference
> designs and Nomadik) with v4.19-rc1:
>
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:516
> drm_gem_cma_create+0x13c/0x158
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0+ #135
> Hardware name: ARM-Versatile (Device Tree Support)
> [<c001c4e0>] (unwind_backtrace) from [<c0019198>] (show_stack+0x10/0x14)
> [<c0019198>] (show_stack) from [<c0024528>] (__warn+0xcc/0xf4)
> [<c0024528>] (__warn) from [<c0024664>] (warn_slowpath_null+0x3c/0x48)
> [<c0024664>] (warn_slowpath_null) from [<c0259710>]
> (drm_gem_cma_create+0x13c/0x158)
> [<c0259710>] (drm_gem_cma_create) from [<c0234700>]
> (drm_fbdev_cma_create+0x58/0x248)
> [<c0234700>] (drm_fbdev_cma_create) from [<c0233d3c>]
> (__drm_fb_helper_initial_config_and_unlock+0x1c8/0x450)
> [<c0233d3c>] (__drm_fb_helper_initial_config_and_unlock) from
> [<c023450c>] (drm_fb_cma_fbdev_init_with_funcs+0x8c/0x114)
> [<c023450c>] (drm_fb_cma_fbdev_init_with_funcs) from [<c025d23c>]
> (pl111_amba_probe+0x3c8/0x4a4)
> [<c025d23c>] (pl111_amba_probe) from [<c01f3c64>] (amba_probe+0xd8/0x154)
> [<c01f3c64>] (amba_probe) from [<c02637e4>] (driver_probe_device+0x25c/0x310)
> [<c02637e4>] (driver_probe_device) from [<c0263968>] (__driver_attach+0xd0/0xd4)
> [<c0263968>] (__driver_attach) from [<c0261b30>] (bus_for_each_dev+0x70/0xb4)
> [<c0261b30>] (bus_for_each_dev) from [<c0262c74>] (bus_add_driver+0x170/0x204)
> [<c0262c74>] (bus_add_driver) from [<c0264278>] (driver_register+0x74/0x108)
> [<c0264278>] (driver_register) from [<c000abf8>] (do_one_initcall+0x48/0x1a0)
> [<c000abf8>] (do_one_initcall) from [<c04fedc0>]
> (kernel_init_freeable+0x104/0x1c4)
> [<c04fedc0>] (kernel_init_freeable) from [<c03e0f04>] (kernel_init+0x8/0xf0)
> [<c03e0f04>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
> Exception stack(0xc781ffb0 to 0xc781fff8)
> ffa0:                                     00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
> ---[ end trace 63124893aa47fae0 ]---
> drm-clcd-pl111 dev:20: coherent DMA mask is unset
> drm-clcd-pl111 dev:20: [drm:drm_fb_cma_fbdev_init_with_funcs] *ERROR*
> Failed to set fbdev configuration.
> [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0
>
> I am trying to bisect but it is really painful because the kernel simply
> does not compile on a lot of bisect points :(

This is one suspect: 894a677f4b3e
drm/cma-helper: Use the generic fbdev emulation

Noralf.

> Any hints? Eric is PL111 working for you?
>
> Yours,
> Linus Walleij

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

Re: PL111 regression in v4.19-rc1

[Linus Walleij]

On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes <noralf@tronnes.org> wrote:

> This is one suspect: 894a677f4b3e
> drm/cma-helper: Use the generic fbdev emulation

This doesn't revert cleanly so I couldn't try that right off.

But the graphics do work before this commit.

I checked out the kernel tree on this commit and it just fails
to create the framebuffer with no messages whatsoever:

versatile-tft-panel 10000000.sysreg:display@0: no panel detected
drm-clcd-pl111 dev:20: set up callbacks for Versatile PL110
drm-clcd-pl111 dev:20: found bridge on endpoint 1
drm-clcd-pl111 dev:20: Using non-panel bridge
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0

I guess this somehow broke it, then some more stuff down
the road made the damage more visible.

I'm trying to see if I can fix it, any hints welcome!

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

Re: PL111 regression in v4.19-rc1

[Linus Walleij]

On Mon, Aug 27, 2018 at 2:43 PM Linus Walleij <linus.walleij@linaro.org> wrote:

> I'm trying to see if I can fix it, any hints welcome!

BTW this is pretty easy to reproduce in QEMU using a cross compilers:
I realized we were missing the VGA DAC when testing this...

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- versatile_defconfig
scripts/config --file .config --enable DRM_DUMB_VGA_DAC
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs
qemu-system-arm -M versatileab -no-reboot -kernel arch/arm/boot/zImage
-dtb arch/arm/boot/dts/versatile-ab.dtb -append "console=ttyAMA0"
-serial stdio -initrd rootfs-versatile.cpio

The initramfs/initrd is here:
https://dflund.se/~triad/krad/versatile/rootfs-versatile.cpio

I'm using this cross-compiler:
https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/

This requires a reasonably recent QEMU which I extended with the
vblank emulation a while back. (If you don't have that the machine
hangs waiting for vblank for a long time in the DRM init.)

I get graphics on v4.18 and the commit preceeding this one.
It fails on v4.19-rc1.

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

Re: PL111 regression in v4.19-rc1

[Noralf Trønnes]

Den 27.08.2018 14.43, skrev Linus Walleij:
> On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes <noralf@tronnes.org> wrote:
>
>> This is one suspect: 894a677f4b3e
>> drm/cma-helper: Use the generic fbdev emulation
> This doesn't revert cleanly so I couldn't try that right off.
>
> But the graphics do work before this commit.
>
> I checked out the kernel tree on this commit and it just fails
> to create the framebuffer with no messages whatsoever:
>
> versatile-tft-panel 10000000.sysreg:display@0: no panel detected
> drm-clcd-pl111 dev:20: set up callbacks for Versatile PL110
> drm-clcd-pl111 dev:20: found bridge on endpoint 1
> drm-clcd-pl111 dev:20: Using non-panel bridge
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0
>
> I guess this somehow broke it, then some more stuff down
> the road made the damage more visible.
>
> I'm trying to see if I can fix it, any hints welcome!

I had time to look closer at this, and I don't think the fbdev change is
to blame. I think it's just that the problem shows up there because it's
the first to allocate a buffer. If the DRM side doesn't work either, I
guess the problem lies elsewhere.

Noralf.

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

Re: PL111 regression in v4.19-rc1

[Linus Walleij]

On Mon, Aug 27, 2018 at 4:34 PM Noralf Trønnes <noralf@tronnes.org> wrote:

> I had time to look closer at this, and I don't think the fbdev change is
> to blame. I think it's just that the problem shows up there because it's
> the first to allocate a buffer. If the DRM side doesn't work either, I
> guess the problem lies elsewhere.

I think you're right.

I tested today with the TVE200 driver (which is similar in structure) and
it works just fine with the generic framebuffer refactorings.
(Good job, by the way.)

Oh well, I'll get back to bisecting. Thanks anyway!

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