Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

27 participants
3100 discussions

Re: [PATCH v2] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Hi Am 15.04.25 um 16:19 schrieb Boris Brezillon: > On Tue, 15 Apr 2025 16:02:20 +0200 > Thomas Zimmermann <tzimmermann(a)suse.de> wrote: > >> Test struct drm_gem_object.import_attach.dmabuf to detect imported >> objects. Warn if the stored state is inconsistent. >> >> During object clenaup, the dma_buf field might be NULL. Testing it in >> an object's free callback then incorrectly does a cleanup as for native >> objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that >> clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). >> >> v2: >> - use import_attach.dmabuf instead of dma_buf (Christian) >> >> Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> >> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") >> Reported-by: Andy Yan <andyshrk(a)163.com> >> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… >> Tested-by: Andy Yan <andyshrk(a)163.com> >> 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: David Airlie <airlied(a)gmail.com> >> Cc: Simona Vetter <simona(a)ffwll.ch> >> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> >> Cc: "Christian König" <christian.koenig(a)amd.com> >> Cc: dri-devel(a)lists.freedesktop.org >> Cc: linux-media(a)vger.kernel.org >> Cc: linaro-mm-sig(a)lists.linaro.org >> --- >> include/drm/drm_gem.h | 26 ++++++++++++++++++++++++-- >> 1 file changed, 24 insertions(+), 2 deletions(-) >> >> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h >> index 9b71f7a9f3f8..464b9c7feec0 100644 >> --- a/include/drm/drm_gem.h >> +++ b/include/drm/drm_gem.h >> @@ -579,6 +579,21 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje >> return (obj->handle_count > 1) || obj->dma_buf; >> } >> >> +/** >> + * drm_gem_owns_dma_buf() - Tests if GEM object backs a DMA-buffer object >> + * @obj: the GEM object >> + * @obj: the DMA buffer >> + * >> + * Returns: >> + * True if the DMA buffer refers to the GEM object's buffer. >> + */ >> +static inline bool drm_gem_owns_dma_buf(const struct drm_gem_object *obj, >> + const struct dma_buf *dma_buf) >> +{ >> + /* The dma-buf's priv field points to the original GEM object. */ >> + return dma_buf->priv == obj; >> +} >> + >> /** >> * drm_gem_is_imported() - Tests if GEM object's buffer has been imported >> * @obj: the GEM object >> @@ -588,8 +603,15 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje >> */ >> static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) >> { >> - /* The dma-buf's priv field points to the original GEM object. */ >> - return obj->dma_buf && (obj->dma_buf->priv != obj); >> + const struct dma_buf *dma_buf = NULL; >> + >> + if (!obj->import_attach) >> + return false; >> + >> + dma_buf = obj->import_attach->dmabuf; >> + >> + /* Warn if we somehow reimported our own buffer. */ >> + return !drm_WARN_ON_ONCE(obj->dev, !dma_buf || drm_gem_owns_dma_buf(obj, dma_buf)); > I'm honestly not sure I see the point of checking > obj->import_attach->dmabuf. If obj->import_attach != NULL, we're sure > it's a foreign buffer already, otherwise we would get the original GEM > object which has ->import_attach=NULL. So why not go for a simple > > return obj->import_attach != NULL; > > check, and extend the check when you get to implement imports without > import attachments (not sure what those would look like BTW). I have no strong opinion. I just found it confusing to rely on import_attach when the dma_buf is what we originally imported. 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)

6 months, 2 weeks

[PATCH] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Test struct drm_gem_object.import_attach to detect imported objects during cleanup. At that point, the imported DMA buffer might have already been released and the dma_buf field is NULL. The object's free callback then does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that eventually clear the dma_buf field in drm_gem_object_exported_dma_buf_free(). Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan <andyshrk(a)163.com> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… Tested-by: Andy Yan <andyshrk(a)163.com> 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: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/drm/drm_gem.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9b71f7a9f3f8..f09b8afcf86d 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -589,7 +589,13 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) { /* The dma-buf's priv field points to the original GEM object. */ - return obj->dma_buf && (obj->dma_buf->priv != obj); + return (obj->dma_buf && (obj->dma_buf->priv != obj)) || + /* + * TODO: During object release, the dma-buf might already + * be gone. For now keep testing import_attach, but + * this should be removed at some point. + */ + obj->import_attach; } #ifdef CONFIG_LOCKDEP -- 2.49.0

