- Linaro-mm-sig - lists.linaro.org

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>

5 months, 1 week

1
0
0 0

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>

5 months, 1 week

1
0
0 0

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.

5 months, 1 week

1
0
0 0

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)

5 months, 1 week

1
0
0 0

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.

5 months, 1 week

1
0
0 0

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

5 months, 1 week

1
0
0 0

[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

5 months, 1 week

2
2
0 0

[PATCH v2] 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. 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 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- include/drm/drm_framebuffer.h | 9 +++++ 6 files changed, 71 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index b781601946db..23b56cde21d7 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->flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i))) + fb->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->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->flags & DRM_FRAMEBUFFER_HAS_HANDLE_REF(i)) { + drm_gem_object_handle_put_unlocked(fb->obj[i]); + fb->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->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/drivers/gpu/drm/drm_modeset_helper.c b/drivers/gpu/drm/drm_modeset_helper.c index ef32f6af10d4..1e8822c4b370 100644 --- a/drivers/gpu/drm/drm_modeset_helper.c +++ b/drivers/gpu/drm/drm_modeset_helper.c @@ -94,7 +94,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev, fb->offsets[i] = mode_cmd->offsets[i]; } fb->modifier = mode_cmd->modifier[0]; - fb->flags = mode_cmd->flags; + fb->flags = mode_cmd->flags & DRM_FRAMEBUFFER_FLAGS_UAPI_MASK; } EXPORT_SYMBOL(drm_helper_mode_fill_fb_struct); diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h index 668077009fce..11fa20d21c58 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,14 @@ struct drm_framebuffer_funcs { unsigned num_clips); }; +#define __DRM_FRAMEBUFFER_FLAGS_BIT_OFFSET 16 + +#define DRM_FRAMEBUFFER_FLAGS_UAPI_MASK \ + GENMASK(__DRM_FRAMEBUFFER_FLAGS_BIT_OFFSET - 1, 0) + +#define DRM_FRAMEBUFFER_HAS_HANDLE_REF(_i) \ + BIT((__DRM_FRAMEBUFFER_FLAGS_BIT_OFFSET + (_i))) + /** * struct drm_framebuffer - frame buffer object * -- 2.50.0

5 months, 1 week

2
2
0 0

Re: [PATCH v2 08/13] media: platform: mediatek: add isp_7x camsys unit

by Krzysztof Kozlowski

