Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

26 participants
3085 discussions

Re: DMA-BUFs always uncached on arm64, causing poor camera performance on Librem 5

by Lucas Stach

Hi Pavel, Am Donnerstag, dem 10.07.2025 um 10:24 +0200 schrieb Pavel Machek: > Hi! > > It seems that DMA-BUFs are always uncached on arm64... which is a > problem. > > I'm trying to get useful camera support on Librem 5, and that includes > recording vidos (and taking photos). > > memcpy() from normal memory is about 2msec/1MB. Unfortunately, for > DMA-BUFs it is 20msec/1MB, and that basically means I can't easily do > 760p video recording. Plus, copying full-resolution photo buffer takes > more than 200msec! > > There's possibility to do some processing on GPU, and its implemented here: > > https://gitlab.com/tui/tui/-/tree/master/icam?ref_type=heads > > but that hits the same problem in the end -- data is in DMA-BUF, > uncached, and takes way too long to copy out. > > And that's ... wrong. DMA ended seconds ago, complete cache flush > would be way cheaper than copying single frame out, and I still have > to deal with uncached frames. > > So I have two questions: > > 1) Is my analysis correct that, no matter how I get frame from v4l and > process it on GPU, I'll have to copy it from uncached memory in the > end? If you need to touch the buffers using the CPU then you are either stuck with uncached memory or you need to implement bracketed access to do the necessary cache maintenance. Be aware that completely flushing the cache is not really an option, as that would impact other workloads, so you have to flush the cache by walking the virtual address space of the buffer, which may take a significant amount of CPU time. However, if you are only going to use the buffer with the GPU I see no reason to touch it from the CPU side. Why would you even need to copy the content? After all dma-bufs are meant to enable zero-copy between DMA capable accelerators. You can simply import the V4L2 buffer into a GL texture using EGL_EXT_image_dma_buf_import. Using this path you don't need to bother with the cache at all, as the GPU will directly read the video buffers from RAM. Regards, Lucas > > 2) Does anyone have patches / ideas / roadmap how to solve that? It > makes GPU unusable for computing, and camera basically unusable for > video. > > Best regards, > Pavel

3 months, 2 weeks

Re: [PATCH 2/3] drm: tiny: Add support for Mayqueen Pixpaper e-ink panel

by kernel test robot

Hi LiangCheng, kernel test robot noticed the following build warnings: [auto build test WARNING on d7b8f8e20813f0179d8ef519541a3527e7661d3a] url: https://github.com/intel-lab-lkp/linux/commits/LiangCheng-Wang/dt-bindings-… base: d7b8f8e20813f0179d8ef519541a3527e7661d3a patch link: https://lore.kernel.org/r/20250708-drm-v1-2-45055fdadc8a%40gmail.com patch subject: [PATCH 2/3] drm: tiny: Add support for Mayqueen Pixpaper e-ink panel config: sparc-randconfig-r112-20250709 (https://download.01.org/0day-ci/archive/20250709/202507092231.FtZkMync-lkp@…) compiler: sparc64-linux-gcc (GCC) 14.3.0 reproduce: (https://download.01.org/0day-ci/archive/20250709/202507092231.FtZkMync-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202507092231.FtZkMync-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/tiny/pixpaper.c:85:10: sparse: sparse: Initializer entry defined twice drivers/gpu/drm/tiny/pixpaper.c:86:9: sparse: also defined here drivers/gpu/drm/tiny/pixpaper.c:601:10: sparse: sparse: Initializer entry defined twice drivers/gpu/drm/tiny/pixpaper.c:606:10: sparse: also defined here vim +85 drivers/gpu/drm/tiny/pixpaper.c 80 81 static const struct drm_plane_funcs pixpaper_plane_funcs = { 82 .update_plane = drm_atomic_helper_update_plane, 83 .disable_plane = drm_atomic_helper_disable_plane, 84 .destroy = drm_plane_cleanup, > 85 .reset = drm_atomic_helper_plane_reset, 86 DRM_GEM_SHADOW_PLANE_FUNCS, 87 }; 88 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