6 months, 2 weeks

[PATCH v2] drm/gem: Internally test import_attach for imported objects

by Thomas Zimmermann

Test struct drm_gem_object.import_attach.dmabuf to detect imported objects. Warn if the stored state is inconsistent. During object clenaup, the dma_buf field might be NULL. Testing it in an object's free callback then incorrectly does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). v2: - use import_attach.dmabuf instead of dma_buf (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan <andyshrk(a)163.com> Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andysh… Tested-by: Andy Yan <andyshrk(a)163.com> 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: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/drm/drm_gem.h | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 9b71f7a9f3f8..464b9c7feec0 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -579,6 +579,21 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje return (obj->handle_count > 1) || obj->dma_buf; } +/** + * drm_gem_owns_dma_buf() - Tests if GEM object backs a DMA-buffer object + * @obj: the GEM object + * @obj: the DMA buffer + * + * Returns: + * True if the DMA buffer refers to the GEM object's buffer. + */ +static inline bool drm_gem_owns_dma_buf(const struct drm_gem_object *obj, + const struct dma_buf *dma_buf) +{ + /* The dma-buf's priv field points to the original GEM object. */ + return dma_buf->priv == obj; +} + /** * drm_gem_is_imported() - Tests if GEM object's buffer has been imported * @obj: the GEM object @@ -588,8 +603,15 @@ static inline bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_obje */ static inline bool drm_gem_is_imported(const struct drm_gem_object *obj) { - /* The dma-buf's priv field points to the original GEM object. */ - return obj->dma_buf && (obj->dma_buf->priv != obj); + const struct dma_buf *dma_buf = NULL; + + if (!obj->import_attach) + return false; + + dma_buf = obj->import_attach->dmabuf; + + /* Warn if we somehow reimported our own buffer. */ + return !drm_WARN_ON_ONCE(obj->dev, !dma_buf || drm_gem_owns_dma_buf(obj, dma_buf)); } #ifdef CONFIG_LOCKDEP -- 2.49.0

6 months, 2 weeks

Re: [PATCH] drm/gem: Internally test import_attach for imported objects

by Christian König

Am 15.04.25 um 15:10 schrieb Simona Vetter: >> This is for devices who only want to do a vmap of the buffer, isn't it? > ... it's for the vmap only case, where you might not even have a struct > device. Or definitely not a reasonable one, like maybe a faux_bus device > or some device on a bus that really doesn't do dma (e.g. spi or i2c), and > where hence dma_buf_map_attachment is just something you never ever want > to do. Even in that case I would still suggest to at least create an attachment to let the exporter know that somebody is doing something with it's buffer. That is also important for move notification since you can't do those without an attachment. BTW: What is keeping a vmap alive after dropping the reservation lock? There is no pinning whatsoever as far as I can see. > I think we might want to transform obj->import_attach into a union or > tagged pointer or something like that, which can cover both cases. And > maybe a drm_gem_bo_imported_dma_buf() helper that gives you the dma_buf no > matter what if it's imported, or NULL if it's allocated on that > drm_device? Yeah, I had the same idea before as well. Just didn't know if that was something worth looking into. Regards, Christian. > > Cheers, Sima

6 months, 2 weeks

Re: [PATCH v2 2/2] drm/nouveau: nouveau_fence: Standardize list iterations

by Christian König