On 07/07/2025 03:31, shangyao lin wrote: > +static int mtk_cam_create_links(struct mtk_cam_device *cam) > +{ > + struct v4l2_subdev *sd; > + int ret = 0; > + > + v4l2_device_for_each_subdev(sd, &cam->v4l2_dev) { > + if (sd->entity.function == MEDIA_ENT_F_VID_IF_BRIDGE) > + ret = config_bridge_pad_links(cam, sd); > + } > + > + return ret; > +} > + > +static int mtk_cam_master_register(struct device *dev) > +{ > + struct mtk_cam_device *cam_dev = dev_get_drvdata(dev); > + struct media_device *media_dev = &cam_dev->media_dev; > + int ret; > + > + dev_info(dev, "camsys | start %s\n", __func__); NAK, nothing improved, you already got comments on that. Provide detailed changelog next time. And respond to EACH comment acknowledging that you understood it. This code still has so many trivial issues and terrible coding style, including wrong indentation, wrong alignment/wrapping. > + > + media_dev->dev = cam_dev->dev; > + strscpy(media_dev->model, dev_driver_string(dev), > + sizeof(media_dev->model)); > + snprintf(media_dev->bus_info, sizeof(media_dev->bus_info), > + "platform:%s", dev_name(dev)); > + media_dev->hw_revision = 0; > + media_dev->ops = &mtk_cam_dev_ops; > + media_device_init(media_dev); > + > + cam_dev->v4l2_dev.mdev = media_dev; > + ret = v4l2_device_register(cam_dev->dev, &cam_dev->v4l2_dev); > + if (ret) { > + dev_dbg(dev, "Failed to register V4L2 device: %d\n", ret); > + goto fail_media_device_cleanup; > + } > + > + ret = media_device_register(media_dev); > + if (ret) { > + dev_dbg(dev, "Failed to register media device: %d\n", > + ret); > + goto fail_v4l2_device_unreg; > + } > + > + dev_info(dev, "%s success\n", __func__); > + return 0; > + > +fail_v4l2_device_unreg: > + v4l2_device_unregister(&cam_dev->v4l2_dev); > + > +fail_media_device_cleanup: > + media_device_cleanup(&cam_dev->media_dev); > + > + return ret; > +} > + > +static void mtk_cam_master_unregister(struct device *dev) > +{ > + struct mtk_cam_device *cam_dev = dev_get_drvdata(dev); > + > + dev_info(dev, "camsys | start %s\n", __func__); NAK > + > + media_device_unregister(&cam_dev->media_dev); > + v4l2_device_unregister(&cam_dev->v4l2_dev); > + media_device_cleanup(&cam_dev->media_dev); > +} > + > +static int mtk_cam_async_add_by_driver(struct device *dev, > + struct platform_driver *drv, > + struct v4l2_async_notifier *notifier) > +{ > + struct fwnode_handle *fwnode; > + struct device *p; > + struct v4l2_async_connection *asc; > + int dev_num = 0; > + > + p = platform_find_device_by_driver(NULL, &drv->driver); > + while (p) { > + dev_info(dev, "camsys | %s add %s\n", __func__, p->kobj.name); > + > + fwnode = dev_fwnode(p); > + asc = v4l2_async_nf_add_fwnode(notifier, fwnode, > + struct v4l2_async_connection); > + put_device(p); > + ... > + > + cam_dev->base = devm_ioremap_resource(dev, res); > + if (IS_ERR(cam_dev->base)) { > + dev_err(dev, "failed to map register base\n"); > + return PTR_ERR(cam_dev->base); > + } > + > + cam_dev->dev = dev; > + dev_set_drvdata(dev, cam_dev); > + > + cam_dev->composer_cnt = 0; > + cam_dev->num_seninf_devices = 0; > + > + cam_dev->max_stream_num = MTKCAM_SUBDEV_MAX; > + cam_dev->ctxs = devm_kcalloc(dev, cam_dev->max_stream_num, > + sizeof(*cam_dev->ctxs), GFP_KERNEL); > + if (!cam_dev->ctxs) > + return -ENOMEM; > + > + cam_dev->streaming_ctx = 0; > + for (i = 0; i < cam_dev->max_stream_num; i++) > + mtk_cam_ctx_init(cam_dev->ctxs + i, cam_dev, i); > + > + cam_dev->running_job_count = 0; > + spin_lock_init(&cam_dev->pending_job_lock); > + spin_lock_init(&cam_dev->running_job_lock); > + INIT_LIST_HEAD(&cam_dev->pending_job_list); > + INIT_LIST_HEAD(&cam_dev->running_job_list); > + > + cam_dev->dma_processing_count = 0; > + spin_lock_init(&cam_dev->dma_pending_lock); > + spin_lock_init(&cam_dev->dma_processing_lock); > + INIT_LIST_HEAD(&cam_dev->dma_pending); > + INIT_LIST_HEAD(&cam_dev->dma_processing); > + > + mutex_init(&cam_dev->queue_lock); > + > + pm_runtime_enable(dev); > + > + ret = mtk_cam_of_rproc(cam_dev, pdev); > + if (ret) > + goto fail_destroy_mutex; > + > + ret = register_sub_drivers(dev); > + if (ret) { > + dev_err(dev, "fail to register_sub_drivers\n"); > + goto fail_destroy_mutex; > + } > + > + cam_dev->clks_pdev = platform_device_register_data( > + dev, "clk-mt8188-cam", PLATFORM_DEVID_AUTO, NULL, 0); > + if (IS_ERR(cam_dev->clks_pdev)) { > + ret = PTR_ERR(cam_dev->clks_pdev); > + dev_err(dev, "Failed to register cam clk device: %d\n", ret); > + goto fail_unregister_sub_drivers; > + } > + > + /* register mtk_cam as all isp subdev async parent */ > + cam_dev->notifier.ops = &mtk_cam_async_nf_ops; > + v4l2_async_nf_init(&cam_dev->notifier, &cam_dev->v4l2_dev); > + ret = mtk_cam_async_subdev_add(dev); /* wait all isp sub drivers */ > + if (ret) { > + dev_err(dev, "%s failed mtk_cam_async_subdev_add\n", __func__); > + goto fail_unregister_clks; > + } > + > + ret = v4l2_async_nf_register(&cam_dev->notifier); > + if (ret) { > + dev_err(dev, "%s async_nf_register ret:%d\n", __func__, ret); > + v4l2_async_nf_cleanup(&cam_dev->notifier); > + goto fail_unregister_clks; > + } > + > + dev_info(dev, "camsys | [%s] success\n", __func__); You already got comments. Nothing improved here. > + > + return 0; > + > +fail_unregister_clks: > + if (cam_dev->clks_pdev) > + platform_device_unregister(cam_dev->clks_pdev); > + Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 00/13] Add MediaTek ISP7.x camera system support

by Krzysztof Kozlowski

On 07/07/2025 03:31, shangyao lin wrote: > Based on linux-next tag: next-20250630 > > This patch set adds the MediaTek ISP7.x camera system hardware driver. > > The driver sets up ISP hardware, handles interrupts, and initializes > V4L2 device nodes and functions. It also implements a V4L2 standard video > driver utilizing the media framework APIs, connects sensors and the ISP > via the seninf interface, and communicates with the SCP co-processor to > compose ISP registers in firmware. > Now I found v1. How did you address comment about compliance report? Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 05/13] media: platform: mediatek: add isp_7x seninf unit

by Krzysztof Kozlowski

On Mon, Jul 07, 2025 at 09:31:46AM +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> My most frequent comment last year to Mediatek. I even asked to come with some internal procedure so you will not keep repating the same mistake in author's name. Any success? > > Introduce support for the MediaTek sensor interface (seninf) in the SoC camera ... > > --- > > Note: > The PHY operations have been refactored and separated from the seninf driver, > but there are still some issues to confirm with reviewers in this v2 patch > (dt-bindings: media: mediatek: add seninf-core binding). The PHY part will be > moved to drivers/phy/mediatek/ in v3. > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> and here the same. Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 03/13] dt-bindings: media: mediatek: add cam-raw binding

by Krzysztof Kozlowski

On Mon, Jul 07, 2025 at 09:31:44AM +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-cam-raw.yaml > - Various fixes per review comments Which fixes? This is way too vague, considering how buggy and poor this code is. Where was v1 of this? Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 04/13] dt-bindings: media: mediatek: add cam-yuv binding