3 months, 2 weeks

[PATCH] dma_buf/sync_file: Enable signaling for fences when querying status

by Mikko Perttunen

From: Mikko Perttunen <mperttunen(a)nvidia.com> dma_fence_get_status is not guaranteed to return valid information on if the fence has been signaled or not if SW signaling has not been enabled for the fence. To ensure valid information is reported, enable SW signaling for fences before getting their status. Signed-off-by: Mikko Perttunen <mperttunen(a)nvidia.com> --- drivers/dma-buf/sync_file.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index 747e377fb95417ddd506b528618a4288bea9d459..a6fd1d14dde155561b9fd2c07e6aa20dc9863a8d 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -271,6 +271,8 @@ static int sync_fill_fence_info(struct dma_fence *fence, const char __rcu *timeline; const char __rcu *driver; + dma_fence_enable_sw_signaling(fence); + rcu_read_lock(); driver = dma_fence_driver_name(fence); @@ -320,6 +322,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, * info->num_fences. */ if (!info.num_fences) { + dma_fence_enable_sw_signaling(sync_file->fence); info.status = dma_fence_get_status(sync_file->fence); goto no_fences; } else { --- base-commit: 58ba80c4740212c29a1cf9b48f588e60a7612209 change-id: 20250708-syncfile-enable-signaling-a993acff1860

3 months, 2 weeks

Re: [PATCH 3/3] dt-bindings: display: Add Mayqueen Pixpaper e-ink panel

by Rob Herring (Arm)

On Tue, 08 Jul 2025 18:06:46 +0800, LiangCheng Wang wrote: > The binding is for the Mayqueen Pixpaper e-ink display panel, > controlled via an SPI interface. > > Signed-off-by: LiangCheng Wang <zaq14760(a)gmail.com> > --- > .../bindings/display/mayqueen,pixpaper.yaml | 63 ++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > This should be patch 2. Bindings come before users of them. Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org>

3 months, 2 weeks

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Mayqueen name

by Rob Herring (Arm)

On Tue, 08 Jul 2025 18:06:44 +0800, LiangCheng Wang wrote: > From: Wig Cheng <onlywig(a)gmail.com> > > Mayqueen is a Taiwan-based company primarily focused on the development > of arm64 development boards and e-paper displays. > > Signed-off-by: Wig Cheng <onlywig(a)gmail.com> > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring (Arm) <robh(a)kernel.org>

3 months, 2 weeks

Re: [RFC 00/12] io_uring dmabuf read/write support

by Christoph Hellwig

On Mon, Jul 07, 2025 at 04:41:23PM +0100, Pavel Begunkov wrote: > > I mean a reference the actual dma_buf (probably indirect through the file > > * for it, but listen to the dma_buf experts for that and not me). > > My expectation is that io_uring would pass struct dma_buf to the io_uring isn't the only user. We've already had one other use case coming up for pre-load of media files in mobile very recently. It's also a really good interface for P2P transfers of any kind. > file during registration, so that it can do a bunch of work upfront, > but iterators will carry sth already pre-attached and pre dma mapped, > probably in a file specific format hiding details for multi-device > support, and possibly bundled with the dma-buf pointer if necessary. > (All modulo move notify which I need to look into first). I'd expect that the exported passed around the dma_buf, and something that has access to it then imports it to the file. This could be directly forwarded to the device for the initial scrope in your series where you only support it for block device files. Now we have two variants: 1) the file instance returns a cookie for the registration that the caller has to pass into every read/write 2) the file instance tracks said cookie itself and matches it on every read/write 1) sounds faster, 2) has more sanity checking and could prevent things from going wrong. (all this is based on my limited dma_buf understanding, corrections always welcome). > > > But maybe that's fine. It's 40B -> 48B, > > > > Alternatively we could the union point to a struct that has the dma buf > > pointer and a variable length array of dma_segs. Not sure if that would > > create a mess in the callers, though. > > Iteration helpers adjust the pointer, so either it needs to store > the pointer directly in iter or keep the current index. It could rely > solely on offsets, but that'll be a mess with nested loops (where the > inner one would walk some kind of sg table). Yeah. Maybe just keep is as a separate pointer growing the structure and see if anyone screams.

3 months, 2 weeks

Re: [PATCH v3] drm/framebuffer: Acquire internal references on GEM handles

by Thomas Zimmermann

Hi Am 07.07.25 um 18:14 schrieb Satadru Pramanik: > Applying this patch to 6.16-rc5 resolves the sleep issue regression > from 6.16-rc4 I was having on my MacBookPro11,3 (Mid-2014 15" > MacBookPro), which has the NVIDIA GK107M GPU enabled via the Nouveau > driver. Thanks for testing. I think the sleep regression was just a side effect of the broken reference counting. Best regards Thomas > > Many thanks, > > Satadru > > On Mon, Jul 7, 2025 at 9:33 AM Thomas Zimmermann <tzimmermann(a)suse.de> > wrote: > > Hi > > Am 07.07.25 um 15:21 schrieb Christian König: > > >> > >> +#define DRM_FRAMEBUFFER_HAS_HANDLE_REF(_i) BIT(0u + (_i)) > > Why the "0u + (_i)" here? An macro trick? > > You mean why not just BIT(_i)? internal_flags could possibly contain > additional flags. Just using BIT(_i) would make it look as if it's > only > for those handle refs. > > Best regards > Thomas > > > > > Regards, > > Christian. > > > >> + > >> /** > >> * struct drm_framebuffer - frame buffer object > >> * > >> @@ -188,6 +191,10 @@ struct drm_framebuffer { > >> * DRM_MODE_FB_MODIFIERS. > >> */ > >> int flags; > >> + /** > >> + * @internal_flags: Framebuffer flags like > DRM_FRAMEBUFFER_HAS_HANDLE_REF. > >> + */ > >> + unsigned int internal_flags; > >> /** > >> * @filp_head: Placed on &drm_file.fbs, protected by > &drm_file.fbs_lock. > >> */ > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstrasse 146, 90461 Nuernberg, Germany > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > HRB 36809 (AG Nuernberg) > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)

3 months, 2 weeks

Re: [RFC 00/12] io_uring dmabuf read/write support

by Christoph Hellwig

On Mon, Jul 07, 2025 at 12:15:54PM +0100, Pavel Begunkov wrote: > > to attach to / detach from a dma_buf, and then have an iter that > > specifies a dmabuf and offsets into. That way the code behind the > > file operations can forward the attachment to all the needed > > devices (including more/less while it remains attached to the file) > > and can pick the right dma address for each device. > > By "iter that specifies a dmabuf" do you mean an opaque file-specific > structure allocated inside the new fop? I mean a reference the actual dma_buf (probably indirect through the file * for it, but listen to the dma_buf experts for that and not me). > Akin to what Keith proposed back > then. That sounds good and has more potential for various optimisations. > My concern would be growing struct iov_iter by an extra pointer: > struct iov_iter { > union { > struct iovec *iov; > struct dma_seg *dmav; > ... > }; > void *dma_token; > }; > > But maybe that's fine. It's 40B -> 48B, Alternatively we could the union point to a struct that has the dma buf pointer and a variable length array of dma_segs. Not sure if that would create a mess in the callers, though. > and it'll get back to > 40 when / if xarray_start / ITER_XARRAY is removed. Would it? At least for 64-bit architectures nr_segs is the same size.

3 months, 2 weeks

Re: [PATCH v4 0/3] dma-buf: heaps: Use constant name for CMA heap

by Sumit Semwal

Hello Jared, On Mon, 7 Jul 2025 at 18:40, Jared Kangas <jkangas(a)redhat.com> wrote: > > On Tue, Jun 10, 2025 at 06:12:28AM -0700, Jared Kangas wrote: > > Hi all, > > > > This patch series is based on a previous discussion around CMA heap > > naming. [1] The heap's name depends on the device name, which is > > generally "reserved", "linux,cma", or "default-pool", but could be any > > arbitrary name given to the default CMA area in the devicetree. For a > > consistent userspace interface, the series introduces a constant name > > for the CMA heap, and for backwards compatibility, an additional Kconfig > > that controls the creation of a legacy-named heap with the same CMA > > backing. > > > > The ideas to handle backwards compatibility in [1] are to either use a > > symlink or add a heap node with a duplicate minor. However, I assume > > that we don't want to create symlinks in /dev from module initcalls, and > > attempting to duplicate minors would cause device_create() to fail. > > Because of these drawbacks, after brainstorming with Maxime Ripard, I > > went with creating a new node in devtmpfs with its own minor. This > > admittedly makes it a little unclear that the old and new nodes are > > backed by the same heap when both are present. The only approach that I > > think would provide total clarity on this in userspace is symlinking, > > which seemed like a fairly involved solution for devtmpfs, but if I'm > > wrong on this, please let me know. > > > > Changelog: > > > > v4: > > - Fix ERR_PTR() usage for negative return value. > > > > v3: > > - Extract documentation markup fix to separate patch. > > - Adjust DEFAULT_CMA_NAME per discussion in [2]. > > - Warn if the legacy heap name and the default heap name are the same. > > - Fix DMABUF_HEAPS_CMA_LEGACY prompt. > > - Touch up commit log wording. > > > > v2: > > - Use tabs instead of spaces for large vertical alignment. > > > > [1]: https://lore.kernel.org/all/f6412229-4606-41ad-8c05-7bbba2eb6e08@ti.com/ > > [2]: https://lore.kernel.org/all/CANDhNCroe6ZBtN_o=c71kzFFaWK-fF5rCdnr9P5h1sgPOW… > > > > Jared Kangas (3): > > Documentation: dma-buf: heaps: Fix code markup > > dma-buf: heaps: Parameterize heap name in __add_cma_heap() > > dma-buf: heaps: Give default CMA heap a fixed name > > > > Documentation/userspace-api/dma-buf-heaps.rst | 11 +++--- > > drivers/dma-buf/heaps/Kconfig | 10 ++++++ > > drivers/dma-buf/heaps/cma_heap.c | 36 +++++++++++++++---- > > 3 files changed, 46 insertions(+), 11 deletions(-) > > > > -- > > 2.49.0 > > > > Hi Sumit, > > Just wanted to check in on this since discussion has died down this > iteration: what's the status on this series? If there's anything I can > do to help, I'm happy to lend a hand. I'm sorry, I had to be out for a bit due to some personal reasons; overall it looks good to me. I'll apply it very soon. Thank you for your patience! > > Thanks, > Jared Best, Sumit. > -- Thanks and regards, Sumit Semwal (he / him) Senior Tech Lead - Android, Platforms and Virtualisation Linaro.org │ Arm Solutions at Light Speed

3 months, 2 weeks

[PATCH v3] drm/framebuffer: Acquire internal references on GEM handles

by Thomas Zimmermann

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 <tzimmermann(a)suse.de> Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki <spasswolf(a)web.de> Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/ Tested-by: Bert Karwatzki <spasswolf(a)web.de> Tested-by: Mario Limonciello <superm1(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Anusha Srivatsa <asrivats(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> --- drivers/gpu/drm/drm_framebuffer.c | 31 ++++++++++++++-- drivers/gpu/drm/drm_gem.c | 38 ++++++++++++-------- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 ++++----- drivers/gpu/drm/drm_internal.h | 2 +- include/drm/drm_framebuffer.h | 7 ++++ 5 files changed, 68 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index b781601946db..63a70f285cce 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -862,11 +862,23 @@ EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_framebuffer_free); int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_framebuffer_funcs *funcs) { + unsigned int i; int ret; + bool exists; if (WARN_ON_ONCE(fb->dev != dev || !fb->format)) return -EINVAL; + for (i = 0; i < fb->format->num_planes; i++) { + if (drm_WARN_ON_ONCE(dev, fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i))) + fb->internal_flags &= ~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i); + if (fb->obj[i]) { + exists = drm_gem_object_handle_get_if_exists_unlocked(fb->obj[i]); + if (exists) + fb->internal_flags |= DRM_FRAMEBUFFER_HAS_HANDLE_REF(i); + } + } + INIT_LIST_HEAD(&fb->filp_head); fb->funcs = funcs; @@ -875,7 +887,7 @@ int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB, false, drm_framebuffer_free); if (ret) - goto out; + goto err; mutex_lock(&dev->mode_config.fb_lock); dev->mode_config.num_fb++; @@ -883,7 +895,16 @@ int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, mutex_unlock(&dev->mode_config.fb_lock); drm_mode_object_register(dev, &fb->base); -out: + + return 0; + +err: + for (i = 0; i < fb->format->num_planes; i++) { + if (fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) { + drm_gem_object_handle_put_unlocked(fb->obj[i]); + fb->internal_flags &= ~DRM_FRAMEBUFFER_HAS_HANDLE_REF(i); + } + } return ret; } EXPORT_SYMBOL(drm_framebuffer_init); @@ -960,6 +981,12 @@ EXPORT_SYMBOL(drm_framebuffer_unregister_private); void drm_framebuffer_cleanup(struct drm_framebuffer *fb) { struct drm_device *dev = fb->dev; + unsigned int i; + + for (i = 0; i < fb->format->num_planes; i++) { + if (fb->internal_flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) + drm_gem_object_handle_put_unlocked(fb->obj[i]); + } mutex_lock(&dev->mode_config.fb_lock); list_del(&fb->head); diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index bc505d938b3e..41cdab6088ae 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -224,23 +224,34 @@ static void drm_gem_object_handle_get(struct drm_gem_object *obj) } /** - * drm_gem_object_handle_get_unlocked - acquire reference on user-space handles + * drm_gem_object_handle_get_if_exists_unlocked - acquire reference on user-space handle, if any * @obj: GEM object * - * Acquires a reference on the GEM buffer object's handle. Required - * to keep the GEM object alive. Call drm_gem_object_handle_put_unlocked() - * to release the reference. + * Acquires a reference on the GEM buffer object's handle. Required to keep + * the GEM object alive. Call drm_gem_object_handle_put_if_exists_unlocked() + * to release the reference. Does nothing if the buffer object has no handle. + * + * Returns: + * True if a handle exists, or false otherwise */ -void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj) +bool drm_gem_object_handle_get_if_exists_unlocked(struct drm_gem_object *obj) { struct drm_device *dev = obj->dev; guard(mutex)(&dev->object_name_lock); - drm_WARN_ON(dev, !obj->handle_count); /* first ref taken in create-tail helper */ + /* + * First ref taken during GEM object creation, if any. Some + * drivers set up internal framebuffers with GEM objects that + * do not have a GEM handle. Hence, this counter can be zero. + */ + if (!obj->handle_count) + return false; + drm_gem_object_handle_get(obj); + + return true; } -EXPORT_SYMBOL(drm_gem_object_handle_get_unlocked); /** * drm_gem_object_handle_free - release resources bound to userspace handles @@ -273,7 +284,7 @@ static void drm_gem_object_exported_dma_buf_free(struct drm_gem_object *obj) } /** - * drm_gem_object_handle_put_unlocked - releases reference on user-space handles + * drm_gem_object_handle_put_unlocked - releases reference on user-space handle * @obj: GEM object * * Releases a reference on the GEM buffer object's handle. Possibly releases @@ -284,14 +295,14 @@ void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) struct drm_device *dev = obj->dev; bool final = false; - if (WARN_ON(READ_ONCE(obj->handle_count) == 0)) + if (drm_WARN_ON(dev, READ_ONCE(obj->handle_count) == 0)) return; /* - * Must bump handle count first as this may be the last - * ref, in which case the object would disappear before we - * checked for a name - */ + * Must bump handle count first as this may be the last + * ref, in which case the object would disappear before + * we checked for a name. + */ mutex_lock(&dev->object_name_lock); if (--obj->handle_count == 0) { @@ -304,7 +315,6 @@ void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) if (final) drm_gem_object_put(obj); } -EXPORT_SYMBOL(drm_gem_object_handle_put_unlocked); /* * Called at device or object close to release the file's diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index c60d0044d036..618ce725cd75 100644 --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c @@ -100,7 +100,7 @@ void drm_gem_fb_destroy(struct drm_framebuffer *fb) unsigned int i; for (i = 0; i < fb->format->num_planes; i++) - drm_gem_object_handle_put_unlocked(fb->obj[i]); + drm_gem_object_put(fb->obj[i]); drm_framebuffer_cleanup(fb); kfree(fb); @@ -183,10 +183,8 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev, if (!objs[i]) { drm_dbg_kms(dev, "Failed to lookup GEM object\n"); ret = -ENOENT; - goto err_gem_object_handle_put_unlocked; + goto err_gem_object_put; } - drm_gem_object_handle_get_unlocked(objs[i]); - drm_gem_object_put(objs[i]); min_size = (height - 1) * mode_cmd->pitches[i] + drm_format_info_min_pitch(info, i, width) @@ -196,22 +194,22 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev, drm_dbg_kms(dev, "GEM object size (%zu) smaller than minimum size (%u) for plane %d\n", objs[i]->size, min_size, i); - drm_gem_object_handle_put_unlocked(objs[i]); + drm_gem_object_put(objs[i]); ret = -EINVAL; - goto err_gem_object_handle_put_unlocked; + goto err_gem_object_put; } } ret = drm_gem_fb_init(dev, fb, mode_cmd, objs, i, funcs); if (ret) - goto err_gem_object_handle_put_unlocked; + goto err_gem_object_put; return 0; -err_gem_object_handle_put_unlocked: +err_gem_object_put: while (i > 0) { --i; - drm_gem_object_handle_put_unlocked(objs[i]); + drm_gem_object_put(objs[i]); } return ret; } diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index f921cc73f8b8..e79c3c623c9a 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -161,7 +161,7 @@ void drm_sysfs_lease_event(struct drm_device *dev); /* drm_gem.c */ int drm_gem_init(struct drm_device *dev); -void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj); +bool drm_gem_object_handle_get_if_exists_unlocked(struct drm_gem_object *obj); void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj); int drm_gem_handle_create_tail(struct drm_file *file_priv, struct drm_gem_object *obj, diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h index 668077009fce..38b24fc8978d 100644 --- a/include/drm/drm_framebuffer.h +++ b/include/drm/drm_framebuffer.h @@ -23,6 +23,7 @@ #ifndef __DRM_FRAMEBUFFER_H__ #define __DRM_FRAMEBUFFER_H__ +#include <linux/bits.h> #include <linux/ctype.h> #include <linux/list.h> #include <linux/sched.h> @@ -100,6 +101,8 @@ struct drm_framebuffer_funcs { unsigned num_clips); }; +#define DRM_FRAMEBUFFER_HAS_HANDLE_REF(_i) BIT(0u + (_i)) + /** * struct drm_framebuffer - frame buffer object * @@ -188,6 +191,10 @@ struct drm_framebuffer { * DRM_MODE_FB_MODIFIERS. */ int flags; + /** + * @internal_flags: Framebuffer flags like DRM_FRAMEBUFFER_HAS_HANDLE_REF. + */ + unsigned int internal_flags; /** * @filp_head: Placed on &drm_file.fbs, protected by &drm_file.fbs_lock. */ -- 2.50.0

3 months, 2 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig