On Fri, Jul 23, 2021 at 5:46 PM Simon Ser <contact@xxxxxxxxxxx> wrote: > > We already have logging for ADDFB2. Add some logging for RMFB as > well. > > This can be handy when trying to find out why a CRTC gets magically > disabled. > > Signed-off-by: Simon Ser <contact@xxxxxxxxxxx> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > --- > drivers/gpu/drm/drm_framebuffer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c > index 4d01464b6f95..da77ceeb35e3 100644 > --- a/drivers/gpu/drm/drm_framebuffer.c > +++ b/drivers/gpu/drm/drm_framebuffer.c > @@ -404,6 +404,7 @@ static void drm_mode_rmfb_work_fn(struct work_struct *w) > struct drm_framebuffer *fb = > list_first_entry(&arg->fbs, typeof(*fb), filp_head); > > + drm_dbg_kms(fb->dev, "Removing [FB:%d]\n", fb->base.id); I'd hammer more in what happens and why this happens. Maybe something like this? "Disabling [FB:¯from all active usage due to RMFB IOCTL\n" Also I wonder whether we could put some additional debug output into drm_framebuffer_remove when we either disable just the plane or the entire crtc as further clue. Like "Disabling CRTC|PLANE because FB is being removed from all active use\n" Also, because you're this great at typing docs: Kerneldoc for RMFB would be nice, but there's not even a struct to attach it to :-/ Any ideas for how to do that? -Daniel > list_del_init(&fb->filp_head); > drm_framebuffer_remove(fb); > } > -- > 2.32.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