Am 15.04.25 um 14:19 schrieb Philipp Stanner: > nouveau_fence.c iterates over lists in a non-canonical way. Since the > operations done are just basic for-each-loops, they should be written in > the standard form. > > Use for_each_safe() instead of the custom loop iterations. > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index 6ded8c2b6d3b..60d961b43488 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -84,11 +84,12 @@ void > nouveau_fence_context_kill(struct nouveau_fence_chan *fctx, int error) > { > struct nouveau_fence *fence; > + struct list_head *pos, *tmp; > unsigned long flags; > > spin_lock_irqsave(&fctx->lock, flags); > - while (!list_empty(&fctx->pending)) { > - fence = list_entry(fctx->pending.next, typeof(*fence), head); > + list_for_each_safe(pos, tmp, &fctx->pending) { > + fence = list_entry(pos, struct nouveau_fence, head); > > if (error && !dma_fence_is_signaled_locked(&fence->base)) > dma_fence_set_error(&fence->base, error); > @@ -131,11 +132,12 @@ static int > nouveau_fence_update(struct nouveau_channel *chan, struct nouveau_fence_chan *fctx) > { > struct nouveau_fence *fence; > + struct list_head *pos, *tmp; > int drop = 0; > u32 seq = fctx->read(chan); > > - while (!list_empty(&fctx->pending)) { > - fence = list_entry(fctx->pending.next, typeof(*fence), head); > + list_for_each_safe(pos, tmp, &fctx->pending) { > + fence = list_entry(pos, struct nouveau_fence, head); > > if ((int)(seq - fence->base.seqno) < 0) > break;

6 months, 2 weeks

Re: [PATCH v7 2/4] drm/panthor: Add driver IOCTL for setting BO labels

by Daniel Stone

Hi, On Fri, 11 Apr 2025 at 16:05, Adrián Larumbe <adrian.larumbe(a)collabora.com> wrote: > +#define PANTHOR_BO_LABEL_MAXLEN PAGE_SIZE PAGE_SIZE can change between kernel builds with a config setting. If the thinking here is '4KiB is big enough' (which I agree with), then just define it to 4096. Cheers, Daniel

6 months, 2 weeks

Re: [PATCH 1/3] drm/nouveau: Prevent signaled fences in pending list

by Christian König

Am 14.04.25 um 16:27 schrieb Danilo Krummrich: > On Mon, Apr 14, 2025 at 10:54:25AM +0200, Philipp Stanner wrote: >> @Danilo: >> We have now 2 possible solutions for the firing WARN_ON floating. >> >> Version A (Christian) >> Check in nouveau_fence_context_kill() whether a fence is already >> signaled before setting an error. >> >> Version B (Me) >> This patch series here. Make sure that in Nouveau, only >> nouveau_fence_signal() signals fences. >> >> >> Both should do the trick. Please share a maintainer-preference so I can >> move on here. > Thanks for working on this Philipp. > > If you don't want to rework things entirely, A seems to be superior, since it > also catches the case when someone else would call dma_fence_is_signaled() on a > nouveau fence (which could happen at any time). This doesn't seem to be caught > by B, right? Correct, yes. I would also keep it as simple as possible for backporting this bug fix. On the other hand a rework is certainly appropriate including both nouveau as well as the DMA-fence calling rules. Especially that the DMA-fence framework calls the signaled callback with inconsistent locking is something we should fix. Regards, Christian.

6 months, 2 weeks

Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

by Andrew Davis

On 4/14/25 2:21 PM, Thomas Petazzoni wrote: > Hello Andrew, > > On Mon, 14 Apr 2025 12:08:44 -0500 > Andrew Davis <afd(a)ti.com> wrote: > >> "UIO is a broken legacy mess, so let's add more broken things >> to it as broken + broken => still broken, so no harm done", am I >> getting that right? > > Who says UIO is a "broken legacy mess"? Only you says so. I don't see > any indication anywhere in the kernel tree suggesting that UIO is > considered a broken legacy mess. > I'm not saying that*, I'm pointing out your argument is that even though what you are trying to do is broken and unsafe, it is okay to do because it isn't any "more "broken and unsafe" than UIO already is." *It is, but that is an argument to have outside of this thread :) > Keep in mind that when you're running code as root, you can load a > kernel module, which can do anything on the system security-wise. So > letting UIO expose MMIO registers of devices to userspace applications > running as root is not any worse than that. > You can take your computer out back and shoot it too, but we shouldn't encourage that either :) According to the original docs, UIO was created to support "industrial I/O cards", think old one-off custom ISA cards by vendors that had no intention of ever writing a proper driver and just wanted to poke registers and wait on an IRQ. IMHO we shouldn't be encouraging that, and trying to modernize UIO does just that. It gives the impression that is how drivers should still be written. If you setup your FPGA card to go blink an LED, sure UIO driver it is, anything more complex, then writing a proper driver is the way to go. >> If your FPGA IP can do DMA then you should not be using UIO in >> the first place, see UIO docs: >> >>> Please note that UIO is not an universal driver interface. Devices that >>> are already handled well by other kernel subsystems (like networking or >>> serial or USB) are no candidates for an UIO driver. >> >> The DMA subsystem already handles DMA devices, so write a DMA driver. > > My FPGA IP block is not a DMA controller that would fit the dmaengine > kernel subsystem. It's a weird custom device that doesn't fit in any > existing subsystem, and that happens to do "peripheral DMA" (i.e the IP > block is DMA-capable itself, without relying on a separate DMA > controller). So this (very valid) recommendation from the UIO > documentation doesn't apply to my device. Peripheral DMA is the much more common case, nothing new here. Could you give a hint as to what this device does that doesn't fit *any* current subsystem? Or are we talking a hypothetical device (which for the sake of argument is a valid thing to say, I'm sure with an FPGA card I could make something that doesn't fit any current framework too). Just want to know if you are trying to solve a specific issue or a generic issue here. Andrew > > Best regards, > > Thomas

6 months, 2 weeks

Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

by Andrew Davis

On 4/14/25 6:48 AM, Thomas Petazzoni wrote: > Hello Christoph, > > On Mon, 14 Apr 2025 04:24:21 -0700 > Christoph Hellwig <hch(a)infradead.org> wrote: > >> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote: >>> What this patch series is about is to add new user-space interface to >>> extend the existing UIO subsystem. >> >> Which as I explained to you is fundamentally broken and unsafe. If you >> need to do DMA from userspae you need to use vfio/iommufd. > > I'm still unclear as to why it is more "broken and unsafe" than UIO > already is. As I already replied in this thread: UIO allows to remap > MMIO registers into a user-space application, which can then do > whatever it wants with the IP block behind those MMIO registers. If > this IP block supports DMA, it already means that _today_ with the > current UIO subsystem as it is, the user-space application can program > a DMA transfer to read/write to any location in memory. > > Therefore, providing a way to cleanly allocate DMA buffers and get > their physical address will not make things any better or worse in > terms of safety. > > The fact that it is reasonably safe is solely based on access control > to the UIO device, done using usual Unix permissions, and that is > already the case today. > >>> I am not sure how this can work in our use-case. We have a very simple >>> set of IP blocks implemented in a FPGA, some of those IP blocks are >>> able to perform DMA operations. The register of those IP blocks are >>> mapped into a user-space application using the existing, accepted >>> upstream, UIO subsystem. Some of those registers allow to program DMA >>> transfers. So far, we can do all what we need, except program those DMA >>> transfers. Lots of people are having the same issue, and zillions of >>> ugly out-of-tree solutions flourish all over, and we're trying to see >>> if we can constructively find a solution that would be acceptable >>> upstream to resolve this use-case. Our platform is an old PowerPC with >>> no IOMMU. >> >> Then your driver design can't work and you need to replace it with a >> proper in-kernel driver. > > See above: your point is moot because providing capabilities to > allocate a buffer and get its physical address so that a UIO-based > user-space application can do DMA transfer does not make things any > more unsafe than they already are. > "UIO is a broken legacy mess, so let's add more broken things to it as broken + broken => still broken, so no harm done", am I getting that right? If your FPGA IP can do DMA then you should not be using UIO in the first place, see UIO docs: > Please note that UIO is not an universal driver interface. Devices that > are already handled well by other kernel subsystems (like networking or > serial or USB) are no candidates for an UIO driver. The DMA subsystem already handles DMA devices, so write a DMA driver. Andrew > Best regards, > > Thomas

6 months, 2 weeks

Re: [PATCH v7 3/4] drm/panthor: Label all kernel BO's

by kernel test robot

Hi Adrián, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.15-rc2 next-20250414] [cannot apply to drm-misc/drm-misc-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Adri-n-Larumbe/drm-panthor-I… base: linus/master patch link: https://lore.kernel.org/r/20250411150357.3308921-4-adrian.larumbe%40collabo… patch subject: [PATCH v7 3/4] drm/panthor: Label all kernel BO's config: i386-buildonly-randconfig-006-20250414 (https://download.01.org/0day-ci/archive/20250414/202504142148.NBAyzLuE-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250414/202504142148.NBAyzLuE-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/202504142148.NBAyzLuE-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/panthor/panthor_gem.c:86: warning: Function parameter or struct member 'name' not described in 'panthor_kernel_bo_create' vim +86 drivers/gpu/drm/panthor/panthor_gem.c 8a1cc07578bf42 Boris Brezillon 2024-02-29 67 8a1cc07578bf42 Boris Brezillon 2024-02-29 68 /** 8a1cc07578bf42 Boris Brezillon 2024-02-29 69 * panthor_kernel_bo_create() - Create and map a GEM object to a VM 8a1cc07578bf42 Boris Brezillon 2024-02-29 70 * @ptdev: Device. 8a1cc07578bf42 Boris Brezillon 2024-02-29 71 * @vm: VM to map the GEM to. If NULL, the kernel object is not GPU mapped. 8a1cc07578bf42 Boris Brezillon 2024-02-29 72 * @size: Size of the buffer object. 8a1cc07578bf42 Boris Brezillon 2024-02-29 73 * @bo_flags: Combination of drm_panthor_bo_flags flags. 8a1cc07578bf42 Boris Brezillon 2024-02-29 74 * @vm_map_flags: Combination of drm_panthor_vm_bind_op_flags (only those 8a1cc07578bf42 Boris Brezillon 2024-02-29 75 * that are related to map operations). 8a1cc07578bf42 Boris Brezillon 2024-02-29 76 * @gpu_va: GPU address assigned when mapping to the VM. 8a1cc07578bf42 Boris Brezillon 2024-02-29 77 * If gpu_va == PANTHOR_VM_KERNEL_AUTO_VA, the virtual address will be 8a1cc07578bf42 Boris Brezillon 2024-02-29 78 * automatically allocated. 8a1cc07578bf42 Boris Brezillon 2024-02-29 79 * 8a1cc07578bf42 Boris Brezillon 2024-02-29 80 * Return: A valid pointer in case of success, an ERR_PTR() otherwise. 8a1cc07578bf42 Boris Brezillon 2024-02-29 81 */ 8a1cc07578bf42 Boris Brezillon 2024-02-29 82 struct panthor_kernel_bo * 8a1cc07578bf42 Boris Brezillon 2024-02-29 83 panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm, 8a1cc07578bf42 Boris Brezillon 2024-02-29 84 size_t size, u32 bo_flags, u32 vm_map_flags, f48f05d54f7696 Adrián Larumbe 2025-04-11 85 u64 gpu_va, const char *name) 8a1cc07578bf42 Boris Brezillon 2024-02-29 @86 { 8a1cc07578bf42 Boris Brezillon 2024-02-29 87 struct drm_gem_shmem_object *obj; 8a1cc07578bf42 Boris Brezillon 2024-02-29 88 struct panthor_kernel_bo *kbo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 89 struct panthor_gem_object *bo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 90 int ret; 8a1cc07578bf42 Boris Brezillon 2024-02-29 91 8a1cc07578bf42 Boris Brezillon 2024-02-29 92 if (drm_WARN_ON(&ptdev->base, !vm)) 8a1cc07578bf42 Boris Brezillon 2024-02-29 93 return ERR_PTR(-EINVAL); 8a1cc07578bf42 Boris Brezillon 2024-02-29 94 8a1cc07578bf42 Boris Brezillon 2024-02-29 95 kbo = kzalloc(sizeof(*kbo), GFP_KERNEL); 8a1cc07578bf42 Boris Brezillon 2024-02-29 96 if (!kbo) 8a1cc07578bf42 Boris Brezillon 2024-02-29 97 return ERR_PTR(-ENOMEM); 8a1cc07578bf42 Boris Brezillon 2024-02-29 98 8a1cc07578bf42 Boris Brezillon 2024-02-29 99 obj = drm_gem_shmem_create(&ptdev->base, size); 8a1cc07578bf42 Boris Brezillon 2024-02-29 100 if (IS_ERR(obj)) { 8a1cc07578bf42 Boris Brezillon 2024-02-29 101 ret = PTR_ERR(obj); 8a1cc07578bf42 Boris Brezillon 2024-02-29 102 goto err_free_bo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 103 } 8a1cc07578bf42 Boris Brezillon 2024-02-29 104 8a1cc07578bf42 Boris Brezillon 2024-02-29 105 bo = to_panthor_bo(&obj->base); 8a1cc07578bf42 Boris Brezillon 2024-02-29 106 kbo->obj = &obj->base; 8a1cc07578bf42 Boris Brezillon 2024-02-29 107 bo->flags = bo_flags; 8a1cc07578bf42 Boris Brezillon 2024-02-29 108 f48f05d54f7696 Adrián Larumbe 2025-04-11 109 panthor_gem_kernel_bo_set_label(kbo, name); f48f05d54f7696 Adrián Larumbe 2025-04-11 110 5d01b56f0518d8 Boris Brezillon 2024-10-30 111 /* The system and GPU MMU page size might differ, which becomes a 5d01b56f0518d8 Boris Brezillon 2024-10-30 112 * problem for FW sections that need to be mapped at explicit address 5d01b56f0518d8 Boris Brezillon 2024-10-30 113 * since our PAGE_SIZE alignment might cover a VA range that's 5d01b56f0518d8 Boris Brezillon 2024-10-30 114 * expected to be used for another section. 5d01b56f0518d8 Boris Brezillon 2024-10-30 115 * Make sure we never map more than we need. 5d01b56f0518d8 Boris Brezillon 2024-10-30 116 */ 5d01b56f0518d8 Boris Brezillon 2024-10-30 117 size = ALIGN(size, panthor_vm_page_size(vm)); 8a1cc07578bf42 Boris Brezillon 2024-02-29 118 ret = panthor_vm_alloc_va(vm, gpu_va, size, &kbo->va_node); 8a1cc07578bf42 Boris Brezillon 2024-02-29 119 if (ret) 8a1cc07578bf42 Boris Brezillon 2024-02-29 120 goto err_put_obj; 8a1cc07578bf42 Boris Brezillon 2024-02-29 121 8a1cc07578bf42 Boris Brezillon 2024-02-29 122 ret = panthor_vm_map_bo_range(vm, bo, 0, size, kbo->va_node.start, vm_map_flags); 8a1cc07578bf42 Boris Brezillon 2024-02-29 123 if (ret) 8a1cc07578bf42 Boris Brezillon 2024-02-29 124 goto err_free_va; 8a1cc07578bf42 Boris Brezillon 2024-02-29 125 ff60c8da0aaf7e Boris Brezillon 2024-05-02 126 kbo->vm = panthor_vm_get(vm); 8a1cc07578bf42 Boris Brezillon 2024-02-29 127 bo->exclusive_vm_root_gem = panthor_vm_root_gem(vm); 8a1cc07578bf42 Boris Brezillon 2024-02-29 128 drm_gem_object_get(bo->exclusive_vm_root_gem); 8a1cc07578bf42 Boris Brezillon 2024-02-29 129 bo->base.base.resv = bo->exclusive_vm_root_gem->resv; 8a1cc07578bf42 Boris Brezillon 2024-02-29 130 return kbo; 8a1cc07578bf42 Boris Brezillon 2024-02-29 131 8a1cc07578bf42 Boris Brezillon 2024-02-29 132 err_free_va: 8a1cc07578bf42 Boris Brezillon 2024-02-29 133 panthor_vm_free_va(vm, &kbo->va_node); 8a1cc07578bf42 Boris Brezillon 2024-02-29 134 8a1cc07578bf42 Boris Brezillon 2024-02-29 135 err_put_obj: 8a1cc07578bf42 Boris Brezillon 2024-02-29 136 drm_gem_object_put(&obj->base); 8a1cc07578bf42 Boris Brezillon 2024-02-29 137 8a1cc07578bf42 Boris Brezillon 2024-02-29 138 err_free_bo: 8a1cc07578bf42 Boris Brezillon 2024-02-29 139 kfree(kbo); 8a1cc07578bf42 Boris Brezillon 2024-02-29 140 return ERR_PTR(ret); 8a1cc07578bf42 Boris Brezillon 2024-02-29 141 } 8a1cc07578bf42 Boris Brezillon 2024-02-29 142 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

6 months, 2 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig