Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
As of commit 47ec5303d73ea344 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git , my VMware environment cannot boot. Do I need to bisect? [9.314496][T1] vga16fb: mapped to 0x71050562 [9.467770][T1] Console: switching to colour frame buffer device 80x30 [9.632092][T1] fb0: VGA16 VGA frame buffer device [9.651768][T1] ACPI: AC Adapter [ACAD] (on-line) [9.672544][T1] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [9.722373][T1] ACPI: Power Button [PWRF] [9.744231][T1] ioatdma: Intel(R) QuickData Technology Driver 5.00 [9.820147][T1] N_HDLC line discipline registered with maxframe=4096 [9.835649][T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [9.852567][T1] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 10.033372][T1] Cyclades driver 2.6 [ 10.049928][T1] Initializing Nozomi driver 2.1d [ 10.065493][T1] RocketPort device driver module, version 2.09, 12-June-2003 [ 10.095368][T1] No rocketport ports found; unloading driver [ 10.112430][T1] Non-volatile memory driver v1.3 [ 10.127090][T1] Linux agpgart interface v0.103 [ 10.144037][T1] agpgart-intel :00:00.0: Intel 440BX Chipset [ 10.162275][T1] agpgart-intel :00:00.0: AGP aperture is 256M @ 0x0 [ 10.181130][T1] [drm] DMA map mode: Caching DMA mappings. [ 10.195150][T1] [drm] Capabilities: [ 10.208728][T1] [drm] Rect copy. [ 10.222772][T1] [drm] Cursor. [ 10.235364][T1] [drm] Cursor bypass. [ 10.249121][T1] [drm] Cursor bypass 2. [ 10.260590][T1] [drm] 8bit emulation. [ 10.272220][T1] [drm] Alpha cursor. [ 10.284670][T1] [drm] 3D. [ 10.295051][T1] [drm] Extended Fifo. [ 10.305180][T1] [drm] Multimon. [ 10.315506][T1] [drm] Pitchlock. [ 10.325167][T1] [drm] Irq mask. [ 10.334262][T1] [drm] Display Topology. [ 10.343519][T1] [drm] GMR. [ 10.352775][T1] [drm] Traces. [ 10.362166][T1] [drm] GMR2. [ 10.370716][T1] [drm] Screen Object 2. [ 10.379220][T1] [drm] Command Buffers. [ 10.388489][T1] [drm] Command Buffers 2. [ 10.396055][T1] [drm] Guest Backed Resources. [ 10.403290][T1] [drm] DX Features. [ 10.409911][T1] [drm] HP Command Queue. [ 10.417820][T1] [drm] Capabilities2: [ 10.424216][T1] [drm] Grow oTable. [ 10.430423][T1] [drm] IntraSurface copy. [ 10.436371][T1] [drm] Max GMR ids is 64 [ 10.442651][T1] [drm] Max number of GMR pages is 65536 [ 10.450317][T1] [drm] Max dedicated hypervisor surface memory is 0 kiB [ 10.458809][T1] [drm] Maximum display memory size is 262144 kiB [ 10.466330][T1] [drm] VRAM at 0xe800 size is 4096 kiB [ 10.474704][T1] [drm] MMIO at 0xfe00 size is 256 kiB [ 10.484625][T1] [TTM] Zone kernel: Available graphics memory: 4030538 KiB [ 10.500730][T1] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 10.516851][T1] [TTM] Initializing pool allocator [ 10.527542][T1] [TTM] Initializing DMA pool allocator [ 10.540197][T1] BUG: kernel NULL pointer dereference, address: 0438 [ 10.550087][T1] #PF: supervisor read access in kernel mode [ 10.550087][T1] #PF: error_code(0x) - not-present page [ 10.550087][T1] PGD 0 P4D 0 [ 10.550087][T1] Oops: [#1] PREEMPT SMP [ 10.550087][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0+ #271 [ 10.550087][T1] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 [ 10.550087][T1] RIP: 0010:drm_dev_has_vblank+0x9/0x20 [ 10.550087][T1] Code: 5d 41 5e 41 5f e9 e7 fa 01 ff e8 e2 fa 01 ff 45 31 e4 41 8b 5f 48 eb a7 cc cc cc cc cc cc cc cc cc 53 48 89 fb e8 c7 fa 01 ff <8b> 83 38 04 00 00 5b 85 c0 0f 95 c0 c3 66 2e 0f 1f 84 00 00 00 00 [ 10.550087][T1] RSP: :c9027b80 EFLAGS: 00010293 [ 10.550087][T1] RAX: RBX: RCX: [ 10.550087][T1] RDX: 88823544c040 RSI: 823265b9 RDI: [ 10.550087][T1] RBP: 888227238800 R08: 0001 R09: [ 10.550087][T1] R10: 888227238800 R11: 0001 R12: [ 10.550087][T1] R13: 888235103000 R14: R15: 888226cc6af0 [ 10.850690][T1] FS: () GS:888236e0() knlGS: [ 10.850690][T1] CS: 0010 DS: ES: CR0: 80050033 [ 10.850690][T1] CR2: 0438 CR3: 04a89001 CR4: 003706f0 [ 10.850690][T1] Call Trace: [ 10.850690][T1] __drm_atomic_helper_crtc_reset+0x28/0x50 [ 10.850690][T1] vmw_du_crtc_reset+0x62/0x80 [ 10.850690][T1]
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
On Thu, Aug 06, 2020 at 03:43:02PM +0900, Tetsuo Handa wrote: > As of commit 47ec5303d73ea344 ("Merge > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git , > my VMware environment cannot boot. Do I need to bisect? That sounds like a good idea, but please start a new thread (not reply to some random existing ones), with maintainers for drivers/gpu/drm/vmwgfx only. Not a massive list of random folks who have no idea what's going on here. From get_maintainers.pl $ scripts/get_maintainer.pl -f drivers/gpu/drm/vmwgfx/ VMware Graphics (supporter:DRM DRIVER FOR VMWARE VIRTUAL GPU) Roland Scheidegger (supporter:DRM DRIVER FOR VMWARE VIRTUAL GPU) David Airlie (maintainer:DRM DRIVERS) Daniel Vetter (maintainer:DRM DRIVERS) dri-de...@lists.freedesktop.org (open list:DRM DRIVER FOR VMWARE VIRTUAL GPU) linux-ker...@vger.kernel.org (open list) Cheers, Daniel > > [9.314496][T1] vga16fb: mapped to 0x71050562 > [9.467770][T1] Console: switching to colour frame buffer device 80x30 > [9.632092][T1] fb0: VGA16 VGA frame buffer device > [9.651768][T1] ACPI: AC Adapter [ACAD] (on-line) > [9.672544][T1] input: Power Button as > /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 > [9.722373][T1] ACPI: Power Button [PWRF] > [9.744231][T1] ioatdma: Intel(R) QuickData Technology Driver 5.00 > [9.820147][T1] N_HDLC line discipline registered with maxframe=4096 > [9.835649][T1] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [9.852567][T1] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = > 115200) is a 16550A > [ 10.033372][T1] Cyclades driver 2.6 > [ 10.049928][T1] Initializing Nozomi driver 2.1d > [ 10.065493][T1] RocketPort device driver module, version 2.09, > 12-June-2003 > [ 10.095368][T1] No rocketport ports found; unloading driver > [ 10.112430][T1] Non-volatile memory driver v1.3 > [ 10.127090][T1] Linux agpgart interface v0.103 > [ 10.144037][T1] agpgart-intel :00:00.0: Intel 440BX Chipset > [ 10.162275][T1] agpgart-intel :00:00.0: AGP aperture is 256M @ 0x0 > [ 10.181130][T1] [drm] DMA map mode: Caching DMA mappings. > [ 10.195150][T1] [drm] Capabilities: > [ 10.208728][T1] [drm] Rect copy. > [ 10.222772][T1] [drm] Cursor. > [ 10.235364][T1] [drm] Cursor bypass. > [ 10.249121][T1] [drm] Cursor bypass 2. > [ 10.260590][T1] [drm] 8bit emulation. > [ 10.272220][T1] [drm] Alpha cursor. > [ 10.284670][T1] [drm] 3D. > [ 10.295051][T1] [drm] Extended Fifo. > [ 10.305180][T1] [drm] Multimon. > [ 10.315506][T1] [drm] Pitchlock. > [ 10.325167][T1] [drm] Irq mask. > [ 10.334262][T1] [drm] Display Topology. > [ 10.343519][T1] [drm] GMR. > [ 10.352775][T1] [drm] Traces. > [ 10.362166][T1] [drm] GMR2. > [ 10.370716][T1] [drm] Screen Object 2. > [ 10.379220][T1] [drm] Command Buffers. > [ 10.388489][T1] [drm] Command Buffers 2. > [ 10.396055][T1] [drm] Guest Backed Resources. > [ 10.403290][T1] [drm] DX Features. > [ 10.409911][T1] [drm] HP Command Queue. > [ 10.417820][T1] [drm] Capabilities2: > [ 10.424216][T1] [drm] Grow oTable. > [ 10.430423][T1] [drm] IntraSurface copy. > [ 10.436371][T1] [drm] Max GMR ids is 64 > [ 10.442651][T1] [drm] Max number of GMR pages is 65536 > [ 10.450317][T1] [drm] Max dedicated hypervisor surface memory is 0 kiB > [ 10.458809][T1] [drm] Maximum display memory size is 262144 kiB > [ 10.466330][T1] [drm] VRAM at 0xe800 size is 4096 kiB > [ 10.474704][T1] [drm] MMIO at 0xfe00 size is 256 kiB > [ 10.484625][T1] [TTM] Zone kernel: Available graphics memory: 4030538 > KiB > [ 10.500730][T1] [TTM] Zone dma32: Available graphics memory: 2097152 > KiB > [ 10.516851][T1] [TTM] Initializing pool allocator > [ 10.527542][T1] [TTM] Initializing DMA pool allocator > [ 10.540197][T1] BUG: kernel NULL pointer dereference, address: > 0438 > [ 10.550087][T1] #PF: supervisor read access in kernel mode > [ 10.550087][T1] #PF: error_code(0x) - not-present page > [ 10.550087][T1] PGD 0 P4D 0 > [ 10.550087][T1] Oops: [#1] PREEMPT SMP > [ 10.550087][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0+ #271 > [ 10.550087][T1] Hardware name: VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 > [ 10.550087][T1] RIP: 0010:drm_dev_has_vblank+0x9/0x20 > [ 10.550087][T1] Code: 5d 41 5e 41 5f e9 e7 fa 01 ff e8 e2 fa 01 ff 45 > 31 e4 41 8b 5f 48 eb a7 cc cc cc cc cc cc cc cc cc 53 48 89 fb e8 c7 fa 01 ff > <8b> 83 38 04 00 00 5b 85 c0 0f 95 c0 c3 66 2e 0f 1f 84 00 00 00 00 > [ 10.550087][T1] RSP: :c9027b80 EFLAGS: 00010293 > [ 10.550087][
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
On Thu, Jul 2, 2020 at 1:27 PM Laurent Pinchart wrote: > > Hi Daniel, > > Thank you for the patch. > > On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote: > > Only when vblanks are supported ofc. > > > > Some drivers do this already, but most unfortunately missed it. This > > opens up bugs after driver load, before the crtc is enabled for the > > first time. syzbot spotted this when loading vkms as a secondary > > output. Given how many drivers are buggy it's best to solve this once > > and for all in shared helper code. > > > > Aside from moving the few existing calls to drm_crtc_vblank_reset into > > helpers (i915 doesn't use helpers, so keeps its own) I think the > > regression risk is minimal: atomic helpers already rely on drivers > > calling drm_crtc_vblank_on/off correctly in their hooks when they > > support vblanks. And driver that's failing to handle vblanks after > > this is missing those calls already, and vblanks could only work by > > accident when enabling a CRTC for the first time right after boot. > > > > Big thanks to Tetsuo for helping track down what's going wrong here. > > > > There's only a few drivers which already had the necessary call and > > needed some updating: > > - komeda, atmel and tidss also needed to be changed to call > > __drm_atomic_helper_crtc_reset() intead of open coding it > > - tegra and msm even had it in the same place already, just code > > motion, and malidp already uses __drm_atomic_helper_crtc_reset(). > > Should you mention rcar-du and omapdrm here ? Uh yes need to mention them too here, and how exactly they're a bit different. Will shuffle that from the v4: block below when applying. > > Only call left is in i915, which doesn't use drm_mode_config_reset, > > but has its own fastboot infrastructure. So that's the only case where > > we actually want this in the driver still. > > > > I've also reviewed all other drivers which set up vblank support with > > drm_vblank_init. After the previous patch fixing mxsfb all atomic > > drivers do call drm_crtc_vblank_on/off as they should, the remaining > > drivers are either legacy kms or legacy dri1 drivers, so not affected > > by this change to atomic helpers. > > > > v2: Use the drm_dev_has_vblank() helper. > > > > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off > > instead of drm_crtc_vblank_reset. Adjust them too. > > > > v4: Laurent noticed that rcar-du and omap open-code their crtc reset > > and hence would actually be broken by this patch now. So fix them up > > by reusing the helpers, which brings the drm_crtc_vblank_reset() back. > > > > Cc: Laurent Pinchart > > Reviewed-by: Boris Brezillon > > Acked-by: Liviu Dudau > > Acked-by: Thierry Reding > > Link: > > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb > > Reported-by: Tetsuo Handa > > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com > > Cc: Tetsuo Handa > > Cc: "James (Qian) Wang" > > Cc: Liviu Dudau > > Cc: Mihail Atanassov > > Cc: Brian Starkey > > Cc: Sam Ravnborg > > Cc: Boris Brezillon > > Cc: Nicolas Ferre > > Cc: Alexandre Belloni > > Cc: Ludovic Desroches > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Thierry Reding > > Cc: Jonathan Hunter > > Cc: Jyri Sarha > > Cc: Tomi Valkeinen > > Cc: Rob Clark > > Cc: Sean Paul > > Cc: Brian Masney > > Cc: Emil Velikov > > Cc: zhengbin > > Cc: Thomas Gleixner > > Cc: linux-te...@vger.kernel.org > > Cc: Kieran Bingham > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: linux-renesas-...@vger.kernel.org > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++- > > drivers/gpu/drm/arm/malidp_drv.c | 1 - > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++- > > drivers/gpu/drm/drm_atomic_state_helper.c| 4 > > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 -- > > drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +--- > > drivers/gpu/drm/omapdrm/omap_drv.c | 4 > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- > > drivers/gpu/drm/tegra/dc.c | 1 - > > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +-- > > drivers/gpu/drm/tidss/tidss_kms.c| 4 > > 11 files changed, 15 insertions(+), 32 deletions(-) > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > > index 56bd938961ee..f33418d6e1a0 100644 > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc) > > crtc->state = NULL; > > > > state = kzalloc(sizeof(*state), GFP_KERNEL); > > - if (state) { > > - crtc->state = &state->base; > > -
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
Hi Daniel, Thank you for the patch. On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms as a secondary > output. Given how many drivers are buggy it's best to solve this once > and for all in shared helper code. > > Aside from moving the few existing calls to drm_crtc_vblank_reset into > helpers (i915 doesn't use helpers, so keeps its own) I think the > regression risk is minimal: atomic helpers already rely on drivers > calling drm_crtc_vblank_on/off correctly in their hooks when they > support vblanks. And driver that's failing to handle vblanks after > this is missing those calls already, and vblanks could only work by > accident when enabling a CRTC for the first time right after boot. > > Big thanks to Tetsuo for helping track down what's going wrong here. > > There's only a few drivers which already had the necessary call and > needed some updating: > - komeda, atmel and tidss also needed to be changed to call > __drm_atomic_helper_crtc_reset() intead of open coding it > - tegra and msm even had it in the same place already, just code > motion, and malidp already uses __drm_atomic_helper_crtc_reset(). Should you mention rcar-du and omapdrm here ? > Only call left is in i915, which doesn't use drm_mode_config_reset, > but has its own fastboot infrastructure. So that's the only case where > we actually want this in the driver still. > > I've also reviewed all other drivers which set up vblank support with > drm_vblank_init. After the previous patch fixing mxsfb all atomic > drivers do call drm_crtc_vblank_on/off as they should, the remaining > drivers are either legacy kms or legacy dri1 drivers, so not affected > by this change to atomic helpers. > > v2: Use the drm_dev_has_vblank() helper. > > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off > instead of drm_crtc_vblank_reset. Adjust them too. > > v4: Laurent noticed that rcar-du and omap open-code their crtc reset > and hence would actually be broken by this patch now. So fix them up > by reusing the helpers, which brings the drm_crtc_vblank_reset() back. > > Cc: Laurent Pinchart > Reviewed-by: Boris Brezillon > Acked-by: Liviu Dudau > Acked-by: Thierry Reding > Link: > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb > Reported-by: Tetsuo Handa > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com > Cc: Tetsuo Handa > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Brian Starkey > Cc: Sam Ravnborg > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: Rob Clark > Cc: Sean Paul > Cc: Brian Masney > Cc: Emil Velikov > Cc: zhengbin > Cc: Thomas Gleixner > Cc: linux-te...@vger.kernel.org > Cc: Kieran Bingham > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++- > drivers/gpu/drm/arm/malidp_drv.c | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++- > drivers/gpu/drm/drm_atomic_state_helper.c| 4 > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 -- > drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +--- > drivers/gpu/drm/omapdrm/omap_drv.c | 4 > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- > drivers/gpu/drm/tegra/dc.c | 1 - > drivers/gpu/drm/tidss/tidss_crtc.c | 3 +-- > drivers/gpu/drm/tidss/tidss_kms.c| 4 > 11 files changed, 15 insertions(+), 32 deletions(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > index 56bd938961ee..f33418d6e1a0 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc) > crtc->state = NULL; > > state = kzalloc(sizeof(*state), GFP_KERNEL); > - if (state) { > - crtc->state = &state->base; > - crtc->state->crtc = crtc; > - } > + if (state) > + __drm_atomic_helper_crtc_reset(crtc, &state->base); > } > > static struct drm_crtc_state * > @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms, > return err; > > drm_crtc_helper_add(crtc, &komeda_crtc_helper_funcs); > - drm_crtc_vblank_reset(crtc); > > crtc->port = kcrtc->mas
Re: [Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms as a secondary > output. Given how many drivers are buggy it's best to solve this once > and for all in shared helper code. > > Aside from moving the few existing calls to drm_crtc_vblank_reset into > helpers (i915 doesn't use helpers, so keeps its own) I think the > regression risk is minimal: atomic helpers already rely on drivers > calling drm_crtc_vblank_on/off correctly in their hooks when they > support vblanks. And driver that's failing to handle vblanks after > this is missing those calls already, and vblanks could only work by > accident when enabling a CRTC for the first time right after boot. > > Big thanks to Tetsuo for helping track down what's going wrong here. > > There's only a few drivers which already had the necessary call and > needed some updating: > - komeda, atmel and tidss also needed to be changed to call > __drm_atomic_helper_crtc_reset() intead of open coding it > - tegra and msm even had it in the same place already, just code > motion, and malidp already uses __drm_atomic_helper_crtc_reset(). > > Only call left is in i915, which doesn't use drm_mode_config_reset, > but has its own fastboot infrastructure. So that's the only case where > we actually want this in the driver still. > > I've also reviewed all other drivers which set up vblank support with > drm_vblank_init. After the previous patch fixing mxsfb all atomic > drivers do call drm_crtc_vblank_on/off as they should, the remaining > drivers are either legacy kms or legacy dri1 drivers, so not affected > by this change to atomic helpers. > > v2: Use the drm_dev_has_vblank() helper. > > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off > instead of drm_crtc_vblank_reset. Adjust them too. > > v4: Laurent noticed that rcar-du and omap open-code their crtc reset > and hence would actually be broken by this patch now. So fix them up > by reusing the helpers, which brings the drm_crtc_vblank_reset() back. > > Cc: Laurent Pinchart > Reviewed-by: Boris Brezillon > Acked-by: Liviu Dudau > Acked-by: Thierry Reding > Link: > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb > Reported-by: Tetsuo Handa > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com > Cc: Tetsuo Handa > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Brian Starkey > Cc: Sam Ravnborg > Cc: Boris Brezillon > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: Ludovic Desroches > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: Rob Clark > Cc: Sean Paul > Cc: Brian Masney > Cc: Emil Velikov > Cc: zhengbin > Cc: Thomas Gleixner > Cc: linux-te...@vger.kernel.org > Cc: Kieran Bingham > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset
Only when vblanks are supported ofc. Some drivers do this already, but most unfortunately missed it. This opens up bugs after driver load, before the crtc is enabled for the first time. syzbot spotted this when loading vkms as a secondary output. Given how many drivers are buggy it's best to solve this once and for all in shared helper code. Aside from moving the few existing calls to drm_crtc_vblank_reset into helpers (i915 doesn't use helpers, so keeps its own) I think the regression risk is minimal: atomic helpers already rely on drivers calling drm_crtc_vblank_on/off correctly in their hooks when they support vblanks. And driver that's failing to handle vblanks after this is missing those calls already, and vblanks could only work by accident when enabling a CRTC for the first time right after boot. Big thanks to Tetsuo for helping track down what's going wrong here. There's only a few drivers which already had the necessary call and needed some updating: - komeda, atmel and tidss also needed to be changed to call __drm_atomic_helper_crtc_reset() intead of open coding it - tegra and msm even had it in the same place already, just code motion, and malidp already uses __drm_atomic_helper_crtc_reset(). Only call left is in i915, which doesn't use drm_mode_config_reset, but has its own fastboot infrastructure. So that's the only case where we actually want this in the driver still. I've also reviewed all other drivers which set up vblank support with drm_vblank_init. After the previous patch fixing mxsfb all atomic drivers do call drm_crtc_vblank_on/off as they should, the remaining drivers are either legacy kms or legacy dri1 drivers, so not affected by this change to atomic helpers. v2: Use the drm_dev_has_vblank() helper. v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off instead of drm_crtc_vblank_reset. Adjust them too. v4: Laurent noticed that rcar-du and omap open-code their crtc reset and hence would actually be broken by this patch now. So fix them up by reusing the helpers, which brings the drm_crtc_vblank_reset() back. Cc: Laurent Pinchart Reviewed-by: Boris Brezillon Acked-by: Liviu Dudau Acked-by: Thierry Reding Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb Reported-by: Tetsuo Handa Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com Cc: Tetsuo Handa Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov Cc: Brian Starkey Cc: Sam Ravnborg Cc: Boris Brezillon Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Thierry Reding Cc: Jonathan Hunter Cc: Jyri Sarha Cc: Tomi Valkeinen Cc: Rob Clark Cc: Sean Paul Cc: Brian Masney Cc: Emil Velikov Cc: zhengbin Cc: Thomas Gleixner Cc: linux-te...@vger.kernel.org Cc: Kieran Bingham Cc: linux-arm-ker...@lists.infradead.org Cc: linux-renesas-...@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++- drivers/gpu/drm/arm/malidp_drv.c | 1 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++- drivers/gpu/drm/drm_atomic_state_helper.c| 4 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 -- drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +--- drivers/gpu/drm/omapdrm/omap_drv.c | 4 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- drivers/gpu/drm/tegra/dc.c | 1 - drivers/gpu/drm/tidss/tidss_crtc.c | 3 +-- drivers/gpu/drm/tidss/tidss_kms.c| 4 11 files changed, 15 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 56bd938961ee..f33418d6e1a0 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc) crtc->state = NULL; state = kzalloc(sizeof(*state), GFP_KERNEL); - if (state) { - crtc->state = &state->base; - crtc->state->crtc = crtc; - } + if (state) + __drm_atomic_helper_crtc_reset(crtc, &state->base); } static struct drm_crtc_state * @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms, return err; drm_crtc_helper_add(crtc, &komeda_crtc_helper_funcs); - drm_crtc_vblank_reset(crtc); crtc->port = kcrtc->master->of_output_port; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 6feda7cb37a6..c9e1ee84b4e8 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -861,7 +861,6 @@ static int malidp_bind(struct device *dev) drm->irq_enabled = true; ret = drm_vblank_init(drm, drm->mode