search for: nouveau_fbcon_destroy

...st at redhat.com> --- drm/nouveau/nouveau_fbcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nouveau_fbcon.c b/drm/nouveau/nouveau_fbcon.c index c533d8e0..be7357bf 100644 --- a/drm/nouveau/nouveau_fbcon.c +++ b/drm/nouveau/nouveau_fbcon.c @@ -429,7 +429,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) drm_fb_helper_unregister_fbi(&fbcon->helper); drm_fb_helper_fini(&fbcon->helper); - if (nouveau_fb->nvbo) { + if (nouveau_fb && nouveau_fb->nvbo) { nouveau_vma_del(&nouveau_fb->vma); nouveau_bo_unmap...

...au module on my optimus notebook machine causes the system to panic. This started occuring when moving from 4.4 to 4.14. These patches make it such that the system does not panic when unloading the module. 4.14 also requires commit 34112bf4935d ("drm/nouveau/fbcon: fix NULL pointer access in nouveau_fbcon_destroy") which was already included in the 4.18 tree. These patches make it so I can unload the module without a panic but there is a warning when unloading the module: sysfs group 'power' not found for kobject 'nv_backlight' WARNING: CPU: 2 PID: 1434 at fs/sysfs/group.c:235 sysfs_...

...ne causes > the system to panic. This started occuring when moving from 4.4 > to 4.14. > > These patches make it such that the system does not panic > when unloading the module. > > 4.14 also requires commit 34112bf4935d ("drm/nouveau/fbcon: fix NULL > pointer access in nouveau_fbcon_destroy") which was already included in > the 4.18 tree. > > These patches make it so I can unload the module without a panic but > there is a warning when unloading the module: > sysfs group 'power' not found for kobject 'nv_backlight' > WARNING: CPU: 2 PID: 1434 a...

Unpinning wasn't always handled correctly. The crtc_disable and nouveau_fbcon_destroy calls needed to unpin but didn't, resulting in a pin leak. While debugging this I found some leaks in the error paths of nouveau_user_framebuffer_create, so I fixed those too. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_disp...

...has a WARN_ON if > > framebuffers are left behind. There's a bunch of options: > > - nouveau somehow manages to keep the crtc on without a framebuffer > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > - something else > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > If I add that, the crtc gets properly disabled on unload. > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the > mode_config.fb_list. >...

...panic. This started occuring when moving from 4.4 >> to 4.14. >> >> These patches make it such that the system does not panic >> when unloading the module. >> >> 4.14 also requires commit 34112bf4935d ("drm/nouveau/fbcon: fix NULL >> pointer access in nouveau_fbcon_destroy") which was already included in >> the 4.18 tree. >> >> These patches make it so I can unload the module without a panic but >> there is a warning when unloading the module: >> sysfs group 'power' not found for kobject 'nv_backlight' >> WAR...

...ehind. There's a bunch of options: > > > > - nouveau somehow manages to keep the crtc on without a framebuffer > > > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > > > - something else > > > > > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > > > If I add that, the crtc gets properly disabled on unload. > > > > > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > > > drm_mode_config_cleanup() only WARNs if a framebuffer was lef...

On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: >> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM >> > core does not turn off the crtc first and neither do the drivers. With

...2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 85c1f10bc2b6..844498c4267c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -429,7 +429,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) nouveau_vma_del(&nouveau_fb->vma); nouveau_bo_unmap(nouveau_fb->nvbo); nouveau_bo_unpin(nouveau_fb->nvbo); - drm_framebuffer_unreference(&nouveau_fb->base); + drm_framebuffer_put(&nouveau_fb->base); } r...

..._gem_object_unreference_unlocked(chan->ntfy->gem); } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 67a1a06..f337976 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -429,6 +429,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) if (nouveau_fb->nvbo) { nouveau_bo_unmap(nouveau_fb->nvbo); nouveau_bo_vma_del(nouveau_fb->nvbo, &nouveau_fb->vma); + nouveau_bo_unpin(nouveau_fb->nvbo); drm_gem_object_unreference_unlocked(nouveau_fb->nvbo->g...

..., fb->base.height, nvbo->bo.offset, nvbo); > + fb->width, fb->height, nvbo->bo.offset, nvbo); > > vga_switcheroo_client_fb_set(dev->pdev, info); > return 0; > @@ -413,18 +413,18 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, > static int > nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) > { > - struct nouveau_framebuffer *nouveau_fb = nouveau_framebuffer(fbcon->helper.fb); > + struct drm_framebuffer *fb = fbcon->helper.fb; > struct nouveau_bo *nvbo; > > drm_fb_helper_unregister_fbi(&fbcon-&...

...dev)) - vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), info); - - return 0; - -out_unlock: - if (chan) - nouveau_vma_del(&fbcon->vma); - nouveau_bo_unmap(nvbo); -out_unpin: - nouveau_bo_unpin(nvbo); -out_unref: - nouveau_bo_ref(NULL, &nvbo); -out: - return ret; -} - -static int -nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) -{ - struct drm_framebuffer *fb = fbcon->helper.fb; - struct nouveau_bo *nvbo; - - drm_fb_helper_unregister_info(&fbcon->helper); - drm_fb_helper_fini(&fbcon->helper); - - if (fb && fb->obj[0]) { - nvbo = nouveau_gem_...

..._gem_object_unreference_unlocked(chan->ntfy->gem); } diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 67a1a06..f337976 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -429,6 +429,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) if (nouveau_fb->nvbo) { nouveau_bo_unmap(nouveau_fb->nvbo); nouveau_bo_vma_del(nouveau_fb->nvbo, &nouveau_fb->vma); + nouveau_bo_unpin(nouveau_fb->nvbo); drm_gem_object_unreference_unlocked(nouveau_fb->nvbo->g...

...if (chan) > - nouveau_vma_del(&fbcon->vma); > - nouveau_bo_unmap(nvbo); > -out_unpin: > - nouveau_bo_unpin(nvbo); > -out_unref: > - nouveau_bo_ref(NULL, &nvbo); > -out: > - return ret; > -} > - > -static int > -nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) > -{ > - struct drm_framebuffer *fb = fbcon->helper.fb; > - struct nouveau_bo *nvbo; > - > - drm_fb_helper_unregister_info(&fbcon->helper); > - drm_fb_helper_fini(&fbcon->helper); > -...

.... And drm_mode_config_cleanup has a WARN_ON if > framebuffers are left behind. There's a bunch of options: > - nouveau somehow manages to keep the crtc on without a framebuffer > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > - something else Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). If I add that, the crtc gets properly disabled on unload. It does call drm_framebuffer_cleanup(). That's why there was no WARN, drm_mode_config_cleanup() only WARNs if a framebuffer was left on the mode_config.fb_list. radeon and amdgpu have the sa...

...; framebuffers are left behind. There's a bunch of options: > > > - nouveau somehow manages to keep the crtc on without a framebuffer > > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > > - something else > > > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > > If I add that, the crtc gets properly disabled on unload. > > > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the > > m...

...ma_del(&fbcon->vma); >> - nouveau_bo_unmap(nvbo); >> -out_unpin: >> - nouveau_bo_unpin(nvbo); >> -out_unref: >> - nouveau_bo_ref(NULL, &nvbo); >> -out: >> - return ret; >> -} >> - >> -static int >> -nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon) >> -{ >> - struct drm_framebuffer *fb = fbcon->helper.fb; >> - struct nouveau_bo *nvbo; >> - >> - drm_fb_helper_unregister_info(&fbcon->helper); >> - drm_fb_helper_fini(&fb...

...gt; +??????? fb->width, fb->height, nvbo->bo.offset, nvbo); >>> ? ????? vga_switcheroo_client_fb_set(dev->pdev, info); >>> ????? return 0; >>> @@ -413,18 +413,18 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, >>> ? static int >>> ? nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev >>> *fbcon) >>> ? { >>> -??? struct nouveau_framebuffer *nouveau_fb = >>> nouveau_framebuffer(fbcon->helper.fb); >>> +??? struct drm_framebuffer *fb = fbcon->helper.fb; >>> ????? struct nouvea...

...er_funcs); > > ret = drm_fb_helper_init(dev, &fbcon->helper, > @@ -571,6 +607,8 @@ nouveau_fbcon_fini(struct drm_device *dev) > if (!drm->fbcon) > return; > > + flush_work(&drm->fbdev_suspend_work); > + > nouveau_fbcon_accel_fini(dev); > nouveau_fbcon_destroy(dev, drm->fbcon); > kfree(drm->fbcon); > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.h b/drivers/gpu/drm/nouveau/nouveau_fbcon.h > index ca77ad0..34b2504 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.h > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.h > @@ -66,...

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct