kernel/linux.git/drivers/gpu/drm/drm_framebuffer.c, branch v6.12.80

drm/framebuffer: Acquire internal references on GEM handles

2025-07-17T16:37:12+00:00

commit f6bfc9afc7510cb5e6fbe0a17c507917b0120280 upstream. Acquire GEM handles in drm_framebuffer_init() and release them in the corresponding drm_framebuffer_cleanup(). Ties the handle's lifetime to the framebuffer. Not all GEM buffer objects have GEM handles. If not set, no refcounting takes place. This is the case for some fbdev emulation. This is not a problem as these GEM objects do not use dma-bufs and drivers will not release them while fbdev emulation is running. Framebuffer flags keep a bit per color plane of which the framebuffer holds a GEM handle reference. As all drivers use drm_framebuffer_init(), they will now all hold dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers"). In the GEM framebuffer helpers, restore the original ref counting on buffer objects. As the helpers for handle refcounting are now no longer called from outside the DRM core, unexport the symbols. v3: - don't mix internal flags with mode flags (Christian) v2: - track framebuffer handle refs by flag - drop gma500 cleanup (Christian) Signed-off-by: Thomas Zimmermann Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/ Tested-by: Bert Karwatzki Tested-by: Mario Limonciello Tested-by: Borislav Petkov (AMD) Cc: Thomas Zimmermann Cc: Anusha Srivatsa Cc: Christian König Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sumit Semwal Cc: "Christian König" Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman

drm: Warn when freeing a framebuffer that's still on a list

2023-12-23T05:31:29+00:00

Sprinkle some extra WARNs around so that we might catch premature framebuffer destruction more readily. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-2-ville.syrjala@linux.intel.com Acked-by: Javier Martinez Canillas

drm/framebuffer: Fix use of uninitialized variable

2023-12-07T07:21:43+00:00

smatch reports: drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'. 'ret' is possibly not set when there are no errors, causing the error above. I can't say if that ever happens in real-life, but in any case I think it is good to initialize 'ret' to 0. Reviewed-by: Laurent Pinchart Acked-by: Maxime Ripard Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-2-c22b2444f5f5@ideasonboard.com

drm: introduce CLOSEFB IOCTL

2023-10-27T11:47:56+00:00

This new IOCTL allows callers to close a framebuffer without disabling planes or CRTCs. This takes inspiration from Rob Clark's unref_fb IOCTL [1] and DRM_MODE_FB_PERSIST [2]. User-space patch for wlroots available at [3]. IGT test available at [4]. v2: add an extra pad field just in case we want to extend this IOCTL in the future (Pekka, Sima). [1]: https://lore.kernel.org/dri-devel/20170509153654.23464-1-robdclark@gmail.com/ [2]: https://lore.kernel.org/dri-devel/20211006151921.312714-1-contact@emersion.fr/ [3]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4394 [4]: https://lists.freedesktop.org/archives/igt-dev/2023-October/063294.html Signed-off-by: Simon Ser Reviewed-by: Daniel Stone Acked-by: Pekka Paalanen Cc: Hans de Goede Cc: Dennis Filder Cc: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20231020101926.145327-2-contact@emersion.fr

drm: extract closefb logic in separate function

2023-10-27T11:47:37+00:00

drm_mode_rmfb performs two operations: drop the FB from the file_priv->fbs list, and make sure the FB is no longer used on a plane. In the next commit an IOCTL which only does so former will be introduced, so let's split it into a separate function. No functional change, only refactoring. v2: no change Signed-off-by: Simon Ser Cc: Hans de Goede Cc: Dennis Filder Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Rob Clark Cc: Sean Paul Reviewed-by: Daniel Stone Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20231020101926.145327-1-contact@emersion.fr

drm: Replace drm_framebuffer plane size functions with its equivalents

2023-10-12T07:51:29+00:00

The functions drm_framebuffer_plane_{width,height} and fb_plane_{width,height} do exactly the same job of its equivalents drm_format_info_plane_{width,height} from drm_fourcc. The only reason to have these functions on drm_framebuffer would be if they would added a abstraction layer to call it just passing a drm_framebuffer pointer and the desired plane index, which is not the case, where these functions actually implements just part of it. In the actual implementation, every call to both drm_framebuffer_plane_{width,height} and fb_plane_{width,height} should pass some drm_framebuffer attribute, which is the same as calling the drm_format_info_plane_{width,height} functions. The drm_format_info_pane_{width,height} functions are much more consistent in both its implementation and its location on code. The kind of calculation that they do is intrinsically derivated from the drm_format_info struct and has not to do with drm_framebuffer, except by the potential motivation described above, which is still not a good justification to have drm_framebuffer functions to calculate it. So, replace each drm_framebuffer_plane_{width,height} and fb_plane_{width,height} call to drm_format_info_plane_{width,height} and remove them. Signed-off-by: Carlos Eduardo Gallo Filho Reviewed-by: André Almeida Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230926141519.9315-3-gcarlos@disroot.org

drm/debugfs: rework debugfs directory creation v5

2023-09-01T06:51:18+00:00

Instead of the per minor directories only create a single debugfs directory for the whole device directly when the device is initialized. For DRM devices each minor gets a symlink to the per device directory for now until we can be sure that this isn't useful any more in any way. Accel devices create only the per device directory and also drops the mid layer callback to create driver specific files. v2: cleanup accel component as well v3: fix typo when debugfs is disabled v4: call drm_debugfs_dev_fini() during release as well, some kerneldoc typos fixed v5: rebased and one more kerneldoc fix Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-4-christian.koenig@amd.com Reviewed-by: Andi Shyti

drm: use new debugfs device-centered functions on DRM core files

2022-12-22T17:58:21+00:00

Replace the use of drm_debugfs_create_files() with the new drm_debugfs_add_files() function in all DRM core files, centering the debugfs files management on the drm_device instead of drm_minor. Signed-off-by: Maíra Canal Reviewed-by: Maxime Ripard Reviewed-by: Melissa Wen Acked-by: Daniel Vetter Signed-off-by: Maíra Canal Link: https://patchwork.freedesktop.org/patch/msgid/20221219120621.15086-3-mcanal@igalia.com

drm/framebuffer: convert to drm_dbg_kms()

2022-09-28T08:43:30+00:00

Replace DRM_DEBUG_KMS() with drm_dbg_kms() which allows specifying the DRM device to provide more context. Signed-off-by: Simon Ser Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20220905103559.118561-1-contact@emersion.fr

drm:remove rebundant word "in" in comments

2022-07-19T07:03:24+00:00

there is a repeated word "in", so remove it. Signed-off-by: shaomin Deng Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220718150418.7321-1-dengshaomin@cdjrlc.com