Message ID | 20221025110453.9404-1-tzimmermann@suse.de |
---|---|
State | Superseded |
Headers | show |
Series | video/aperture: Call sysfb_disable() before removing PCI devices | expand |
On Tue, Oct 25, 2022 at 01:04:53PM +0200, Thomas Zimmermann wrote: > Call sysfb_disable() from aperture_remove_conflicting_pci_devices() > before removing PCI devices. Without, simpledrm can still bind to > simple-framebuffer devices after the hardware driver has taken over > the hardware. Both drivers interfere with each other and results are > undefined. > > Reported modesetting errors are shown below. > > ---- snap ---- > rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/. > rcu: blocking rcu_node structures (internal RCU debug): > Task dump for CPU 13: > task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008 > Call Trace: > <TASK> > ? commit_tail+0xd7/0x130 > ? drm_atomic_helper_commit+0x126/0x150 > ? drm_atomic_commit+0xa4/0xe0 > ? drm_plane_get_damage_clips.cold+0x1c/0x1c > ? drm_atomic_helper_dirtyfb+0x19e/0x280 > ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 > ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 > ? drm_ioctl_kernel+0xc4/0x150 > ? drm_ioctl+0x246/0x3f0 > ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 > ? __x64_sys_ioctl+0x91/0xd0 > ? do_syscall_64+0x60/0xd0 > ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 > </TASK> > ... > rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/. > rcu: blocking rcu_node structures (internal RCU debug): > Task dump for CPU 13: > task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e > Call Trace: > <TASK> > ? memcpy_toio+0x76/0xc0 > ? memcpy_toio+0x1b/0xc0 > ? drm_fb_memcpy_toio+0x76/0xb0 > ? drm_fb_blit_toio+0x75/0x2b0 > ? simpledrm_simple_display_pipe_update+0x132/0x150 > ? drm_atomic_helper_commit_planes+0xb6/0x230 > ? drm_atomic_helper_commit_tail+0x44/0x80 > ? commit_tail+0xd7/0x130 > ? drm_atomic_helper_commit+0x126/0x150 > ? drm_atomic_commit+0xa4/0xe0 > ? drm_plane_get_damage_clips.cold+0x1c/0x1c > ? drm_atomic_helper_dirtyfb+0x19e/0x280 > ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0 > ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 > ? drm_ioctl_kernel+0xc4/0x150 > ? drm_ioctl+0x246/0x3f0 > ? drm_mode_getfb2_ioctl+0x2d0/0x2d0 > ? __x64_sys_ioctl+0x91/0xd0 > ? do_syscall_64+0x60/0xd0 > ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5 > </TASK> > > The problem was added by commit 5e0137612430 ("video/aperture: Disable > and unregister sysfb devices via aperture helpers") to v6.0.3 and does > not exist in the mainline branch. Why isn't this a problem in Linus's tree? What commits there cause this to not be an issue and why can't we just take them instead? thanks, greg k-h
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index d245826a9324d..cc6427a091bc7 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/aperture.c @@ -338,6 +338,17 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na resource_size_t base, size; int bar, ret; + /* + * If a driver asked to unregister a platform device registered by + * sysfb, then can be assumed that this is a driver for a display + * that is set up by the system firmware and has a generic driver. + * + * Drivers for devices that don't have a generic driver will never + * ask for this, so let's assume that a real driver for the display + * was already probed and prevent sysfb to register devices later. + */ + sysfb_disable(); + /* * WARNING: Apparently we must kick fbdev drivers before vgacon, * otherwise the vga fbdev driver falls over.