by Krzysztof Kozlowski

On Mon, Jul 07, 2025 at 09:31:45AM +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-cam-yuv.yaml > - Various fixes per review comments > - Update maintainers list Where did you post v1? Please use standard email subjects, so with the PATCH keyword in the title. 'git format-patch -vX' helps here to create proper versioned patches. Another useful tool is b4. Skipping the PATCH keyword makes filtering of emails more difficult thus making the review process less convenient. A nit, subject: drop second/last, redundant "bindings". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/b… > +properties: > + compatible: > + const: mediatek,mt8188-cam-yuv > + > + reg: > + minItems: 1 What, why? Look at other bindings. > + maxItems: 2 > + description: > + Base address and optional inner base address of the cam-yuv hardware block. Why are you stating obvious? From where did you take it? > + > + reg-names: > + items: > + - const: base > + - const: inner_base > + minItems: 1 > + maxItems: 2 No, really no. You did not follow any existing patterns and this binding does not look at all as anything else. Why making this things up? Just use recently reviewed binding as starting point. Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 02/13] dt-bindings: media: mediatek: add seninf-core binding

by Krzysztof Kozlowski

On Mon, Jul 07, 2025 at 09:31:43AM +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > 1. Add camera isp7x module device document > Still no SoB, still not tested, still no checkpatch... and also: ... > + > +... > \ No newline at end of file Look, you have patch warnings. Review your patches before you post them. You should reach internally to mediatek colleagues to explain you how this process works. I really do not understand why mediatek has so poor quality of work and cannot improve over last 1-2 years! > -- > 2.18.0 >

5 months, 1 week

1
0
0 0

Re: [PATCH v2 01/13] dt-bindings: media: mediatek: add camisp binding

by Krzysztof Kozlowski

On Mon, Jul 07, 2025 at 09:31:42AM +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. Missing SoB, missing checkpatch. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-camisp.yaml > - Split bindings into four separate patches (one per YAML file) > - Various fixes per review comments > - Update maintainers list > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> Apply this patch and see by yourself. This wasn't tested either, so I will skip review. Best regards, Krzysztof

5 months, 1 week

1
0
0 0

Re: [PATCH v2 04/13] dt-bindings: media: mediatek: add cam-yuv binding

by Rob Herring (Arm)

On Mon, 07 Jul 2025 09:31:45 +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-cam-yuv.yaml > - Various fixes per review comments > - Update maintainers list > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> > --- > .../mediatek/mediatek,mt8188-cam-yuv.yaml | 134 ++++++++++++++++++ > 1 file changed, 134 insertions(+) > create mode 100755 Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.yaml: properties:reg-names: {'items': [{'const': 'base'}, {'const': 'inner_base'}], 'minItems': 1, 'maxItems': 2, 'description': 'Names for each register region. Must be "base" and optionally "inner_base".'} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.yaml: properties:clock-names: {'items': [{'const': 'camsys_cam2mm0_cgpdn'}, {'const': 'camsys_cam2mm1_cgpdn'}, {'const': 'camsys_cam2sys_cgpdn'}, {'const': 'camsys_yuva_larbx'}, {'const': 'camsys_yuva_cam_cgpdn'}, {'const': 'camsys_yuva_camtg_cgpdn'}, {'const': 'camsys_yuvb_larbx_cgpdn'}, {'const': 'camsys_yuvb_cam_cgpdn'}, {'const': 'camsys_yuvb_camtg_cgpdn'}], 'minItems': 4, 'maxItems': 16, 'description': 'Names of the clocks, must match the order of the clocks property.'} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-yuv.yaml file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.yaml Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dts:33.13-43: Warning (reg_format): /example-0/soc/yuv@16050000:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dts:37.13-59: Warning (dma_ranges_format): /example-0/soc/yuv@16050000:dma-ranges: "dma-ranges" property has invalid length (24 bytes) (parent #address-cells == 2, child #address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dts:31.24-58.13: Warning (avoid_default_addr_size): /example-0/soc/yuv@16050000: Relying on default #address-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dts:31.24-58.13: Warning (avoid_default_addr_size): /example-0/soc/yuv@16050000: Relying on default #size-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: yuv@16050000 (mediatek,mt8188-cam-yuv): clock-names:3: 'camsys_yuva_larbx' was expected from schema $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-yuv.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-yuv.example.dtb: yuv@16050000 (mediatek,mt8188-cam-yuv): dma-ranges: [[2], [0], [0], [1073741824], [1], [0]] is too long from schema $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-yuv.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202507070131… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

5 months, 1 week

1
0
0 0

Re: [PATCH v2 03/13] dt-bindings: media: mediatek: add cam-raw binding

by Rob Herring (Arm)

On Mon, 07 Jul 2025 09:31:44 +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-cam-raw.yaml > - Various fixes per review comments > - Update maintainers list > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> > --- > .../mediatek/mediatek,mt8188-cam-raw.yaml | 156 ++++++++++++++++++ > 1 file changed, 156 insertions(+) > create mode 100755 Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml:156:4: [error] no new line character at the end of file (new-line-at-end-of-file) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml: properties:clock-names: {'items': [{'const': 'camsys_cam2mm0_cgpdn'}, {'const': 'camsys_cam2mm1_cgpdn'}, {'const': 'camsys_cam2sys_cgpdn'}, {'const': 'camsys_cam_cgpdn'}, {'const': 'camsys_camtg_cgpdn'}, {'const': 'camsys_rawa_larbx_cgpdn'}, {'const': 'camsys_rawa_cam_cgpdn'}, {'const': 'camsys_rawa_camtg_cgpdn'}, {'const': 'topckgen_top_cam'}, {'const': 'topckgen_top_camtg'}, {'const': 'topckgen_top_camtm'}], 'minItems': 4, 'maxItems': 16, 'description': 'Names of the clocks, must match the order of the clocks property.'} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml: properties:reg-names: {'items': [{'const': 'base'}, {'const': 'inner_base'}], 'minItems': 1, 'maxItems': 2, 'description': 'Names for each register region. Must be "base" and optionally "inner_base".'} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-raw.yaml file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.yaml Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dts:33.13-34.43: Warning (reg_format): /example-0/soc/raw@16030000:reg: property has invalid length (32 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dts:37.13-59: Warning (dma_ranges_format): /example-0/soc/raw@16030000:dma-ranges: "dma-ranges" property has invalid length (24 bytes) (parent #address-cells == 2, child #address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dts:31.24-78.13: Warning (avoid_default_addr_size): /example-0/soc/raw@16030000: Relying on default #address-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dts:31.24-78.13: Warning (avoid_default_addr_size): /example-0/soc/raw@16030000: Relying on default #size-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: raw@16030000 (mediatek,mt8188-cam-raw): dma-ranges: [[2], [0], [0], [1073741824], [1], [0]] is too long from schema $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-raw.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-cam-raw.example.dtb: raw@16030000 (mediatek,mt8188-cam-raw): reg: [[0, 369295360], [0, 32768], [0, 369328128], [0, 32768]] is too long from schema $id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-raw.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202507070131… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

5 months, 1 week

1
0
0 0

Re: [PATCH v2 02/13] dt-bindings: media: mediatek: add seninf-core binding

by Rob Herring (Arm)

On Mon, 07 Jul 2025 09:31:43 +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > 1. Add camera isp7x module device document > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-seninf-core.yaml > - Various fixes per review comments > - Update maintainers list > > Question for reviewer (CK): > > Hi CK, > > Thank you for your review and suggestions on this patch, especially for providing the reference patch (https://patchwork.kernel.org/project/linux-mediatek/list/?series=874617) and for mentioning in another patch ([V1,02/10] MEDIA: PLATFORM: MEDIATEK: ADD SENINF CONTROLLER) the suggestion to "Move the phy part to phy/mediatek/ folder. You could refer to phy/mediatek/phy-mtk-mipi-csi-0-5.c". > > After reading your comments and the reference patches, my understanding is that only the seninf-core driver should manage all ports internally, and each port corresponds to a PHY. During probe, the driver will parse each port, obtain the corresponding PHY (e.g., devm_phy_get(dev, "csi0"), devm_phy_get(dev, "csi1"), etc.), and operate the PHY for each port individually during stream on/off or power on/off. > > Could you please confirm if my understanding is correct? > If you have any additional reference patches or examples, I would greatly appreciate it. > > Thank you for your guidance! > > Best regards, > Shangyao > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> > --- > .../mediatek/mediatek,mt8188-seninf-core.yaml | 121 ++++++++++++++++++ > 1 file changed, 121 insertions(+) > create mode 100755 Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml:6:10: [error] string value is redundantly quoted with any quotes (quoted-strings) ./Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml:121:4: [error] no new line character at the end of file (new-line-at-end-of-file) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: properties:clock-names: {'items': [{'const': 'clk_cam_seninf'}, {'const': 'clk_top_seninf'}, {'const': 'clk_top_seninf1'}, {'const': 'clk_top_camtm'}], 'minItems': 4, 'maxItems': 4} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: properties:clock-names: 'oneOf' conditional failed, one must be fixed: [{'const': 'clk_cam_seninf'}, {'const': 'clk_top_seninf'}, {'const': 'clk_top_seninf1'}, {'const': 'clk_top_camtm'}] is too long [{'const': 'clk_cam_seninf'}, {'const': 'clk_top_seninf'}, {'const': 'clk_top_seninf1'}, {'const': 'clk_top_camtm'}] is too short False schema does not allow 4 1 was expected 4 is greater than the maximum of 2 4 is greater than the maximum of 3 hint: "minItems" is only needed if less than the "items" list length from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: properties:reg-names: {'items': [{'const': 'base'}], 'minItems': 1, 'maxItems': 1} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: properties:reg-names: 'oneOf' conditional failed, one must be fixed: [{'const': 'base'}] is too short False schema does not allow 1 hint: "minItems" is only needed if less than the "items" list length from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: properties:reg: 'anyOf' conditional failed, one must be fixed: 'minItems' is not one of ['maxItems', 'description', 'deprecated'] hint: Only "maxItems" is required for a single entry if there are no constraints defined for the values. 'minItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 'maxItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 1 is less than the minimum of 2 hint: Arrays must be described with a combination of minItems/maxItems/items hint: cell array properties must define how many entries and what the entries are when there is more than one entry. from schema $id: http://devicetree.org/meta-schemas/core.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename $id: http://devicetree.org/schemas/media/mediatek,seninf-core.yaml file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-seninf-core.example.dtb: seninf@16010000 (mediatek,mt8188-seninf-core): reg: [[0, 369164288], [0, 32768]] is too long from schema $id: http://devicetree.org/schemas/media/mediatek,seninf-core.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202507070131… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

5 months, 1 week

1
0
0 0

Re: [PATCH v2 01/13] dt-bindings: media: mediatek: add camisp binding

by Rob Herring (Arm)

On Mon, 07 Jul 2025 09:31:42 +0800, shangyao lin wrote: > From: "shangyao.lin" <shangyao.lin(a)mediatek.com> > > Add camera isp7x module device document. > > --- > > Changes in v2: > - Rename binding file to mediatek,mt8188-camisp.yaml > - Split bindings into four separate patches (one per YAML file) > - Various fixes per review comments > - Update maintainers list > > Signed-off-by: shangyao.lin <shangyao.lin(a)mediatek.com> > --- > .../mediatek/mediatek,mt8188-camisp.yaml | 68 +++++++++++++++++++ > 1 file changed, 68 insertions(+) > create mode 100755 Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml:68:4: [error] no new line character at the end of file (new-line-at-end-of-file) dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml: properties:reg-names: {'items': [{'const': 'base'}], 'minItems': 1, 'maxItems': 1, 'description': 'Name for the register region. Must be "base".'} should not be valid under {'required': ['maxItems']} hint: "maxItems" is not needed with an "items" list from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml: properties:reg-names: 'oneOf' conditional failed, one must be fixed: [{'const': 'base'}] is too short False schema does not allow 1 hint: "minItems" is only needed if less than the "items" list length from schema $id: http://devicetree.org/meta-schemas/items.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml: properties:reg: 'anyOf' conditional failed, one must be fixed: 'minItems' is not one of ['maxItems', 'description', 'deprecated'] hint: Only "maxItems" is required for a single entry if there are no constraints defined for the values. 'minItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 'maxItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 1 is less than the minimum of 2 hint: Arrays must be described with a combination of minItems/maxItems/items hint: cell array properties must define how many entries and what the entries are when there is more than one entry. from schema $id: http://devicetree.org/meta-schemas/core.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml: properties:power-domains: 'anyOf' conditional failed, one must be fixed: 'minItems' is not one of ['maxItems', 'description', 'deprecated'] hint: Only "maxItems" is required for a single entry if there are no constraints defined for the values. 'minItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 'maxItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] 1 is less than the minimum of 2 hint: Arrays must be described with a combination of minItems/maxItems/items hint: cell array properties must define how many entries and what the entries are when there is more than one entry. from schema $id: http://devicetree.org/meta-schemas/power-domain.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename $id: http://devicetree.org/schemas/media/mediatek/mediatek,camisp.yaml file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.yaml Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dts:23.13-43: Warning (reg_format): /example-0/soc/isp@16000000:reg: property has invalid length (16 bytes) (#address-cells == 2, #size-cells == 1) Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dts:21.24-27.13: Warning (avoid_default_addr_size): /example-0/soc/isp@16000000: Relying on default #address-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dts:21.24-27.13: Warning (avoid_default_addr_size): /example-0/soc/isp@16000000: Relying on default #size-cells value Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/mediatek/mediatek,mt8188-camisp.example.dtb: isp@16000000 (mediatek,mt8188-camisp): reg: [[0, 369098752], [0, 4096]] is too long from schema $id: http://devicetree.org/schemas/media/mediatek/mediatek,camisp.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202507070131… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

5 months, 1 week

1
0
0 0

Re: [PATCH] virtio: Add missing kerneldoc for virtio_dma_buf_attach

by Krzysztof Kozlowski

On 04/07/2025 09:20, jiang.peng9(a)zte.com.cn wrote: > From: Peng Jiang <jiang.peng9(a)zte.com.cn> > > Add kerneldoc for 'virtio_dma_buf_attach' function to fix W=1 warnings: > > drivers/virtio/virtio_dma_buf.c:41 function parameter 'dma_buf' not described in 'virtio_dma_buf_attach' > drivers/virtio/virtio_dma_buf.c:41 function parameter 'attach' not described in 'virtio_dma_buf_attach' > > Signed-off-by: Peng Jiang <jiang.peng9(a)zte.com.cn> > --- > drivers/virtio/virtio_dma_buf.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_dma_buf.c b/drivers/virtio/virtio_dma_buf.c > index 3fe1d03b0645..18d261ba5197 100644 > --- a/drivers/virtio/virtio_dma_buf.c > +++ b/drivers/virtio/virtio_dma_buf.c > @@ -35,7 +35,16 @@ struct dma_buf *virtio_dma_buf_export > EXPORT_SYMBOL(virtio_dma_buf_export); > > /** > - * virtio_dma_buf_attach - mandatory attach callback for virtio dma-bufs > + * virtio_dma_buf_attach - Mandatory attach callback for virtio dma-bufs Read kernel-doc.rst. Missing () > + * @dma_buf: Pointer to the shared dma-buf structure > + * @attach: Pointer to the newly created attachment metadata > + * > + * Description: Implements the standard dma-buf attach operation for virtio devices. That's not kerneldoc. Which part of kernel-doc document documents such syntax? > + * Retrieves virtio-specific operations through container_of macro, > + * then invokes device-specific attach callback if present. Best regards, Krzysztof

5 months, 1 week

1
0
0 0

[PATCH] 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. 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. Gma500 (unnecessarily) clears the framebuffer's GEM-object pointer before calling drm_framebuffer_cleanup(). Remove these lines to make it consistent with the rest of the drivers. It's one of the fbdev emulations with no GEM handle on their buffers. The change to gma500 is therefore rather cosmetic. Tested on i915, amdgpu (by Bert) and gma500. Also tested on i915 plus udl for the original problem with dma-buf sharing. 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> 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 | 23 +++++++- drivers/gpu/drm/drm_gem.c | 59 +++++++++++++------- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +++--- drivers/gpu/drm/drm_internal.h | 4 +- drivers/gpu/drm/gma500/fbdev.c | 2 - 5 files changed, 69 insertions(+), 35 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index b781601946db..e4a10dd053fc 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -862,11 +862,17 @@ 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; if (WARN_ON_ONCE(fb->dev != dev || !fb->format)) return -EINVAL; + for (i = 0; i < fb->format->num_planes; i++) { + if (fb->obj[i]) + drm_gem_object_handle_get_if_exists_unlocked(fb->obj[i]); + } + INIT_LIST_HEAD(&fb->filp_head); fb->funcs = funcs; @@ -875,7 +881,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 +889,14 @@ 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->obj[i]) + drm_gem_object_handle_put_if_exists_unlocked(fb->obj[i]); + } return ret; } EXPORT_SYMBOL(drm_framebuffer_init); @@ -960,6 +973,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->obj[i]) + drm_gem_object_handle_put_if_exists_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..9d8b9e6b7d25 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -224,23 +224,27 @@ 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. */ -void drm_gem_object_handle_get_unlocked(struct drm_gem_object *obj) +void 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 */ - drm_gem_object_handle_get(obj); + /* + * 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) + drm_gem_object_handle_get(obj); } -EXPORT_SYMBOL(drm_gem_object_handle_get_unlocked); /** * drm_gem_object_handle_free - release resources bound to userspace handles @@ -272,21 +276,11 @@ 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 - * @obj: GEM object - * - * Releases a reference on the GEM buffer object's handle. Possibly releases - * the GEM buffer object and associated dma-buf objects. - */ -void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) +static void drm_gem_object_handle_put_unlocked_tail(struct drm_gem_object *obj) { struct drm_device *dev = obj->dev; bool final = false; - if (WARN_ON(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 @@ -304,7 +298,32 @@ 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); + +static void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj) +{ + struct drm_device *dev = obj->dev; + + if (drm_WARN_ON(dev, READ_ONCE(obj->handle_count) == 0)) + return; + + drm_gem_object_handle_put_unlocked_tail(obj); +} + +/** + * drm_gem_object_handle_put_if_exists_unlocked - releases reference on user-space handle, if any + * @obj: GEM object + * + * Releases a reference on the GEM buffer object's handle. Possibly releases + * the GEM buffer object and associated dma-buf objects. Does nothing if the + * buffer object has no handle. + */ +void drm_gem_object_handle_put_if_exists_unlocked(struct drm_gem_object *obj) +{ + if (!obj->handle_count) + return; + + drm_gem_object_handle_put_unlocked_tail(obj); +} /* * 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 f7b414a813ae..9233019f54a8 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -161,8 +161,8 @@ 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); -void drm_gem_object_handle_put_unlocked(struct drm_gem_object *obj); +void drm_gem_object_handle_get_if_exists_unlocked(struct drm_gem_object *obj); +void drm_gem_object_handle_put_if_exists_unlocked(struct drm_gem_object *obj); int drm_gem_handle_create_tail(struct drm_file *file_priv, struct drm_gem_object *obj, u32 *handlep); diff --git a/drivers/gpu/drm/gma500/fbdev.c b/drivers/gpu/drm/gma500/fbdev.c index 8edefea2ef59..afd252108cfa 100644 --- a/drivers/gpu/drm/gma500/fbdev.c +++ b/drivers/gpu/drm/gma500/fbdev.c @@ -121,7 +121,6 @@ static void psb_fbdev_fb_destroy(struct fb_info *info) drm_fb_helper_fini(fb_helper); drm_framebuffer_unregister_private(fb); - fb->obj[0] = NULL; drm_framebuffer_cleanup(fb); kfree(fb); @@ -243,7 +242,6 @@ int psb_fbdev_driver_fbdev_probe(struct drm_fb_helper *fb_helper, err_drm_framebuffer_unregister_private: drm_framebuffer_unregister_private(fb); - fb->obj[0] = NULL; drm_framebuffer_cleanup(fb); kfree(fb); err_drm_gem_object_put: -- 2.50.0

5 months, 1 week

2
3
0 0

Re: [PATCH 1/6] drm/sched: Avoid memory leaks with cancel_job() callback

by Maíra Canal

Hi Philipp, On 01/07/25 10:21, Philipp Stanner wrote: > Since its inception, the GPU scheduler can leak memory if the driver > calls drm_sched_fini() while there are still jobs in flight. > > The simplest way to solve this in a backwards compatible manner is by > adding a new callback, drm_sched_backend_ops.cancel_job(), which > instructs the driver to signal the hardware fence associated with the > job. Afterwards, the scheduler can savely use the established free_job() s/savely/safely > callback for freeing the job. > > Implement the new backend_ops callback cancel_job(). > > Suggested-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Link: https://lore.kernel.org/dri-devel/20250418113211.69956-1-tvrtko.ursulin@iga… > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> Reviewed-by: Maíra Canal <mcanal(a)igalia.com> Best Regards, - Maíra

5 months, 1 week

1
0
0 0

Re: Warnings in next-20250703 caused by commit 582111e630f5

by Thomas Zimmermann

Hi Am 03.07.25 um 19:23 schrieb Bert Karwatzki: > Am Donnerstag, dem 03.07.2025 um 18:09 +0200 schrieb Thomas Zimmermann: >> Hi, >> >> before I give up on the issue, could you please test the attached patch? >> >> Best regards >> Thomas >> >> >> -- >> 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) > I applied the patch on top of next-20250703 > > $ git log --oneline > 18ee3ed3cb60 (HEAD -> drm_gem_object_handle_put) drm/amdgpu: Provide custom framebuffer destroy function > 8d6c58332c7a (tag: next-20250703, origin/master, origin/HEAD, master) Add linux-next specific files for 20250703 > > and it solves the issue for me (i.e. no warnings). Great, thanks for testing. If nothing else, that's the minimal workaround. Here's another patch, which should solve the problem for all drivers. Could you please revert the old fix and apply the new one and test again? Best regards Thomas > > Bert Karwatzki -- -- 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)

5 months, 2 weeks

1
0
0 0

Re: Warnings in next-20250703 caused by commit 582111e630f5

by Thomas Zimmermann

Hi, before I give up on the issue, could you please test the attached patch? Best regards Thomas Am 03.07.25 um 13:59 schrieb Bert Karwatzki: > When booting next-20250703 on my Msi Alpha 15 Laptop running debian sid (last > updated 20250703) I get a several warnings of the following kind: > > [ 8.702999] [ T1628] ------------[ cut here ]------------ > [ 8.703001] [ T1628] WARNING: drivers/gpu/drm/drm_gem.c:287 at drm_gem_object_handle_put_unlocked+0xaa/0xe0, CPU#14: Xorg/1628 > [ 8.703007] [ T1628] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device rfcomm bnep nls_ascii nls_cp437 vfat fat snd_ctl_led snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel btusb snd_intel_dspcfg btrtl btintel snd_hda_codec uvcvideo snd_soc_dmic snd_acp3x_pdm_dma btbcm snd_acp3x_rn btmtk snd_hwdep videobuf2_vmalloc snd_soc_core snd_hda_core videobuf2_memops snd_pcm_oss uvc videobuf2_v4l2 bluetooth snd_mixer_oss videodev snd_pcm snd_rn_pci_acp3x videobuf2_common snd_acp_config snd_timer msi_wmi ecdh_generic snd_soc_acpi ecc mc sparse_keymap snd wmi_bmof edac_mce_amd k10temp soundcore snd_pci_acp3x ccp ac battery button joydev hid_sensor_accel_3d hid_sensor_prox hid_sensor_als hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio hid_sensor_iio_common amd_pmc evdev mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76 mac80211 libarc4 cfg80211 rfkill msr fuse > [ 8.703056] [ T1628] nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 mbcache jbd2 usbhid amdgpu drm_client_lib i2c_algo_bit drm_ttm_helper ttm drm_panel_backlight_quirks drm_exec drm_suballoc_helper amdxcp drm_buddy xhci_pci gpu_sched xhci_hcd drm_display_helper hid_sensor_hub hid_multitouch mfd_core hid_generic drm_kms_helper psmouse i2c_hid_acpi nvme usbcore amd_sfh i2c_hid hid cec serio_raw nvme_core r8169 crc16 i2c_piix4 usb_common i2c_smbus i2c_designware_platform i2c_designware_core > [ 8.703082] [ T1628] CPU: 14 UID: 1000 PID: 1628 Comm: Xorg Not tainted 6.16.0-rc4-next-20250703-master #127 PREEMPT_{RT,(full)} > [ 8.703085] [ T1628] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.10F 11/11/2024 > [ 8.703086] [ T1628] RIP: 0010:drm_gem_object_handle_put_unlocked+0xaa/0xe0 > [ 8.703088] [ T1628] Code: c7 f6 8a ff 48 89 ef e8 94 d4 2e 00 eb d8 48 8b 43 08 48 8d b8 d8 06 00 00 e8 52 78 2b 00 c7 83 08 01 00 00 00 00 00 00 eb 98 <0f> 0b 5b 5d e9 98 f6 8a ff 48 8b 83 68 01 00 00 48 8b 00 48 85 c0 > [ 8.703089] [ T1628] RSP: 0018:ffffb8e8c7fbfb00 EFLAGS: 00010246 > [ 8.703091] [ T1628] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 > [ 8.703092] [ T1628] RDX: 0000000000000000 RSI: ffff94cdc062b478 RDI: ffff94ce71390448 > [ 8.703093] [ T1628] RBP: ffff94ce14780010 R08: ffff94cdc062b618 R09: ffff94ce14780278 > [ 8.703094] [ T1628] R10: 0000000000000001 R11: ffff94cdc062b478 R12: ffff94ce14780010 > [ 8.703095] [ T1628] R13: 0000000000000007 R14: 0000000000000004 R15: ffff94ce14780010 > [ 8.703096] [ T1628] FS: 00007fc164276b00(0000) GS:ffff94dcb49cf000(0000) knlGS:0000000000000000 > [ 8.703097] [ T1628] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 8.703098] [ T1628] CR2: 00005647ccd53008 CR3: 000000012533f000 CR4: 0000000000750ef0 > [ 8.703099] [ T1628] PKRU: 55555554 > [ 8.703100] [ T1628] Call Trace: > [ 8.703101] [ T1628] <TASK> > [ 8.703104] [ T1628] drm_gem_fb_destroy+0x27/0x50 [drm_kms_helper] > [ 8.703113] [ T1628] __drm_atomic_helper_plane_destroy_state+0x1a/0xa0 [drm_kms_helper] > [ 8.703119] [ T1628] drm_atomic_helper_plane_destroy_state+0x10/0x20 [drm_kms_helper] > [ 8.703124] [ T1628] drm_atomic_state_default_clear+0x1c0/0x2e0 > [ 8.703127] [ T1628] __drm_atomic_state_free+0x6c/0xb0 > [ 8.703129] [ T1628] drm_atomic_helper_disable_plane+0x92/0xe0 [drm_kms_helper] > [ 8.703135] [ T1628] drm_mode_cursor_universal+0xf2/0x2a0 > [ 8.703140] [ T1628] drm_mode_cursor_common.part.0+0x9c/0x1e0 > [ 8.703144] [ T1628] ? drm_mode_setplane+0x320/0x320 > [ 8.703146] [ T1628] drm_mode_cursor_ioctl+0x8a/0xa0 > [ 8.703148] [ T1628] drm_ioctl_kernel+0xa1/0xf0 > [ 8.703151] [ T1628] drm_ioctl+0x26a/0x510 > [ 8.703153] [ T1628] ? drm_mode_setplane+0x320/0x320 > [ 8.703155] [ T1628] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 8.703157] [ T1628] ? rt_spin_unlock+0x12/0x40 > [ 8.703159] [ T1628] ? do_setitimer+0x185/0x1d0 > [ 8.703161] [ T1628] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 8.703164] [ T1628] amdgpu_drm_ioctl+0x46/0x90 [amdgpu] > [ 8.703283] [ T1628] __x64_sys_ioctl+0x91/0xe0 > [ 8.703286] [ T1628] do_syscall_64+0x65/0xfc0 > [ 8.703289] [ T1628] entry_SYSCALL_64_after_hwframe+0x55/0x5d > [ 8.703291] [ T1628] RIP: 0033:0x7fc1645f78db > [ 8.703292] [ T1628] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 > [ 8.703294] [ T1628] RSP: 002b:00007ffd75bce430 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > [ 8.703295] [ T1628] RAX: ffffffffffffffda RBX: 000056224e896ea0 RCX: 00007fc1645f78db > [ 8.703296] [ T1628] RDX: 00007ffd75bce4c0 RSI: 00000000c01c64a3 RDI: 000000000000000f > [ 8.703297] [ T1628] RBP: 00007ffd75bce4c0 R08: 0000000000000100 R09: 0000562210547ab0 > [ 8.703298] [ T1628] R10: 000000000000004c R11: 0000000000000246 R12: 00000000c01c64a3 > [ 8.703298] [ T1628] R13: 000000000000000f R14: 0000000000000000 R15: 000056224e5c1cd0 > [ 8.703302] [ T1628] </TASK> > [ 8.703303] [ T1628] ---[ end trace 0000000000000000 ]--- > > As the warnings do not occur in next-20250702, I looked at the commits given by > $ git log --oneline next-20250702..next-20250703 drivers/gpu/drm > to search for a culprit. So I reverted the most likely candidate, > commit 582111e630f5 ("drm/gem: Acquire references on GEM handles for framebuffers"), > in next-20250703 and the warnings disappeared. > This is the hardware I used: > $ lspci > 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex > 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU > 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge > 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge > 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge > 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge > 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge > 00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge > 00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge > 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge > 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus > 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 51) > 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) > 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 0 > 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 1 > 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 2 > 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 3 > 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 4 > 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 5 > 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 6 > 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 7 > 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c3) > 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch > 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] (rev c3) > 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller > 04:00.0 Network controller: MEDIATEK Corp. MT7921K (RZ608) Wi-Fi 6E 80MHz > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15) > 06:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. KC3000/FURY Renegade NVMe SSD [E18] (rev 01) > 07:00.0 Non-Volatile memory controller: Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03) > 08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c5) > 08:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Renoir Radeon High Definition Audio Controller > 08:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor > 08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 > 08:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1 > 08:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Audio Coprocessor (rev 01) > 08:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller > 08:00.7 Signal processing controller: Advanced Micro Devices, Inc. [AMD] Sensor Fusion Hub > > > Bert Karwatzki -- -- 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)

5 months, 2 weeks

1
0
0 0

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

by Christoph Hellwig

[Note: it would be really useful to Cc all relevant maintainers] On Fri, Jun 27, 2025 at 04:10:27PM +0100, Pavel Begunkov wrote: > This series implements it for read/write io_uring requests. The uAPI > looks similar to normal registered buffers, the user will need to > register a dmabuf in io_uring first and then use it as any other > registered buffer. On registration the user also specifies a file > to map the dmabuf for. Just commenting from the in-kernel POV here, where the interface feels wrong. You can't just expose 'the DMA device' up file operations, because there can be and often is more than one. Similarly stuffing a dma_addr_t into an iovec is rather dangerous. The model that should work much better is to have file operations 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. I also remember some discussion that new dma-buf importers should use the dynamic imported model for long-term imports, but as I'm everything but an expert in that area I'll let the dma-buf folks speak.

5 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig