Re: [PATCH v4 43/48] drm/ttm: introduce pool_shrink_rwsem
On Mon, Aug 07, 2023 at 07:09:31PM +0800, Qi Zheng wrote:
> Currently, the synchronize_shrinkers() is only used by TTM pool. It only
> requires that no shrinkers run in parallel.
>
> After we use RCU+refcount method to implement the lockless slab shrink,
> we can not use shrinker_rwsem or synchronize_rcu() to guarantee that all
> shrinker invocations have seen an update before freeing memory.
>
> So we introduce a new pool_shrink_rwsem to implement a private
> synchronize_shrinkers(), so as to achieve the same purpose.
>
> Signed-off-by: Qi Zheng
> Reviewed-by: Muchun Song
On the 5 drm patches (I counted 2 ttm and 3 drivers) for merging through
some other tree (since I'm assuming that's how this will land):
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 15 +++
> include/linux/shrinker.h | 2 --
> mm/shrinker.c | 15 ---
> 3 files changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index c9c9618c0dce..38b4c280725c 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -74,6 +74,7 @@ static struct ttm_pool_type global_dma32_uncached[MAX_ORDER
> + 1];
> static spinlock_t shrinker_lock;
> static struct list_head shrinker_list;
> static struct shrinker *mm_shrinker;
> +static DECLARE_RWSEM(pool_shrink_rwsem);
>
> /* Allocate pages of size 1 << order with the given gfp_flags */
> static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t
> gfp_flags,
> @@ -317,6 +318,7 @@ static unsigned int ttm_pool_shrink(void)
> unsigned int num_pages;
> struct page *p;
>
> + down_read(&pool_shrink_rwsem);
> spin_lock(&shrinker_lock);
> pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
> list_move_tail(&pt->shrinker_list, &shrinker_list);
> @@ -329,6 +331,7 @@ static unsigned int ttm_pool_shrink(void)
> } else {
> num_pages = 0;
> }
> + up_read(&pool_shrink_rwsem);
>
> return num_pages;
> }
> @@ -572,6 +575,18 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
> *dev,
> }
> EXPORT_SYMBOL(ttm_pool_init);
>
> +/**
> + * synchronize_shrinkers - Wait for all running shrinkers to complete.
> + *
> + * This is useful to guarantee that all shrinker invocations have seen an
> + * update, before freeing memory, similar to rcu.
> + */
> +static void synchronize_shrinkers(void)
> +{
> + down_write(&pool_shrink_rwsem);
> + up_write(&pool_shrink_rwsem);
> +}
> +
> /**
> * ttm_pool_fini - Cleanup a pool
> *
> diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
> index c55c07c3f0cb..025c8070dd86 100644
> --- a/include/linux/shrinker.h
> +++ b/include/linux/shrinker.h
> @@ -103,8 +103,6 @@ struct shrinker *shrinker_alloc(unsigned int flags, const
> char *fmt, ...);
> void shrinker_register(struct shrinker *shrinker);
> void shrinker_free(struct shrinker *shrinker);
>
> -extern void synchronize_shrinkers(void);
> -
> #ifdef CONFIG_SHRINKER_DEBUG
> extern int __printf(2, 3) shrinker_debugfs_rename(struct shrinker *shrinker,
> const char *fmt, ...);
> diff --git a/mm/shrinker.c b/mm/shrinker.c
> index 3ab301ff122d..a27779ed3798 100644
> --- a/mm/shrinker.c
> +++ b/mm/shrinker.c
> @@ -650,18 +650,3 @@ void shrinker_free(struct shrinker *shrinker)
> kfree(shrinker);
> }
> EXPORT_SYMBOL_GPL(shrinker_free);
> -
> -/**
> - * synchronize_shrinkers - Wait for all running shrinkers to complete.
> - *
> - * This is equivalent to calling unregister_shrink() and register_shrinker(),
> - * but atomically and with less overhead. This is useful to guarantee that
> all
> - * shrinker invocations have seen an update, before freeing memory, similar
> to
> - * rcu.
> - */
> -void synchronize_shrinkers(void)
> -{
> - down_write(&shrinker_rwsem);
> - up_write(&shrinker_rwsem);
> -}
> -EXPORT_SYMBOL(synchronize_shrinkers);
> --
> 2.30.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/3] drm/shmem-helper: Export dedicated wrappers for GEM object functions
On Fri, Nov 05, 2021 at 10:35:57AM +0100, Thomas Zimmermann wrote:
> Wrap GEM SHMEM functions for struct drm_gem_object_funcs and update
> all callers. This will allow for an update of the public interfaces
> of the GEM SHMEM helper library.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 45 -
> drivers/gpu/drm/lima/lima_gem.c | 8 +-
> drivers/gpu/drm/panfrost/panfrost_gem.c | 12 +--
> drivers/gpu/drm/v3d/v3d_bo.c| 14 +--
> drivers/gpu/drm/virtio/virtgpu_object.c | 15 ++-
> include/drm/drm_gem_shmem_helper.h | 120
> 6 files changed, 161 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index cd93e91b3487..72ac263f20be 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -30,14 +30,14 @@
Maybe add a few lines to the intro DOC: section about which functions
should be used where? Just so drivers don't make a mess out of this again
now that you cleaned it up.
It's ofc not going to be perfect, but better than nothing.
With that, on the series:
Acked-by: Daniel Vetter
But maybe wait for some more acks/reviews from driver folks.
-Daniel
> */
>
> static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
> - .free = drm_gem_shmem_free_object,
> - .print_info = drm_gem_shmem_print_info,
> - .pin = drm_gem_shmem_pin,
> - .unpin = drm_gem_shmem_unpin,
> - .get_sg_table = drm_gem_shmem_get_sg_table,
> - .vmap = drm_gem_shmem_vmap,
> - .vunmap = drm_gem_shmem_vunmap,
> - .mmap = drm_gem_shmem_mmap,
> + .free = drm_gem_shmem_object_free,
> + .print_info = drm_gem_shmem_object_print_info,
> + .pin = drm_gem_shmem_object_pin,
> + .unpin = drm_gem_shmem_object_unpin,
> + .get_sg_table = drm_gem_shmem_object_get_sg_table,
> + .vmap = drm_gem_shmem_object_vmap,
> + .vunmap = drm_gem_shmem_object_vunmap,
> + .mmap = drm_gem_shmem_object_mmap,
> };
>
> static struct drm_gem_shmem_object *
> @@ -121,8 +121,7 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
> * @obj: GEM object to free
> *
> * This function cleans up the GEM object state and frees the memory used to
> - * store the object itself. It should be used to implement
> - * &drm_gem_object_funcs.free.
> + * store the object itself.
> */
> void drm_gem_shmem_free_object(struct drm_gem_object *obj)
> {
> @@ -248,8 +247,7 @@ EXPORT_SYMBOL(drm_gem_shmem_put_pages);
> * @obj: GEM object
> *
> * This function makes sure the backing pages are pinned in memory while the
> - * buffer is exported. It should only be used to implement
> - * &drm_gem_object_funcs.pin.
> + * buffer is exported.
> *
> * Returns:
> * 0 on success or a negative error code on failure.
> @@ -269,7 +267,7 @@ EXPORT_SYMBOL(drm_gem_shmem_pin);
> * @obj: GEM object
> *
> * This function removes the requirement that the backing pages are pinned in
> - * memory. It should only be used to implement &drm_gem_object_funcs.unpin.
> + * memory.
> */
> void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> {
> @@ -340,11 +338,8 @@ static int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem, struct
> * store.
> *
> * This function makes sure that a contiguous kernel virtual address mapping
> - * exists for the buffer backing the shmem GEM object.
> - *
> - * This function can be used to implement &drm_gem_object_funcs.vmap. But it
> can
> - * also be called by drivers directly, in which case it will hide the
> - * differences between dma-buf imported and natively allocated objects.
> + * exists for the buffer backing the shmem GEM object. It hides the
> differences
> + * between dma-buf imported and natively allocated objects.
> *
> * Acquired mappings should be cleaned up by calling drm_gem_shmem_vunmap().
> *
> @@ -396,9 +391,8 @@ static void drm_gem_shmem_vunmap_locked(struct
> drm_gem_shmem_object *shmem,
> * drm_gem_shmem_vmap(). The mapping is only removed when the use count
> drops to
> * zero.
> *
> - * This function can be used to implement &drm_gem_object_funcs.vmap. But it
> can
> - * also be called by drivers directly, in which case it will hide the
> - * differences between dma-buf imported and natively allocated objects.
> + * This function hides the differences between dma-buf imported and natively
> + * allocated objects.
> */
> void drm_gem_shmem_vunmap(struct drm_gem_object *obj, struct dma_buf_map
> *map)
> {
> @@ -604,8 +598,7 @@ static const struct vm_o
Re: regression with mainline kernel
On Sat, Nov 13, 2021 at 09:06:57AM -0800, Linus Torvalds wrote:
> [ Hmm. This email was marked as spam for me. I see no obvious reason
> for it being marked as spam, but it happens.. ]
>
> On Thu, Nov 11, 2021 at 12:52 PM Sudip Mukherjee
> wrote:
> >
> > # first bad commit: [cd7f5ca33585918febe5e2f6dc090a21cfa775b0]
> > drm/virtio: implement context init: add virtio_gpu_fence_event
>
> Hmm. Judging from your automated screenshots, the login never appears.
Greg also reported a regression, plus I looked at the commit and had
questions too.
> > And, indeed reverting cd7f5ca33585 on top of debe436e77c7 has fixed
> > the problem I was seeing on my qemu test of x86_64. The qemu image is
> > based on Ubuntu.
>
> Presumably either that commit is somehow buggy in itself - or it does
> exactly what it means to do, and the new poll() semantics just
> confuses the heck out of the X server (or wayland or whatever).
>
> And honestly, if I read that thing correctly, the patch is entirely
> broken. The new poll function (virtio_gpu_poll()) will unconditionally
> remove the first event from the event list, and then report "Yeah, I
> had events".
>
> This is completely bogus for a few reasons:
>
> - poll() really should be idempotent, because the poll function gets
> called multiple times
>
> - it doesn't even seem to check that the event that it removes is the
> new VIRTGPU_EVENT_FENCE_SIGNALED_INTERNAL kind of event, so it will
> unconditionally just remove random events.
>
> - it does seem to check the "vfpriv->ring_idx_mask" and do the old
> thing if that is zero, but I see absolutely no reason for that (and
> that check itself has caused problems, see below)
>
> Honestly, my reaction to this all is that that commit is fundamentally
> broken and probably should be reverted regardless as "this commit does
> bad things".
>
> HOWEVER - it has had a fix for a NULL pointer dereference in the
> meantime - can you check whether the current top of tree happens to
> work for you? Maybe your problem isn't due to "that commit does
> unnatural things", but simply due to the bug fixed in d89c0c8322ec
> ("drm/virtio: Fix NULL dereference error in virtio_gpu_poll").
>
> And if it's still broken with that commit, I'll happily revert it and
> people need to go back to the drawing board.
>
> In fact, I would really suggest that people look at that
> virtio_gpu_poll() function regardless. That odd "let's unconditionally
> just drop events in the poll function is really REALLY broken
> behavior.
Tbh I haven't looked at the poll implementation, but it's fishy on
principles as in drm drivers shouldn't reinvent them. The commit message
cites vmwgfx as example for a private driver drm_event, but that works
perfectly fine with standard drm_poll (and is meant to work perfectly fine
with standard drm_poll).
So if it's buggy on top of questionable I think revert might be the right
choice irrespective of whether there's some fixes in-flight.
So if you end up pushing that revert:
References:
https://lore.kernel.org/dri-devel/YZJrutLaiwozLfSw@phenom.ffwll.local/
Acked-by: Daniel Vetter
Plus credit Greg too and all that ofc.
But lets wait a bit for virtio folks to chime in, it's only Monday :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 6/8] drm/shmem-helper: Add generic memory shrinker
m_shrinker = gem_shrinker;
> +
> + err = register_shrinker(&gem_shrinker->base);
> + if (err) {
> + dev->shmem_shrinker = NULL;
> + kfree(gem_shrinker);
> + return err;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_shrinker_register);
> +
> +void drm_gem_shmem_shrinker_unregister(struct drm_device *dev)
> +{
> + struct drm_gem_shmem_shrinker *gem_shrinker = dev->shmem_shrinker;
> +
> + if (gem_shrinker) {
> + unregister_shrinker(&gem_shrinker->base);
> + mutex_destroy(&gem_shrinker->lock);
> + dev->shmem_shrinker = NULL;
> + kfree(gem_shrinker);
> + }
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_shrinker_unregister);
> +
> MODULE_DESCRIPTION("DRM SHMEM memory-management helpers");
> MODULE_IMPORT_NS(DMA_BUF);
> MODULE_LICENSE("GPL v2");
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 9923c7a6885e..929546cad894 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -16,6 +16,7 @@ struct drm_vblank_crtc;
> struct drm_vma_offset_manager;
> struct drm_vram_mm;
> struct drm_fb_helper;
> +struct drm_gem_shmem_shrinker;
>
> struct inode;
>
> @@ -277,6 +278,9 @@ struct drm_device {
> /** @vram_mm: VRAM MM memory manager */
> struct drm_vram_mm *vram_mm;
>
> + /** @shmem_shrinker: SHMEM GEM memory shrinker */
> + struct drm_gem_shmem_shrinker *shmem_shrinker;
> +
> /**
>* @switch_power_state:
>*
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index e2941cee14b6..cdb99cfbf0bc 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -172,6 +172,17 @@ struct drm_gem_object_funcs {
>* This is optional but necessary for mmap support.
>*/
> const struct vm_operations_struct *vm_ops;
> +
> + /**
> + * @purge:
> + *
> + * Releases the GEM object's allocated backing storage to the system.
> + *
> + * Returns the number of pages that have been freed by purging the GEM
> object.
> + *
> + * This callback is used by the GEM shrinker.
> + */
> + unsigned long (*purge)(struct drm_gem_object *obj);
> };
>
> /**
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index d0a57853c188..455254f131f6 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -15,6 +16,7 @@
> struct dma_buf_attachment;
> struct drm_mode_create_dumb;
> struct drm_printer;
> +struct drm_device;
> struct sg_table;
>
> /**
> @@ -272,6 +274,29 @@ static inline int drm_gem_shmem_object_mmap(struct
> drm_gem_object *obj, struct v
> return drm_gem_shmem_mmap(shmem, vma);
> }
>
> +/**
> + * struct drm_gem_shmem_shrinker - Generic memory shrinker for shmem GEMs
> + */
> +struct drm_gem_shmem_shrinker {
> + /** @base: Shrinker for purging shmem GEM objects */
> + struct shrinker base;
> +
> + /** @lock: Protects @lru */
> + struct mutex lock;
> +
> + /** @lru: List of shmem GEM objects available for purging */
> + struct list_head lru;
> +
> + /** @dev: DRM device that uses this shrinker */
> + struct drm_device *dev;
> +
> + /** @shrinkable_count: Count of shmem GEM pages to be purged */
> + u64 shrinkable_count;
> +};
> +
> +int drm_gem_shmem_shrinker_register(struct drm_device *dev);
> +void drm_gem_shmem_shrinker_unregister(struct drm_device *dev);
> +
> /*
> * Driver ops
> */
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a simplified version of TTM's existing kmap code. Both
> > functions respect the memory's location ani/or writecombine flags.
> >
> > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
> > two helpers that convert a GEM object into the TTM BO and forward the call
> > to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
> > callbacks.
> >
> > v4:
> > * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
> > Christian)
>
> Bunch of minor comments below, but over all look very solid to me.
Yeah I think just duplicating the ttm bo map stuff for vmap is indeed the
cleanest. And then we can maybe push the combinatorial monster into
vmwgfx, which I think is the only user after this series. Or perhaps a
dedicated set of helpers to map an invidual page (again using the
dma_buf_map stuff).
I'll let Christian with the details, but at a high level this is
definitely
Acked-by: Daniel Vetter
Thanks a lot for doing all this.
-Daniel
>
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
> > drivers/gpu/drm/ttm/ttm_bo_util.c| 72
> > include/drm/drm_gem_ttm_helper.h | 6 +++
> > include/drm/ttm/ttm_bo_api.h | 28 +++
> > include/linux/dma-buf-map.h | 20
> > 5 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > index 0e4fb9ba43ad..db4c14d78a30 100644
> > --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
> > unsigned int indent,
> > }
> > EXPORT_SYMBOL(drm_gem_ttm_print_info);
> > +/**
> > + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object
> > + * @gem: GEM object.
> > + * @map: [out] returns the dma-buf mapping.
> > + *
> > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as
> > + * &drm_gem_object_funcs.vmap callback.
> > + *
> > + * Returns:
> > + * 0 on success, or a negative errno code otherwise.
> > + */
> > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > +struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + return ttm_bo_vmap(bo, map);
> > +
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vmap);
> > +
> > +/**
> > + * drm_gem_ttm_vunmap() - vunmap &ttm_buffer_object
> > + * @gem: GEM object.
> > + * @map: dma-buf mapping.
> > + *
> > + * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
> > + * &drm_gem_object_funcs.vmap callback.
> > + */
> > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > + struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + ttm_bo_vunmap(bo, map);
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vunmap);
> > +
> > /**
> >* drm_gem_ttm_mmap() - mmap &ttm_buffer_object
> >* @gem: GEM object.
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > index bdee4df1f3f2..80c42c774c7d 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
> > }
> > EXPORT_SYMBOL(ttm_bo_kunmap);
> > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
> > +{
> > + struct ttm_resource *mem = &bo->mem;
> > + int ret;
> > +
> > + ret = ttm_mem_io_reserve(bo->bdev, mem);
> > + if (ret)
> > + return ret;
> > +
> > + if (mem->bus.is_iomem) {
> > + void __iomem *vaddr_iomem;
> > + unsigned long size = bo->num_pages << PAGE_SHIFT;
>
> Please use uint64_t here and make sure to cast bo->num_pages before
> sh
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
p(map->vaddr);
> > > > + dma_buf_map_clear(map);
> > > > +
> > > > + ttm_mem_io_free(bo->bdev, &bo->mem);
> > > > +}
> > > > +EXPORT_SYMBOL(ttm_bo_vunmap);
> > > > +
> > > > static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
> > > > bool dst_use_tt)
> > > > {
> > > > diff --git a/include/drm/drm_gem_ttm_helper.h
> > > > b/include/drm/drm_gem_ttm_helper.h
> > > > index 118cef76f84f..7c6d874910b8 100644
> > > > --- a/include/drm/drm_gem_ttm_helper.h
> > > > +++ b/include/drm/drm_gem_ttm_helper.h
> > > > @@ -10,11 +10,17 @@
> > > > #include
> > > > #include
> > > > +struct dma_buf_map;
> > > > +
> > > > #define drm_gem_ttm_of_gem(gem_obj) \
> > > > container_of(gem_obj, struct ttm_buffer_object, base)
> > > > void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int
> > > > indent,
> > > > const struct drm_gem_object *gem);
> > > > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > > > + struct dma_buf_map *map);
> > > > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > > > + struct dma_buf_map *map);
> > > > int drm_gem_ttm_mmap(struct drm_gem_object *gem,
> > > > struct vm_area_struct *vma);
> > > > diff --git a/include/drm/ttm/ttm_bo_api.h
> > > > b/include/drm/ttm/ttm_bo_api.h
> > > > index 37102e45e496..2c59a785374c 100644
> > > > --- a/include/drm/ttm/ttm_bo_api.h
> > > > +++ b/include/drm/ttm/ttm_bo_api.h
> > > > @@ -48,6 +48,8 @@ struct ttm_bo_global;
> > > > struct ttm_bo_device;
> > > > +struct dma_buf_map;
> > > > +
> > > > struct drm_mm_node;
> > > > struct ttm_placement;
> > > > @@ -494,6 +496,32 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
> > > > unsigned long start_page,
> > > > */
> > > > void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map);
> > > > +/**
> > > > + * ttm_bo_vmap
> > > > + *
> > > > + * @bo: The buffer object.
> > > > + * @map: pointer to a struct dma_buf_map representing the map.
> > > > + *
> > > > + * Sets up a kernel virtual mapping, using ioremap or vmap to the
> > > > + * data in the buffer object. The parameter @map returns the virtual
> > > > + * address as struct dma_buf_map. Unmap the buffer with
> > > > ttm_bo_vunmap().
> > > > + *
> > > > + * Returns
> > > > + * -ENOMEM: Out of memory.
> > > > + * -EINVAL: Invalid range.
> > > > + */
> > > > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map);
> > > > +
> > > > +/**
> > > > + * ttm_bo_vunmap
> > > > + *
> > > > + * @bo: The buffer object.
> > > > + * @map: Object describing the map to unmap.
> > > > + *
> > > > + * Unmaps a kernel map set up by ttm_bo_vmap().
> > > > + */
> > > > +void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map
> > > > *map);
> > > > +
> > > > /**
> > > > * ttm_bo_mmap_obj - mmap memory backed by a ttm buffer object.
> > > > *
> > > > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > > > index fd1aba545fdf..2e8bbecb5091 100644
> > > > --- a/include/linux/dma-buf-map.h
> > > > +++ b/include/linux/dma-buf-map.h
> > > > @@ -45,6 +45,12 @@
> > > > *
> > > > * dma_buf_map_set_vaddr(&map. 0xdeadbeaf);
> > > > *
> > > > + * To set an address in I/O memory, use dma_buf_map_set_vaddr_iomem().
> > > > + *
> > > > + * .. code-block:: c
> > > > + *
> > > > + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
> > > > + *
> > > > * Test if a mapping is valid with either dma_buf_map_is_set() or
> > > > * dma_buf_map_is_null().
> > > > *
> > > > @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(struct
> > > > dma_buf_map *map, void *vaddr)
> > > > map->is_iomem = false;
> > > > }
> > > > +/**
> > > > + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping structure to
> > > > an address in I/O memory
> > > > + * @map: The dma-buf mapping structure
> > > > + * @vaddr_iomem: An I/O-memory address
> > > > + *
> > > > + * Sets the address and the I/O-memory flag.
> > > > + */
> > > > +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_map *map,
> > > > + void __iomem *vaddr_iomem)
> > > > +{
> > > > + map->vaddr_iomem = vaddr_iomem;
> > > > + map->is_iomem = true;
> > > > +}
> > > > +
> > > > /**
> > > > * dma_buf_map_is_equal - Compares two dma-buf mapping structures
> > > > for equality
> > > > * @lhs: The dma-buf mapping structure
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C07bc68af3c6440b5be8d08d8740e9b32%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637386953433558595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RlGCmjzyZERvqfnl4kA1bEHez5bkLf3F9OlKi2ybDAM%3D&reserved=0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory
On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
> internally by DRM's fbdev helper.
>
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
>
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
>
> v5:
> * implement fb_read/fb_write internally (Daniel, Sam)
> v4:
> * move dma_buf_map changes into separate patch (Daniel)
> * TODO list: comment on fbdev updates (Daniel)
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Sam Ravnborg
> ---
> Documentation/gpu/todo.rst| 19 ++-
> drivers/gpu/drm/bochs/bochs_kms.c | 1 -
> drivers/gpu/drm/drm_fb_helper.c | 227 --
> include/drm/drm_mode_config.h | 12 --
> 4 files changed, 230 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>
>
> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>
> Contact: Maintainer of the driver you plan to convert
>
> Level: Intermediate
>
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
> -
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = &bochs_mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..1d3180841778 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
> work_struct *work)
> }
>
> static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> - struct drm_clip_rect *clip)
> + struct drm_clip_rect *clip,
> + struct dma_buf_map *dst)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip->x2 - clip->x1) * cpp;
> unsigned int y;
>
> - for (y = clip->y1; y < clip->y2; y++) {
> - if (!fb_helper->dev->mode_config.
Re: [PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> Kernel DRM clients now store their framebuffer address in an instance
> of struct dma_buf_map. Depending on the buffer's location, the address
> refers to system or I/O memory.
>
> Callers of drm_client_buffer_vmap() receive a copy of the value in
> the call's supplied arguments. It can be accessed and modified with
> dma_buf_map interfaces.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
> Tested-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_client.c| 34 +++--
> drivers/gpu/drm/drm_fb_helper.c | 23 +-
> include/drm/drm_client.h| 7 ---
> 3 files changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index ac0082bed966..fe573acf1067 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -235,7 +235,7 @@ static void drm_client_buffer_delete(struct
> drm_client_buffer *buffer)
> {
> struct drm_device *dev = buffer->client->dev;
>
> - drm_gem_vunmap(buffer->gem, buffer->vaddr);
> + drm_gem_vunmap(buffer->gem, &buffer->map);
>
> if (buffer->gem)
> drm_gem_object_put(buffer->gem);
> @@ -291,25 +291,31 @@ drm_client_buffer_create(struct drm_client_dev *client,
> u32 width, u32 height, u
> /**
> * drm_client_buffer_vmap - Map DRM client buffer into address space
> * @buffer: DRM client buffer
> + * @map_copy: Returns the mapped memory's address
> *
> * This function maps a client buffer into kernel address space. If the
> - * buffer is already mapped, it returns the mapping's address.
> + * buffer is already mapped, it returns the existing mapping's address.
> *
> * Client buffer mappings are not ref'counted. Each call to
> * drm_client_buffer_vmap() should be followed by a call to
> * drm_client_buffer_vunmap(); or the client buffer should be mapped
> * throughout its lifetime.
> *
> + * The returned address is a copy of the internal value. In contrast to
> + * other vmap interfaces, you don't need it for the client's vunmap
> + * function. So you can modify it at will during blit and draw operations.
> + *
> * Returns:
> - * The mapped memory's address
> + * 0 on success, or a negative errno code otherwise.
> */
> -void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
> +int
> +drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map
> *map_copy)
> {
> - struct dma_buf_map map;
> + struct dma_buf_map *map = &buffer->map;
> int ret;
>
> - if (buffer->vaddr)
> - return buffer->vaddr;
> + if (dma_buf_map_is_set(map))
> + goto out;
>
> /*
>* FIXME: The dependency on GEM here isn't required, we could
> @@ -319,13 +325,14 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
> *buffer)
>* fd_install step out of the driver backend hooks, to make that
>* final step optional for internal users.
>*/
> - ret = drm_gem_vmap(buffer->gem, &map);
> + ret = drm_gem_vmap(buffer->gem, map);
> if (ret)
> - return ERR_PTR(ret);
> + return ret;
>
> - buffer->vaddr = map.vaddr;
> +out:
> + *map_copy = *map;
>
> - return map.vaddr;
> + return 0;
> }
> EXPORT_SYMBOL(drm_client_buffer_vmap);
>
> @@ -339,10 +346,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
> */
> void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
> {
> - struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
> + struct dma_buf_map *map = &buffer->map;
>
> - drm_gem_vunmap(buffer->gem, &map);
> - buffer->vaddr = NULL;
> + drm_gem_vunmap(buffer->gem, map);
> }
> EXPORT_SYMBOL(drm_client_buffer_vunmap);
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index c2f72bb6afb1..6212cd7cde1d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -378,7 +378,7 @@ static void drm_fb_helper_dirty_blit_real(struct
> drm_fb_helper *fb_helper,
> unsigned int cpp = fb->format->cpp[0];
> size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->vaddr + offset;
> + void *dst = fb_helper->buffer->map.vaddr + offset;
> size_t len = (clip-
Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote: > Hi > > On 22.10.20 10:05, Daniel Vetter wrote: > > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote: > >> At least sparc64 requires I/O-specific access to framebuffers. This > >> patch updates the fbdev console accordingly. > >> > >> For drivers with direct access to the framebuffer memory, the callback > >> functions in struct fb_ops test for the type of memory and call the rsp > >> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented > >> internally by DRM's fbdev helper. > >> > >> For drivers that employ a shadow buffer, fbdev's blit function retrieves > >> the framebuffer address as struct dma_buf_map, and uses dma_buf_map > >> interfaces to access the buffer. > >> > >> The bochs driver on sparc64 uses a workaround to flag the framebuffer as > >> I/O memory and avoid a HW exception. With the introduction of struct > >> dma_buf_map, this is not required any longer. The patch removes the rsp > >> code from both, bochs and fbdev. > >> > >> v5: > >>* implement fb_read/fb_write internally (Daniel, Sam) > >> v4: > >>* move dma_buf_map changes into separate patch (Daniel) > >>* TODO list: comment on fbdev updates (Daniel) > >> > >> Signed-off-by: Thomas Zimmermann > >> Tested-by: Sam Ravnborg > >> --- > >> Documentation/gpu/todo.rst| 19 ++- > >> drivers/gpu/drm/bochs/bochs_kms.c | 1 - > >> drivers/gpu/drm/drm_fb_helper.c | 227 -- > >> include/drm/drm_mode_config.h | 12 -- > >> 4 files changed, 230 insertions(+), 29 deletions(-) > >> > >> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > >> index 7e6fc3c04add..638b7f704339 100644 > >> --- a/Documentation/gpu/todo.rst > >> +++ b/Documentation/gpu/todo.rst > >> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup() > >> > >> > >> Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > >> -atomic modesetting and GEM vmap support. Current generic fbdev emulation > >> -expects the framebuffer in system memory (or system-like memory). > >> +atomic modesetting and GEM vmap support. Historically, generic fbdev > >> emulation > >> +expected the framebuffer in system memory or system-like memory. By > >> employing > >> +struct dma_buf_map, drivers with frambuffers in I/O memory can be > >> supported > >> +as well. > >> > >> Contact: Maintainer of the driver you plan to convert > >> > >> Level: Intermediate > >> > >> +Reimplement functions in drm_fbdev_fb_ops without fbdev > >> +--- > >> + > >> +A number of callback functions in drm_fbdev_fb_ops could benefit from > >> +being rewritten without dependencies on the fbdev module. Some of the > >> +helpers could further benefit from using struct dma_buf_map instead of > >> +raw pointers. > >> + > >> +Contact: Thomas Zimmermann , Daniel Vetter > >> + > >> +Level: Advanced > >> + > >> + > >> drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup > >> - > >> > >> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c > >> b/drivers/gpu/drm/bochs/bochs_kms.c > >> index 13d0d04c4457..853081d186d5 100644 > >> --- a/drivers/gpu/drm/bochs/bochs_kms.c > >> +++ b/drivers/gpu/drm/bochs/bochs_kms.c > >> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs) > >>bochs->dev->mode_config.preferred_depth = 24; > >>bochs->dev->mode_config.prefer_shadow = 0; > >>bochs->dev->mode_config.prefer_shadow_fbdev = 1; > >> - bochs->dev->mode_config.fbdev_use_iomem = true; > >>bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true; > >> > >>bochs->dev->mode_config.funcs = &bochs_mode_funcs; > >> diff --git a/drivers/gpu/drm/drm_fb_helper.c > >> b/drivers/gpu/drm/drm_fb_helper.c > >> index 6212cd7cde1d..1d3180841778 100644 > >> --- a/drivers/gpu/drm/drm_fb_helper.c > >> +++ b/drivers/gpu/drm/drm_fb_helper.c > >> @@ -372,24 +372,22 @
Re: [PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 22.10.20 10:49, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> >> Kernel DRM clients now store their framebuffer address in an instance
> >> of struct dma_buf_map. Depending on the buffer's location, the address
> >> refers to system or I/O memory.
> >>
> >> Callers of drm_client_buffer_vmap() receive a copy of the value in
> >> the call's supplied arguments. It can be accessed and modified with
> >> dma_buf_map interfaces.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Reviewed-by: Daniel Vetter
> >> Tested-by: Sam Ravnborg
> >> ---
> >> drivers/gpu/drm/drm_client.c| 34 +++--
> >> drivers/gpu/drm/drm_fb_helper.c | 23 +-
> >> include/drm/drm_client.h| 7 ---
> >> 3 files changed, 38 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> >> index ac0082bed966..fe573acf1067 100644
> >> --- a/drivers/gpu/drm/drm_client.c
> >> +++ b/drivers/gpu/drm/drm_client.c
> >> @@ -235,7 +235,7 @@ static void drm_client_buffer_delete(struct
> >> drm_client_buffer *buffer)
> >> {
> >> struct drm_device *dev = buffer->client->dev;
> >>
> >> -drm_gem_vunmap(buffer->gem, buffer->vaddr);
> >> +drm_gem_vunmap(buffer->gem, &buffer->map);
> >>
> >> if (buffer->gem)
> >> drm_gem_object_put(buffer->gem);
> >> @@ -291,25 +291,31 @@ drm_client_buffer_create(struct drm_client_dev
> >> *client, u32 width, u32 height, u
> >> /**
> >> * drm_client_buffer_vmap - Map DRM client buffer into address space
> >> * @buffer: DRM client buffer
> >> + * @map_copy: Returns the mapped memory's address
> >> *
> >> * This function maps a client buffer into kernel address space. If the
> >> - * buffer is already mapped, it returns the mapping's address.
> >> + * buffer is already mapped, it returns the existing mapping's address.
> >> *
> >> * Client buffer mappings are not ref'counted. Each call to
> >> * drm_client_buffer_vmap() should be followed by a call to
> >> * drm_client_buffer_vunmap(); or the client buffer should be mapped
> >> * throughout its lifetime.
> >> *
> >> + * The returned address is a copy of the internal value. In contrast to
> >> + * other vmap interfaces, you don't need it for the client's vunmap
> >> + * function. So you can modify it at will during blit and draw operations.
> >> + *
> >> * Returns:
> >> - * The mapped memory's address
> >> + * 0 on success, or a negative errno code otherwise.
> >> */
> >> -void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
> >> +int
> >> +drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct
> >> dma_buf_map *map_copy)
> >> {
> >> -struct dma_buf_map map;
> >> +struct dma_buf_map *map = &buffer->map;
> >> int ret;
> >>
> >> -if (buffer->vaddr)
> >> -return buffer->vaddr;
> >> +if (dma_buf_map_is_set(map))
> >> +goto out;
> >>
> >> /*
> >> * FIXME: The dependency on GEM here isn't required, we could
> >> @@ -319,13 +325,14 @@ void *drm_client_buffer_vmap(struct
> >> drm_client_buffer *buffer)
> >> * fd_install step out of the driver backend hooks, to make that
> >> * final step optional for internal users.
> >> */
> >> -ret = drm_gem_vmap(buffer->gem, &map);
> >> +ret = drm_gem_vmap(buffer->gem, map);
> >> if (ret)
> >> -return ERR_PTR(ret);
> >> +return ret;
> >>
> >> -buffer->vaddr = map.vaddr;
> >> +out:
> >> +*map_copy = *map;
> >>
> >> -return map.vaddr;
> >> +return 0;
> >> }
> >> EXPORT_SYMBOL(drm_client_buffer_vmap);
> >>
> >> @@ -339,10 +346,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
> >> */
> >> void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
> >> {
> >> -struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->va
[PATCH 5/5] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed, 75 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index cc5b5915bc5e..d04008f3e31a 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -58,7 +58,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data) return status; } -stat
[PATCH] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed, 75 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index cc5b5915bc5e..d04008f3e31a 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_
Re: [PATCH] drm/: Constify struct drm_driver
On Sun, Oct 25, 2020 at 11:23 PM Sam Ravnborg wrote: > > Hi Daniel. > > On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > > platforms where it's supported (i.e. again driver_feature mangling) > > - vc4, again because of driver_feature mangling > > - qxl, because the ioctl table is somewhere else and moving that is > > maybe a bit too much, hence the num_ioctls assignment prevents a > > const driver structure. > My grepping turned up the following: > - The example in drm_drv needs to be updated > - legacy drivers, that are obviously not converted - but worth to > mention above > - arc is not converted and it is not legacy > Maybe you have it covered in your big arc conversion patch? Yeah I excluded that one because it's stuck behind my arcpgu tinification. I'll update the commit message to mention that with your other suggestions. -Daniel > > With the above fixed: > Acked-by: Sam Ravnborg > > > > Note that for armada I also went ahead and made the ioctl array const. > > > > Only cc'ing the driver people who've not been converted (everyone else > > is way too much). > > > > v2: Fix one misplaced const static, should be static const (0day) > > > > Cc: kernel test robot > > Acked-by: Maxime Ripard > > Signed-off-by: Daniel Vetter > > Cc: Dave Airlie > > Cc: Gerd Hoffmann > > Cc: virtualization@lists.linux-foundation.org > > Cc: Harry Wentland > > Cc: Leo Li > > Cc: Alex Deucher > > Cc: Christian König > > Cc: Eric Anholt > > Cc: Maxime Ripard > > Cc: Ben Skeggs > > Cc: nouv...@lists.freedesktop.org > > Signed-off-by: Daniel Vetter > > Hmm, so we have more than one Daniel in play here. > Both the Intel guy and the ffwll guy - looks funny. > > Sam > > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 7 +++ > > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- > > drivers/gpu/drm/ast/ast_drv.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.h| 2 +- > > drivers/gpu/drm/ast/ast_main.c | 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c| 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- > > drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- > > drivers/gpu/drm/imx/imx-drm-core.c | 2 +- > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- > > drivers/gpu/drm/lima/lima_drv.c | 2 +- > > drivers/gpu/drm/mcde/mcde_drv.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > > drivers/gpu/drm/meson/meson_drv.c| 2 +- > > drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- > > drivers/gpu/drm/msm/msm_drv.c| 4 ++-- > > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- > > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > drivers/gpu/drm/pl111/pl111_drv.c| 2 +- > > drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > > drivers/gpu/drm/sti/sti_drv.c| 2 +- > > drivers/gpu/drm/stm/drv.c| 2 +- > > drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- > > drivers/gpu/drm/tegra/drm.c | 5 ++--- > > drivers/gpu/drm/tidss/tidss_drv.c| 2 +- > > drivers/gpu
Re: [PATCH 5/5] drm/: Constify struct drm_driver
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann wrote: > > Hi > > Am 23.10.20 um 14:28 schrieb Daniel Vetter: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > > platforms where it's supported (i.e. again driver_feature mangling) > > - vc4, again because of driver_feature mangling > > - qxl, because the ioctl table is somewhere else and moving that is > > maybe a bit too much, hence the num_ioctls assignment prevents a > > const driver structure. > > > > Note that for armada I also went ahead and made the ioctl array const. > > > > Only cc'ing the driver people who've not been converted (everyone else > > is way too much). > > > > Signed-off-by: Daniel Vetter > > Cc: Dave Airlie > > Cc: Gerd Hoffmann > > Cc: virtualization@lists.linux-foundation.org > > Cc: Harry Wentland > > Cc: Leo Li > > Cc: Alex Deucher > > Cc: Christian König > > Cc: Eric Anholt > > Cc: Maxime Ripard > > Cc: Ben Skeggs > > Cc: nouv...@lists.freedesktop.org > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 7 +++ > > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- > > drivers/gpu/drm/ast/ast_drv.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.h| 2 +- > > drivers/gpu/drm/ast/ast_main.c | 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c| 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- > > drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- > > drivers/gpu/drm/i915/i915_drv.c | 4 ++-- > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- > > drivers/gpu/drm/imx/imx-drm-core.c | 2 +- > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- > > drivers/gpu/drm/lima/lima_drv.c | 2 +- > > drivers/gpu/drm/mcde/mcde_drv.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- > > drivers/gpu/drm/meson/meson_drv.c| 2 +- > > drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- > > drivers/gpu/drm/msm/msm_drv.c| 4 ++-- > > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- > > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- > > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > drivers/gpu/drm/pl111/pl111_drv.c| 2 +- > > drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > > drivers/gpu/drm/sti/sti_drv.c| 2 +- > > drivers/gpu/drm/stm/drv.c| 2 +- > > drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- > > drivers/gpu/drm/tegra/drm.c | 5 ++--- > > drivers/gpu/drm/tidss/tidss_drv.c| 2 +- > > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- > > drivers/gpu/drm/tiny/cirrus.c| 2 +- > > drivers/gpu/drm/tiny/gm12u320.c | 2 +- > > drivers/gpu/drm/tiny/hx8357d.c | 2 +- > > drivers/gpu/drm/tiny/ili9225.c | 2 +- > > drivers/gpu/drm/tiny/ili9341.c | 2 +- > > drivers/gpu/drm/tiny/ili9486.c | 2 +- > > drivers/gpu/drm/tiny/mi0283qt.c | 2 +- > > drivers/gpu/drm/tiny/repaper.c | 2 +- > > drivers/gpu/drm/tiny/st7586.c| 2 +- > > drivers/gpu/drm/tiny/st7735r.c | 2 +- > > drivers/gpu/drm/tve200/tve200_drv.c | 2 +- > > drivers/gpu/drm/udl/udl_drv.c| 2 +- >
Re: [PATCH 6/8] drm: atomic: use krealloc_array()
On Tue, Oct 27, 2020 at 01:17:23PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Use the helper that checks for overflows internally instead of manually > calculating the size of the new array. > > Signed-off-by: Bartosz Golaszewski Acked-by: Daniel Vetter I don't expect conflicts with this going through some other tree, so please make that happen. Or resend once I can apply this to drm trees. Thanks, Daniel > --- > drivers/gpu/drm/drm_atomic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 58527f151984..09ad6a2ec17b 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -960,7 +960,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state > *state, > struct __drm_connnectors_state *c; > int alloc = max(index + 1, config->num_connector); > > - c = krealloc(state->connectors, alloc * > sizeof(*state->connectors), GFP_KERNEL); > + c = krealloc_array(state->connectors, alloc, > +sizeof(*state->connectors), GFP_KERNEL); > if (!c) > return ERR_PTR(-ENOMEM); > > -- > 2.29.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 3/3] drm/qxl: Remove fbcon acceleration leftovers
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
emulation code").
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 3602e8b34189..86eee66ecbad 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -166,20 +166,6 @@ struct qxl_drm_image {
struct list_head chunk_list;
};
-struct qxl_fb_image {
- struct qxl_device *qdev;
- uint32_t pseudo_palette[16];
- struct fb_image fb_image;
- uint32_t visual;
-};
-
-struct qxl_draw_fill {
- struct qxl_device *qdev;
- struct qxl_rect rect;
- uint32_t color;
- uint16_t rop;
-};
-
/*
* Debugfs
*/
--
2.28.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm/qxl: Remove fbcon acceleration leftovers
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
emulation code").
v2: Somehow these structs provided the struct qxl_device pre-decl,
reorder the header to not anger compilers.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.h | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 3602e8b34189..6239626503ef 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -166,20 +166,6 @@ struct qxl_drm_image {
struct list_head chunk_list;
};
-struct qxl_fb_image {
- struct qxl_device *qdev;
- uint32_t pseudo_palette[16];
- struct fb_image fb_image;
- uint32_t visual;
-};
-
-struct qxl_draw_fill {
- struct qxl_device *qdev;
- struct qxl_rect rect;
- uint32_t color;
- uint16_t rop;
-};
-
/*
* Debugfs
*/
@@ -188,8 +174,6 @@ struct qxl_debugfs {
unsigned int num_files;
};
-int qxl_debugfs_fence_init(struct qxl_device *rdev);
-
struct qxl_device {
struct drm_device ddev;
@@ -271,6 +255,8 @@ struct qxl_device {
#define to_qxl(dev) container_of(dev, struct qxl_device, ddev)
+int qxl_debugfs_fence_init(struct qxl_device *rdev);
+
extern const struct drm_ioctl_desc qxl_ioctls[];
extern int qxl_max_ioctl;
--
2.28.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 5/5] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. - arcpgu, because that is stuck behind a pending tiny-fication series from me. - legacy drivers, because legacy requires non-const drm_driver. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) v3: - Improve commit message (Sam) Acked-by: Sam Ravnborg Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed, 75 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/dr
[PATCH 5/6] drm/: Constify struct drm_driver
Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too much, hence the num_ioctls assignment prevents a const driver structure. - arcpgu, because that is stuck behind a pending tiny-fication series from me. - legacy drivers, because legacy requires non-const drm_driver. Note that for armada I also went ahead and made the ioctl array const. Only cc'ing the driver people who've not been converted (everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) v3: - Improve commit message (Sam) Acked-by: Sam Ravnborg Cc: kernel test robot Acked-by: Maxime Ripard Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 7 +++ drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.c| 2 +- drivers/gpu/drm/ast/ast_drv.h| 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++--- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +- drivers/gpu/drm/lima/lima_drv.c | 2 +- drivers/gpu/drm/mcde/mcde_drv.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +- drivers/gpu/drm/meson/meson_drv.c| 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++-- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/stm/drv.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +- drivers/gpu/drm/tegra/drm.c | 5 ++--- drivers/gpu/drm/tidss/tidss_drv.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c| 2 +- drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c | 2 +- drivers/gpu/drm/tiny/ili9225.c | 2 +- drivers/gpu/drm/tiny/ili9341.c | 2 +- drivers/gpu/drm/tiny/ili9486.c | 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c | 2 +- drivers/gpu/drm/tiny/st7586.c| 2 +- drivers/gpu/drm/tiny/st7735r.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c| 2 +- drivers/gpu/drm/v3d/v3d_drv.c| 2 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 2 +- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 63 files changed,
Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy from system memory and a
> >> pointer-increment function. Add both interfaces with documentation.
> >
> > (...)
> >> +/**
> >> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> >> + * @dst: The dma-buf mapping structure
> >> + * @src: The source buffer
> >> + * @len: The number of byte in src
> >> + *
> >> + * Copies data into a dma-buf mapping. The source buffer is in system
> >> + * memory. Depending on the buffer's location, the helper picks the
> >> correct
> >> + * method of accessing the memory.
> >> + */
> >> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const
> >> void *src, size_t len)
> >> +{
> >> + if (dst->is_iomem)
> >> + memcpy_toio(dst->vaddr_iomem, src, len);
> >> + else
> >> + memcpy(dst->vaddr, src, len);
> >> +}
> >
> > Are these going to be really big memcpy() operations?
>
> Individually, each could be a scanline, so a few KiB. (4 bytes *
> horizontal resolution). Updating a full framebuffer can sum up to
> several MiB.
>
> >
> > Some platforms have DMA offload engines that can perform memcpy(),They
> > could be
> > drivers/dma, include/linux/dmaengine.h
> > especially if the CPU doesn't really need to touch the contents
> > and flush caches etc.
> > An example exist in some MTD drivers that move large quantities of
> > data off flash memory like this:
> > drivers/mtd/nand/raw/cadence-nand-controller.c
> >
> > Notice that DMAengine and DMAbuf does not have much in common,
> > the names can be deceiving.
> >
> > The value of this varies with the system architecture. It is not just
> > a question about performance but also about power and the CPU
> > being able to do other stuff in parallel for large transfers. So *when*
> > to use this facility to accelerate memcpy() is a delicate question.
> >
> > What I'm after here is if these can be really big, do we want
> > (in the long run, not now) open up to the idea to slot in
> > hardware-accelerated memcpy() here?
>
> We currently use this functionality for the graphical framebuffer
> console that most DRM drivers provide. It's non-accelerated and slow,
> but this has not been much of a problem so far.
>
> Within DRM, we're more interested in removing console code from drivers
> and going for the generic implementation.
>
> Most of the graphics HW allocates framebuffers from video RAM, system
> memory or CMA pools and does not really need these memcpys. Only a few
> systems with small video RAM require a shadow buffer, which we flush
> into VRAM as needed. Those might benefit.
>
> OTOH, off-loading memcpys to hardware sounds reasonable if we can hide
> it from the DRM code. I think it all depends on how invasive that change
> would be.
I wouldn't, all the additional locks this would pull in sound like
nightmare. And when an oops happens, this might be the only thing that
manages to get the oops to the user.
Unless someone really starts caring about fbcon acceleration I really
wouldn't bother. Ok maybe it also matters for fbdev, but the problem is
that the page fault intercepting alone is already expensive, so the only
real solution if you care about performance in that case is to use kms
natively, and use a dirty rectangle flip (or the DIRTY syscall).
And in there drivers should (and do) use any dma engines they have to
upload the frames already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/qxl: Remove fbcon acceleration leftovers
On Thu, Oct 29, 2020 at 02:33:47PM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
>
> v2: Somehow these structs provided the struct qxl_device pre-decl,
> reorder the header to not anger compilers.
>
> Acked-by: Gerd Hoffmann
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
Entire series applied to drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_drv.h | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 3602e8b34189..6239626503ef 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -166,20 +166,6 @@ struct qxl_drm_image {
> struct list_head chunk_list;
> };
>
> -struct qxl_fb_image {
> - struct qxl_device *qdev;
> - uint32_t pseudo_palette[16];
> - struct fb_image fb_image;
> - uint32_t visual;
> -};
> -
> -struct qxl_draw_fill {
> - struct qxl_device *qdev;
> - struct qxl_rect rect;
> - uint32_t color;
> - uint16_t rop;
> -};
> -
> /*
> * Debugfs
> */
> @@ -188,8 +174,6 @@ struct qxl_debugfs {
> unsigned int num_files;
> };
>
> -int qxl_debugfs_fence_init(struct qxl_device *rdev);
> -
> struct qxl_device {
> struct drm_device ddev;
>
> @@ -271,6 +255,8 @@ struct qxl_device {
>
> #define to_qxl(dev) container_of(dev, struct qxl_device, ddev)
>
> +int qxl_debugfs_fence_init(struct qxl_device *rdev);
> +
> extern const struct drm_ioctl_desc qxl_ioctls[];
> extern int qxl_max_ioctl;
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > > > > > On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > > > > Hi > > > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >> Hi > >> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>> > >>> > >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann wrote: > >>>> > >>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>> drm_device.dev. No functional changes. > >>>> > >>>> Signed-off-by: Thomas Zimmermann > >>>> Cc: Roland Scheidegger > >>>> --- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>> > >>> Reviewed-by: Zack Rusin > >> Could you add this patch to the vmwgfx tree? > > > > AMD devs indicated that they'd prefer to merge the patchset trough > > drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > > drm-misc-next as well. > > Sounds good. I’ll make sure to rebase our latest patch set on top of it when > it’s in. Thanks! btw if you want to avoid multi-tree coordination headaches, we can also manage vmwgfx in drm-misc and give you & Roland commit rights there. Up to you. There is some scripting involved for now (but I hope whenever we move to gitlab we could do the checks server-side): https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann wrote: > >>> > >>> Hi > >>> > >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >>>> Hi > >>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>>>> > >>>>> > >>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann > >>>>>> wrote: > >>>>>> > >>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>>>> drm_device.dev. No functional changes. > >>>>>> > >>>>>> Signed-off-by: Thomas Zimmermann > >>>>>> Cc: Roland Scheidegger > >>>>>> --- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>>>> > >>>>> Reviewed-by: Zack Rusin > >>>> Could you add this patch to the vmwgfx tree? > >>> > >>> AMD devs indicated that they'd prefer to merge the patchset trough > >>> drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through > >>> drm-misc-next as well. > >> > >> Sounds good. I’ll make sure to rebase our latest patch set on top of it > >> when it’s in. Thanks! > > > > btw if you want to avoid multi-tree coordination headaches, we can > > also manage vmwgfx in drm-misc and give you & Roland commit rights > > there. Up to you. There is some scripting involved for now (but I hope > > whenever we move to gitlab we could do the checks server-side): > > I’d be happy to take you up on that. I would like to move a lot more of > our development into public repos and reducing the burden of maintaining > multiple trees would help. Is there a lot of changes to drm core that > doesn’t go through drm-misc? Or alternatively is drm-misc often pulling > from Linus’ master? I’m trying to figure out how much would our need to > rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes > because that would also allow me to point some internal testing > infrastructure at it as well. I think nowadays pretty much all the cross-driver work lands through drm-misc. Exception is just new stuff that's only used by a single driver. For testing there's also drm-tip, which tries to pull it all together (but you might still want to point your CI at branches). Also note that drm-misc-next doesn't have a merge window freeze period (with have the drm-misc-next-fixes branch during that time for merge window fixes), so you can treat it like a main development branch like e.g. in mesa, with the -fixes branches as the release branches. Only difference is that we don't cherry pick patches from the main branch to the release branches (at least not as the normal flow). If you do need a backmerge for patches from Linus to drm-misc-next because of some feature work (or conflicts with other stuff in general) drm-misc maintainers do that. Usually happens every few weeks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations
*map); > void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); > + > + /** > + * @vmap_local: > + * > + * Creates a virtual mapping for the buffer into kernel address space. > + * > + * This callback establishes short-term mappings for situations where > + * callers only use the buffer for a bounded amount of time; such as > + * updates to the framebuffer or reading back contained information. > + * In contrast to the regular @vmap callback, vmap_local does never pin > + * the buffer to a specific domain or acquire the buffer's reservation > + * lock. > + * > + * This is called with the dmabuf->resv object locked. Callers must hold ^^Not the right kerneldoc, I think it should be &dma_buf.resv to get the hyperlink. > + * the lock until after removing the mapping with @vunmap_local. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. > + */ > + int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > + > + /** > + * @vunmap_local: > + * > + * Removes a virtual mapping that wa sestablished by @vmap_local. ^^established > + * > + * This callback is optional. > + */ > + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > }; > > /** > @@ -506,4 +538,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct > *, >unsigned long); > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > #endif /* __DMA_BUF_H__ */ With the doc nits addressed: Reviewed-by: Daniel Vetter > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 4/8] drm/gem: Create infrastructure for GEM vmap_local
mmap = drm_gem_dmabuf_mmap,
> .vmap = drm_gem_dmabuf_vmap,
> .vunmap = drm_gem_dmabuf_vunmap,
> + .vmap_local = drm_gem_dmabuf_vmap_local,
> + .vunmap_local = drm_gem_dmabuf_vunmap_local,
> };
>
> /**
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index 807a27a16365..fea11a53d8fc 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -54,6 +54,8 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops =
> {
> .mmap = drm_gem_dmabuf_mmap,
> .vmap = drm_gem_dmabuf_vmap,
> .vunmap = drm_gem_dmabuf_vunmap,
> + .vmap = drm_gem_dmabuf_vmap_local,
> + .vunmap = drm_gem_dmabuf_vunmap_local,
> },
> .device_attach = drm_gem_map_attach,
> .get_uuid = virtgpu_virtio_get_uuid,
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 5e6daa1c982f..1281f26de494 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -151,6 +151,26 @@ struct drm_gem_object_funcs {
>*/
> void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>
> + /**
> + * @vmap_local:
> + *
> + * Returns a virtual address for the buffer. Used by the
> + * drm_gem_dmabuf_vmap_local() helper.
I'd add "Callers will hold &drm_gem_object.resv already and only release
it after @vunmap is called" (and pls check I typed this correctly for the
linking).
Either way: Reviewed-by: Daniel Vetter
> + *
> + * This callback is optional.
> + */
> + int (*vmap_local)(struct drm_gem_object *obj, struct dma_buf_map *map);
> +
> + /**
> + * @vunmap_local:
> + *
> + * Releases the address previously returned by @vmap. Used by the
> + * drm_gem_dmabuf_vunmap_local() helper.
> + *
> + * This callback is optional.
> + */
> + void (*vunmap_local)(struct drm_gem_object *obj, struct dma_buf_map
> *map);
> +
> /**
>* @mmap:
>*
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index 54f2c58305d2..fd2aef6966ef 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -85,6 +85,8 @@ void drm_gem_unmap_dma_buf(struct dma_buf_attachment
> *attach,
> enum dma_data_direction dir);
> int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map);
> void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, struct dma_buf_map *map);
> +int drm_gem_dmabuf_vmap_local(struct dma_buf *dma_buf, struct dma_buf_map
> *map);
> +void drm_gem_dmabuf_vunmap_local(struct dma_buf *dma_buf, struct dma_buf_map
> *map);
>
> int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
> *vma);
> int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings
On Wed, Dec 09, 2020 at 03:25:24PM +0100, Thomas Zimmermann wrote:
> Implementations of the vmap/vunmap GEM callbacks may perform pinning
> of the BO and may acquire the associated reservation object's lock.
> Callers that only require a mapping of the contained memory can thus
> interfere with other tasks that require exact pinning, such as scanout.
> This is less of an issue with private CMA buffers, but may happen
> with imported ones.
>
> Therefore provide the new interface drm_gem_cma_vmap_local(), which only
> performs the vmap operations. Callers have to hold the reservation lock
> while the mapping persists.
>
> This patch also connects GEM CMA helpers to the GEM object function with
> equivalent functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 35
> drivers/gpu/drm/vc4/vc4_bo.c | 13 +++
> drivers/gpu/drm/vc4/vc4_drv.h| 1 +
> include/drm/drm_gem_cma_helper.h | 1 +
> 4 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 7942cf05cd93..40b3e8e3fc42 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs
> drm_gem_cma_default_funcs = {
> .print_info = drm_gem_cma_print_info,
> .get_sg_table = drm_gem_cma_get_sg_table,
> .vmap = drm_gem_cma_vmap,
> + .vmap_local = drm_gem_cma_vmap_local,
> .mmap = drm_gem_cma_mmap,
> .vm_ops = &drm_gem_cma_vm_ops,
> };
> @@ -471,6 +472,40 @@ int drm_gem_cma_vmap(struct drm_gem_object *obj, struct
> dma_buf_map *map)
> }
> EXPORT_SYMBOL_GPL(drm_gem_cma_vmap);
>
> +/**
> + * drm_gem_cma_vmap_local - map a CMA GEM object into the kernel's virtual
> + * address space
> + * @obj: GEM object
> + * @map: Returns the kernel virtual address of the CMA GEM object's backing
> + * store.
> + *
> + * This function maps a buffer into the kernel's
> + * virtual address space. Since the CMA buffers are already mapped into the
> + * kernel virtual address space this simply returns the cached virtual
> + * address. Drivers using the CMA helpers should set this as their DRM
> + * driver's &drm_gem_object_funcs.vmap_local callback.
> + *
> + * Returns:
> + * 0 on success, or a negative error code otherwise.
> + */
> +int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
> *map)
> +{
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> +
> + /*
> + * TODO: The code in drm_gem_cma_prime_import_sg_table_vmap()
> + * establishes this mapping. The correct solution would
> + * be to call dma_buf_vmap_local() here.
> + *
> + * If we find a case where we absolutely have to call
> + * dma_buf_vmap_local(), the code needs to be restructured.
dma_buf_vmap_local is only relevant for dynamic importers, pinning at
import time is actually what you get anyway. That's what Christian meant
with his comments for the ->pin hook. So the TODO here doesn't make sense
imo, just delete it. We're very far away from making cma dynamic :-)
> + */
> + dma_buf_map_set_vaddr(map, cma_obj->vaddr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_vmap_local);
> +
> /**
> * drm_gem_cma_mmap - memory-map an exported CMA GEM object
> * @obj: GEM object
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index dc316cb79e00..ec57326c69c4 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -387,6 +387,7 @@ static const struct drm_gem_object_funcs
> vc4_gem_object_funcs = {
> .export = vc4_prime_export,
> .get_sg_table = drm_gem_cma_get_sg_table,
> .vmap = vc4_prime_vmap,
> + .vmap_local = vc4_prime_vmap_local,
> .vm_ops = &vc4_vm_ops,
> };
>
> @@ -797,6 +798,18 @@ int vc4_prime_vmap(struct drm_gem_object *obj, struct
> dma_buf_map *map)
> return drm_gem_cma_vmap(obj, map);
> }
>
> +int vc4_prime_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
> +{
> + struct vc4_bo *bo = to_vc4_bo(obj);
> +
> + if (bo->validated_shader) {
This freaks me out. It should be impossible to export a validated shader
as a dma-buf, and indeed the check exists already.
All the wrapper functions here are imo pointless. Either we should remove
them, or replace the if with a BUG_ON here since if that ever happens we
have a security bug already. I'd go with removing, l
Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings
On Wed, Dec 09, 2020 at 03:25:25PM +0100, Thomas Zimmermann wrote:
> Implementations of the vmap/vunmap GEM callbacks may perform pinning
> of the BO and may acquire the associated reservation object's lock.
> Callers that only require a mapping of the contained memory can thus
> interfere with other tasks that require exact pinning, such as scanout.
> This is less of an issue with private SHMEM buffers, but may happen
> with imported ones.
>
> Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
> drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
> operations. Callers have to hold the reservation lock while the mapping
> persists.
>
> The affected callers are display updates in cirrus, gm12u320, mgag200
> and udl. All are being changed to the new interface.
>
> This patch also connects GEM SHMEM helpers to GEM object functions with
> equivalent functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 71 +-
> drivers/gpu/drm/mgag200/mgag200_mode.c | 16 --
> drivers/gpu/drm/tiny/cirrus.c | 10 +++-
> drivers/gpu/drm/tiny/gm12u320.c| 14 +++--
> drivers/gpu/drm/udl/udl_modeset.c | 18 ---
I think that's a bit much driver conversion. I'd say in general split
these out from the patch that adds the new functionality. More
importantly, since vmap_local is optional, you can only start using it
once all drivers have it. Especially with udl this will break use-cases
otherwise, but also probably with gm12u320.
> include/drm/drm_gem_shmem_helper.h | 2 +
> 6 files changed, 115 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 9825c378dfa6..41663f48d46a 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs
> drm_gem_shmem_funcs = {
> .get_sg_table = drm_gem_shmem_get_sg_table,
> .vmap = drm_gem_shmem_vmap,
> .vunmap = drm_gem_shmem_vunmap,
> + .vmap_local = drm_gem_shmem_vmap_local,
> + .vunmap_local = drm_gem_shmem_vunmap_local,
> .mmap = drm_gem_shmem_mmap,
> };
>
> @@ -313,7 +315,7 @@ static int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem, struct
> return ret;
> }
>
> -/*
> +/**
> * drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
> * @shmem: shmem GEM object
> * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
> @@ -346,6 +348,44 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj,
> struct dma_buf_map *map)
> }
> EXPORT_SYMBOL(drm_gem_shmem_vmap);
>
> +/**
> + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
> + * @shmem: shmem GEM object
> + * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
> + * store.
> + *
> + * This function makes sure that a contiguous kernel virtual address mapping
> + * exists for the buffer backing the shmem GEM object.
> + *
> + * The function is called with the BO's reservation object locked. Callers
> must
> + * hold the lock until after unmapping the buffer.
> + *
> + * This function can be used to implement &drm_gem_object_funcs.vmap_local.
> But
> + * it can also be called by drivers directly, in which case it will hide the
> + * differences between dma-buf imported and natively allocated objects.
> + *
> + * Acquired mappings should be cleaned up by calling
> drm_gem_shmem_vunmap_local().
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
> *map)
> +{
> + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> + int ret;
> +
> + dma_resv_assert_held(obj->resv);
> +
> + ret = mutex_lock_interruptible(&shmem->vmap_lock);
This bites. You need to check for shmem->import_attach and call
dma_buf_vmap_local directly here before you take any shmem helper locks.
Real fix would be to replace both vmap_lock and pages_lock with dma_resv
lock, but that's more work. Same for vunmap_local
With that fixed on the helper part of this patch:
Reviewed-by: Daniel Vetter
> + if (ret)
> + return ret;
> + ret = drm_gem_shmem_vmap_locked(shmem, map);
> + mutex_unlock(&shmem->vmap_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
> +
> static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
>
Re: [PATCH v3 7/8] drm/vram-helper: Provide a vmap function for short-term mappings
p.vaddr_iomem; /* TODO: Use mapping abstraction properly */
>
> sig = dst + AST_HWC_SIZE;
> writel(x, sig + AST_HWC_SIGNATURE_X);
> writel(y, sig + AST_HWC_SIGNATURE_Y);
>
> - drm_gem_vram_vunmap(gbo, &map);
> + drm_gem_vram_vunmap_local(gbo, &map);
> + dma_resv_unlock(obj->resv);
>
> if (x < 0) {
> x_offset = (-x) + offset_x;
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 02ca22e90290..08a713993896 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -379,47 +379,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_unpin);
>
> -static int drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
> - struct dma_buf_map *map)
> -{
> - int ret;
> -
> - if (gbo->vmap_use_count > 0)
> - goto out;
> -
> - ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
> - if (ret)
> - return ret;
> -
> -out:
> - ++gbo->vmap_use_count;
> - *map = gbo->map;
> -
> - return 0;
> -}
> -
> -static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo,
> -struct dma_buf_map *map)
> -{
> - struct drm_device *dev = gbo->bo.base.dev;
> -
> - if (drm_WARN_ON_ONCE(dev, !gbo->vmap_use_count))
> - return;
> -
> - if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
> - return; /* BUG: map not mapped from this BO */
> -
> - if (--gbo->vmap_use_count > 0)
> - return;
> -
> - /*
> - * Permanently mapping and unmapping buffers adds overhead from
> - * updating the page tables and creates debugging output. Therefore,
> - * we delay the actual unmap operation until the BO gets evicted
> - * from memory. See drm_gem_vram_bo_driver_move_notify().
> - */
> -}
> -
> /**
> * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
> * space
> @@ -447,7 +406,7 @@ int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo,
> struct dma_buf_map *map)
> ret = drm_gem_vram_pin_locked(gbo, 0);
> if (ret)
> goto err_ttm_bo_unreserve;
> - ret = drm_gem_vram_kmap_locked(gbo, map);
> + ret = drm_gem_vram_vmap_local(gbo, map);
> if (ret)
> goto err_drm_gem_vram_unpin_locked;
>
> @@ -479,13 +438,84 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object
> *gbo, struct dma_buf_map *ma
> if (WARN_ONCE(ret, "ttm_bo_reserve_failed(): ret=%d\n", ret))
> return;
>
> - drm_gem_vram_kunmap_locked(gbo, map);
> + drm_gem_vram_vunmap_local(gbo, map);
> drm_gem_vram_unpin_locked(gbo);
>
> ttm_bo_unreserve(&gbo->bo);
> }
> EXPORT_SYMBOL(drm_gem_vram_vunmap);
>
> +/**
> + * drm_gem_vram_vmap_local() - Maps a GEM VRAM object into kernel address
> space
> + * @gbo: The GEM VRAM object to map
> + * @map: Returns the kernel virtual address of the VRAM GEM object's backing
> + * store.
> + *
> + * The vmap_local function maps the buffer of a GEM VRAM object into kernel
> address
> + * space. Call drm_gem_vram_vunmap_local() with the returned address to
> unmap and
> + * unpin the GEM VRAM object.
> + *
> + * The function is called with the BO's reservation object locked. For
> short-term
> + * mappings, callers must hold the lock until after unmapping the buffer. For
"the lock" is unclear, please mention the exact lock and maybe how to lock
it. This is the first time we have a vram helper function which requires
callers to lock, so better safe than sorry :-)
> + * long-term mappings, callers are required to pin the BO to it's current
> location
> + * before calling this function.
With the dma_resv_assert_held the 2nd use-case kinda doesn't work, since
there we'd access without the dma_resv_lock. I'd just drop that
sentence.
For the vram helper part, with the kerneldoc polished:
Reviewed-by: Daniel Vetter
> + *
> + * Returns:
> + * 0 on success, or a negative error code otherwise.
> + */
> +int drm_gem_vram_vmap_local(struct drm_gem_vram_object *gbo, struct
> dma_buf_map *map)
> +{
> + int ret;
> +
> + dma_resv_assert_held(gbo->bo.base.resv);
> +
> + if (gbo->vmap_use_count > 0)
> + goto out;
> +
> + ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
> + if (ret)
> +
Re: [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker
On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote:
> Fbdev emulation has to lock the BO into place while flushing the shadow
> buffer into the BO's memory. Remove any interference with pinning by
> using vmap_local functionality (instead of full vmap). This requires
> BO reservation locking in fbdev's damage worker.
>
> The new DRM client functions for locking and vmap_local functionality
> are added for consistency with the existing style.
>
> Signed-off-by: Thomas Zimmermann
The old vmap/vunmap in the client library aren't used anymore, please
delete. That will also make it clearer in the diff what's going on and
that it makes sense to have the client and fb-helper part in one patch.
With that: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_client.c| 91 +
> drivers/gpu/drm/drm_fb_helper.c | 41 +++
> include/drm/drm_client.h| 4 ++
> 3 files changed, 116 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index ce45e380f4a2..795f5cb052ba 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client,
> u32 width, u32 height, u
> return ERR_PTR(ret);
> }
>
> +/**
> + * drm_client_buffer_lock - Locks the DRM client buffer
> + * @buffer: DRM client buffer
> + *
> + * This function locks the client buffer by acquiring the buffer
> + * object's reservation lock.
> + *
> + * Unlock the buffer with drm_client_buffer_unlock().
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + */
> +int
> +drm_client_buffer_lock(struct drm_client_buffer *buffer)
> +{
> + return dma_resv_lock(buffer->gem->resv, NULL);
> +}
> +EXPORT_SYMBOL(drm_client_buffer_lock);
> +
> +/**
> + * drm_client_buffer_unlock - Unlock DRM client buffer
> + * @buffer: DRM client buffer
> + *
> + * Unlocks a client buffer. See drm_client_buffer_lock().
> + */
> +void drm_client_buffer_unlock(struct drm_client_buffer *buffer)
> +{
> + dma_resv_unlock(buffer->gem->resv);
> +}
> +EXPORT_SYMBOL(drm_client_buffer_unlock);
> +
> /**
> * drm_client_buffer_vmap - Map DRM client buffer into address space
> * @buffer: DRM client buffer
> @@ -348,6 +379,66 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
> *buffer)
> }
> EXPORT_SYMBOL(drm_client_buffer_vunmap);
>
> +/**
> + * drm_client_buffer_vmap_local - Map DRM client buffer into address space
> + * @buffer: DRM client buffer
> + * @map_copy: Returns the mapped memory's address
> + *
> + * This function maps a client buffer into kernel address space. If the
> + * buffer is already mapped, it returns the existing mapping's address.
> + *
> + * Client buffer mappings are not ref'counted. Each call to
> + * drm_client_buffer_vmap_local() should be followed by a call to
> + * drm_client_buffer_vunmap_local(); or the client buffer should be mapped
> + * throughout its lifetime.
> + *
> + * The returned address is a copy of the internal value. In contrast to
> + * other vmap interfaces, you don't need it for the client's vunmap
> + * function. So you can modify it at will during blit and draw operations.
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + */
> +int
> +drm_client_buffer_vmap_local(struct drm_client_buffer *buffer, struct
> dma_buf_map *map_copy)
> +{
> + struct dma_buf_map *map = &buffer->map;
> + int ret;
> +
> + /*
> + * FIXME: The dependency on GEM here isn't required, we could
> + * convert the driver handle to a dma-buf instead and use the
> + * backend-agnostic dma-buf vmap_local support instead. This would
> + * require that the handle2fd prime ioctl is reworked to pull the
> + * fd_install step out of the driver backend hooks, to make that
> + * final step optional for internal users.
> + */
> + ret = drm_gem_vmap_local(buffer->gem, map);
> + if (ret)
> + return ret;
> +
> + *map_copy = *map;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_client_buffer_vmap_local);
> +
> +/**
> + * drm_client_buffer_vunmap_local - Unmap DRM client buffer
> + * @buffer: DRM client buffer
> + *
> + * This function removes a client buffer's memory mapping. Calling this
> + * function is only required by clients that manage their buffer mappings
> + * by themselves.
> + */
> +void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer)
> +{
> + struct d
Re: [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings
On Fri, Dec 11, 2020 at 10:40:00AM +0100, Daniel Vetter wrote:
> On Wed, Dec 09, 2020 at 03:25:24PM +0100, Thomas Zimmermann wrote:
> > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> > of the BO and may acquire the associated reservation object's lock.
> > Callers that only require a mapping of the contained memory can thus
> > interfere with other tasks that require exact pinning, such as scanout.
> > This is less of an issue with private CMA buffers, but may happen
> > with imported ones.
> >
> > Therefore provide the new interface drm_gem_cma_vmap_local(), which only
> > performs the vmap operations. Callers have to hold the reservation lock
> > while the mapping persists.
> >
> > This patch also connects GEM CMA helpers to the GEM object function with
> > equivalent functionality.
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/drm_gem_cma_helper.c | 35
> > drivers/gpu/drm/vc4/vc4_bo.c | 13 +++
> > drivers/gpu/drm/vc4/vc4_drv.h| 1 +
> > include/drm/drm_gem_cma_helper.h | 1 +
> > 4 files changed, 50 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c
> > index 7942cf05cd93..40b3e8e3fc42 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs
> > drm_gem_cma_default_funcs = {
> > .print_info = drm_gem_cma_print_info,
> > .get_sg_table = drm_gem_cma_get_sg_table,
> > .vmap = drm_gem_cma_vmap,
> > + .vmap_local = drm_gem_cma_vmap_local,
> > .mmap = drm_gem_cma_mmap,
> > .vm_ops = &drm_gem_cma_vm_ops,
> > };
> > @@ -471,6 +472,40 @@ int drm_gem_cma_vmap(struct drm_gem_object *obj,
> > struct dma_buf_map *map)
> > }
> > EXPORT_SYMBOL_GPL(drm_gem_cma_vmap);
> >
> > +/**
> > + * drm_gem_cma_vmap_local - map a CMA GEM object into the kernel's virtual
> > + * address space
> > + * @obj: GEM object
> > + * @map: Returns the kernel virtual address of the CMA GEM object's backing
> > + * store.
> > + *
> > + * This function maps a buffer into the kernel's
> > + * virtual address space. Since the CMA buffers are already mapped into the
> > + * kernel virtual address space this simply returns the cached virtual
> > + * address. Drivers using the CMA helpers should set this as their DRM
> > + * driver's &drm_gem_object_funcs.vmap_local callback.
> > + *
> > + * Returns:
> > + * 0 on success, or a negative error code otherwise.
> > + */
> > +int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
> > *map)
> > +{
> > + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> > +
> > + /*
> > +* TODO: The code in drm_gem_cma_prime_import_sg_table_vmap()
> > +* establishes this mapping. The correct solution would
> > +* be to call dma_buf_vmap_local() here.
> > +*
> > +* If we find a case where we absolutely have to call
> > +* dma_buf_vmap_local(), the code needs to be restructured.
>
> dma_buf_vmap_local is only relevant for dynamic importers, pinning at
> import time is actually what you get anyway. That's what Christian meant
> with his comments for the ->pin hook. So the TODO here doesn't make sense
> imo, just delete it. We're very far away from making cma dynamic :-)
>
> > +*/
> > + dma_buf_map_set_vaddr(map, cma_obj->vaddr);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_gem_cma_vmap_local);
> > +
> > /**
> > * drm_gem_cma_mmap - memory-map an exported CMA GEM object
> > * @obj: GEM object
> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> > index dc316cb79e00..ec57326c69c4 100644
> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> > @@ -387,6 +387,7 @@ static const struct drm_gem_object_funcs
> > vc4_gem_object_funcs = {
> > .export = vc4_prime_export,
> > .get_sg_table = drm_gem_cma_get_sg_table,
> > .vmap = vc4_prime_vmap,
> > + .vmap_local = vc4_prime_vmap_local,
> > .vm_ops = &vc4_vm_ops,
> > };
> >
> > @@ -797,6 +798,18 @@ int vc4_prime_vmap(struct drm_gem_object *obj, struct
> > dma_buf_map *map)
> > return drm_gem_cma_vmap(obj, map);
> > }
> >
> &g
Re: [PATCH v3 1/8] drm/ast: Don't pin cursor source BO explicitly during update
On Wed, Dec 09, 2020 at 03:25:20PM +0100, Thomas Zimmermann wrote: > Vmapping the cursor source BO contains an implicit pin operation, > so there's no need to do this manually. > > Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter > --- > drivers/gpu/drm/ast/ast_cursor.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/ast/ast_cursor.c > b/drivers/gpu/drm/ast/ast_cursor.c > index 742d43a7edf4..68bf3d33f1ed 100644 > --- a/drivers/gpu/drm/ast/ast_cursor.c > +++ b/drivers/gpu/drm/ast/ast_cursor.c > @@ -180,12 +180,9 @@ int ast_cursor_blit(struct ast_private *ast, struct > drm_framebuffer *fb) > > gbo = drm_gem_vram_of_gem(fb->obj[0]); > > - ret = drm_gem_vram_pin(gbo, 0); > - if (ret) > - return ret; > ret = drm_gem_vram_vmap(gbo, &map); > if (ret) > - goto err_drm_gem_vram_unpin; > + return ret; > src = map.vaddr; /* TODO: Use mapping abstraction properly */ > > dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem; > @@ -194,13 +191,8 @@ int ast_cursor_blit(struct ast_private *ast, struct > drm_framebuffer *fb) > update_cursor_image(dst, src, fb->width, fb->height); > > drm_gem_vram_vunmap(gbo, &map); > - drm_gem_vram_unpin(gbo); > > return 0; > - > -err_drm_gem_vram_unpin: > - drm_gem_vram_unpin(gbo); > - return ret; > } > > static void ast_cursor_set_base(struct ast_private *ast, u64 address) > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates
On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote:
> The HW cursor's BO used to be mapped permanently into the kernel's
> address space. GEM's vmap operation will be protected by locks, and
> we don't want to lock the BO's for an indefinate period of time.
>
> Change the cursor code to map the HW BOs only during updates. The
> vmap operation in VRAM helpers is cheap, as a once estabished mapping
> is being reused until the BO actually moves. As the HW cursor BOs are
> permanently pinned, they never move at all.
>
> v2:
> * fix typos in commit description
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Christian König
Acked-by: Daniel Vetter
Now there's a pretty big issue here though: We can't take dma_resv_lock in
commit_tail, because of possible deadlocks on at least gpus that do real
async rendering because of the dma_fences. Unfortunately my annotations
patches got stuck a bit, I need to refresh them.
Rules are you can pin and unpin stuff in prepare/cleanup_plane, and also
take dma_resv_lock there, but not in commit_tail in-between. So I think
our vmap_local needs to loose the unconditional assert_locked and require
either that or a pin count.
-Daniel
> ---
> drivers/gpu/drm/ast/ast_cursor.c | 51 ++--
> drivers/gpu/drm/ast/ast_drv.h| 2 --
> 2 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> b/drivers/gpu/drm/ast/ast_cursor.c
> index 68bf3d33f1ed..fac1ee79c372 100644
> --- a/drivers/gpu/drm/ast/ast_cursor.c
> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> @@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
>
> for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
> gbo = ast->cursor.gbo[i];
> - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
> drm_gem_vram_unpin(gbo);
> drm_gem_vram_put(gbo);
> }
> @@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev,
> void *ptr)
> }
>
> /*
> - * Allocate cursor BOs and pins them at the end of VRAM.
> + * Allocate cursor BOs and pin them at the end of VRAM.
> */
> int ast_cursor_init(struct ast_private *ast)
> {
> struct drm_device *dev = &ast->base;
> size_t size, i;
> struct drm_gem_vram_object *gbo;
> - struct dma_buf_map map;
> int ret;
>
> size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
> @@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
> drm_gem_vram_put(gbo);
> goto err_drm_gem_vram_put;
> }
> - ret = drm_gem_vram_vmap(gbo, &map);
> - if (ret) {
> - drm_gem_vram_unpin(gbo);
> - drm_gem_vram_put(gbo);
> - goto err_drm_gem_vram_put;
> - }
> -
> ast->cursor.gbo[i] = gbo;
> - ast->cursor.map[i] = map;
> }
>
> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
> @@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast)
> while (i) {
> --i;
> gbo = ast->cursor.gbo[i];
> - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
> drm_gem_vram_unpin(gbo);
> drm_gem_vram_put(gbo);
> }
> @@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const
> u8 *src, int width, int h
> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
> {
> struct drm_device *dev = &ast->base;
> - struct drm_gem_vram_object *gbo;
> - struct dma_buf_map map;
> - int ret;
> - void *src;
> + struct drm_gem_vram_object *dst_gbo =
> ast->cursor.gbo[ast->cursor.next_index];
> + struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
> + struct dma_buf_map src_map, dst_map;
> void __iomem *dst;
> + void *src;
> + int ret;
>
> if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
> drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
> return -EINVAL;
>
> - gbo = drm_gem_vram_of_gem(fb->obj[0]);
> -
> - ret = drm_gem_vram_vmap(gbo, &map);
> + ret = drm_gem_vram_vmap(src_gbo, &src_map);
> if (ret)
> return ret;
> - src = map.vaddr; /* TODO: Use mapping abstraction properly */
> + src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
>
> - dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
> +
Re: [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates
On Fri, Dec 11, 2020 at 11:49:48AM +0100, Thomas Zimmermann wrote:
>
>
> Am 11.12.20 um 11:18 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote:
> > > The HW cursor's BO used to be mapped permanently into the kernel's
> > > address space. GEM's vmap operation will be protected by locks, and
> > > we don't want to lock the BO's for an indefinate period of time.
> > >
> > > Change the cursor code to map the HW BOs only during updates. The
> > > vmap operation in VRAM helpers is cheap, as a once estabished mapping
> > > is being reused until the BO actually moves. As the HW cursor BOs are
> > > permanently pinned, they never move at all.
> > >
> > > v2:
> > > * fix typos in commit description
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > Acked-by: Christian König
> >
> > Acked-by: Daniel Vetter
> >
> > Now there's a pretty big issue here though: We can't take dma_resv_lock in
> > commit_tail, because of possible deadlocks on at least gpus that do real
> > async rendering because of the dma_fences. Unfortunately my annotations
> > patches got stuck a bit, I need to refresh them.
> >
> > Rules are you can pin and unpin stuff in prepare/cleanup_plane, and also
> > take dma_resv_lock there, but not in commit_tail in-between. So I think
> > our vmap_local needs to loose the unconditional assert_locked and require
> > either that or a pin count.
>
> I guess my commit description is misleading when it speaks of updates.
> ast_cursor_blit() is actually called from the cursor plane's prepare_fb
> function. [1] The vmap code in ast_cursor_show() could be moved into blit()
> as well, I think.
Oh I failed to check this properly. Even better.
> I guess the clean solution is to integrate the cursor code with the
> modesetting code in ast_mode. From there, locks and mappings can be
> established in prepare_fb and the HW state can be updated in atomic_commit.
Yup. I'll still refresh my series with lockdep annotations, keeps paranoid
me at peace :-)
-Daniel
>
> Best regards
> Thomas
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ast/ast_mode.c#n646
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/ast/ast_cursor.c | 51 ++--
> > > drivers/gpu/drm/ast/ast_drv.h| 2 --
> > > 2 files changed, 28 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> > > b/drivers/gpu/drm/ast/ast_cursor.c
> > > index 68bf3d33f1ed..fac1ee79c372 100644
> > > --- a/drivers/gpu/drm/ast/ast_cursor.c
> > > +++ b/drivers/gpu/drm/ast/ast_cursor.c
> > > @@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
> > > for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
> > > gbo = ast->cursor.gbo[i];
> > > - drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
> > > drm_gem_vram_unpin(gbo);
> > > drm_gem_vram_put(gbo);
> > > }
> > > @@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device
> > > *dev, void *ptr)
> > > }
> > > /*
> > > - * Allocate cursor BOs and pins them at the end of VRAM.
> > > + * Allocate cursor BOs and pin them at the end of VRAM.
> > >*/
> > > int ast_cursor_init(struct ast_private *ast)
> > > {
> > > struct drm_device *dev = &ast->base;
> > > size_t size, i;
> > > struct drm_gem_vram_object *gbo;
> > > - struct dma_buf_map map;
> > > int ret;
> > > size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE,
> > > PAGE_SIZE);
> > > @@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
> > > drm_gem_vram_put(gbo);
> > > goto err_drm_gem_vram_put;
> > > }
> > > - ret = drm_gem_vram_vmap(gbo, &map);
> > > - if (ret) {
> > > - drm_gem_vram_unpin(gbo);
> > > - drm_gem_vram_put(gbo);
> > > - goto err_drm_gem_vram_put;
> > > - }
> > > -
> > > ast->cursor.gbo[i] = gbo;
> > > - ast->cursor.map[i] = map;
> > > }
> > > retu
Re: [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker
On Fri, Dec 11, 2020 at 11:16:25AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.12.20 um 11:01 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote:
> > > Fbdev emulation has to lock the BO into place while flushing the shadow
> > > buffer into the BO's memory. Remove any interference with pinning by
> > > using vmap_local functionality (instead of full vmap). This requires
> > > BO reservation locking in fbdev's damage worker.
> > >
> > > The new DRM client functions for locking and vmap_local functionality
> > > are added for consistency with the existing style.
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > The old vmap/vunmap in the client library aren't used anymore, please
> > delete. That will also make it clearer in the diff what's going on and
> > that it makes sense to have the client and fb-helper part in one patch.
>
> They are still around for perma-mapped BOs where HW supports it (really only
> CMA-based drivers). See drm_fb_helper_generic_probe() and
> drm_fbdev_cleanup().
Ah right I didn't grep this carefully enough. I guess in that case
splitting this into the drm_client patch and fb-helper patch would be good
I think.
Also some kerneldoc commment addition for normal vmap that vmap_local is
preferred for short-term mappings, and for vmap_local that _vmap() gives
you the long term mapping. Just for more links and stuff in docs.
With that: Reviewed-by: Daniel Vetter
-Daniel
>
> Best regards
> Thomas
>
> >
> > With that: Reviewed-by: Daniel Vetter
> >
> > > ---
> > > drivers/gpu/drm/drm_client.c| 91 +
> > > drivers/gpu/drm/drm_fb_helper.c | 41 +++
> > > include/drm/drm_client.h| 4 ++
> > > 3 files changed, 116 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index ce45e380f4a2..795f5cb052ba 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev
> > > *client, u32 width, u32 height, u
> > > return ERR_PTR(ret);
> > > }
> > > +/**
> > > + * drm_client_buffer_lock - Locks the DRM client buffer
> > > + * @buffer: DRM client buffer
> > > + *
> > > + * This function locks the client buffer by acquiring the buffer
> > > + * object's reservation lock.
> > > + *
> > > + * Unlock the buffer with drm_client_buffer_unlock().
> > > + *
> > > + * Returns:
> > > + * 0 on success, or a negative errno code otherwise.
> > > + */
> > > +int
> > > +drm_client_buffer_lock(struct drm_client_buffer *buffer)
> > > +{
> > > + return dma_resv_lock(buffer->gem->resv, NULL);
> > > +}
> > > +EXPORT_SYMBOL(drm_client_buffer_lock);
> > > +
> > > +/**
> > > + * drm_client_buffer_unlock - Unlock DRM client buffer
> > > + * @buffer: DRM client buffer
> > > + *
> > > + * Unlocks a client buffer. See drm_client_buffer_lock().
> > > + */
> > > +void drm_client_buffer_unlock(struct drm_client_buffer *buffer)
> > > +{
> > > + dma_resv_unlock(buffer->gem->resv);
> > > +}
> > > +EXPORT_SYMBOL(drm_client_buffer_unlock);
> > > +
> > > /**
> > >* drm_client_buffer_vmap - Map DRM client buffer into address space
> > >* @buffer: DRM client buffer
> > > @@ -348,6 +379,66 @@ void drm_client_buffer_vunmap(struct
> > > drm_client_buffer *buffer)
> > > }
> > > EXPORT_SYMBOL(drm_client_buffer_vunmap);
> > > +/**
> > > + * drm_client_buffer_vmap_local - Map DRM client buffer into address
> > > space
> > > + * @buffer: DRM client buffer
> > > + * @map_copy: Returns the mapped memory's address
> > > + *
> > > + * This function maps a client buffer into kernel address space. If the
> > > + * buffer is already mapped, it returns the existing mapping's address.
> > > + *
> > > + * Client buffer mappings are not ref'counted. Each call to
> > > + * drm_client_buffer_vmap_local() should be followed by a call to
> > > + * drm_client_buffer_vunmap_local(); or the client buffer should be
> > > mapped
> > > + * throughout its lifetime.
> > > + *
> > > + * The returned address is a copy of the interna
Re: [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations
buf_map *map); > + > + /** > + * @vmap_local: > + * > + * Creates a virtual mapping for the buffer into kernel address space. > + * > + * This callback establishes short-term mappings for situations where > + * callers only use the buffer for a bounded amount of time; such as > + * updates to the framebuffer or reading back contained information. > + * In contrast to the regular @vmap callback, vmap_local does never pin > + * the buffer to a specific domain or acquire the buffer's reservation > + * lock. > + * > + * This is called with the dmabuf->resv object locked. Callers must hold > + * the lock until after removing the mapping with @vunmap_local. > + * > + * This callback is optional. > + * > + * Returns: > + * > + * 0 on success or a negative error code on failure. > + */ > + int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > + > + /** > + * @vunmap_local: > + * > + * Removes a virtual mapping that wa sestablished by @vmap_local. > + * > + * This callback is optional. > + */ > + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > }; > > /** > @@ -506,4 +538,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct > *, >unsigned long); > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map); > +int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > +void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map); > #endif /* __DMA_BUF_H__ */ > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings
On Thu, Jan 7, 2021 at 11:28 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 11.12.20 um 10:50 schrieb Daniel Vetter:
> [...]
> >> +/**
> >> + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM
> >> object
> >> + * @shmem: shmem GEM object
> >> + * @map: Returns the kernel virtual address of the SHMEM GEM object's
> >> backing
> >> + * store.
> >> + *
> >> + * This function makes sure that a contiguous kernel virtual address
> >> mapping
> >> + * exists for the buffer backing the shmem GEM object.
> >> + *
> >> + * The function is called with the BO's reservation object locked.
> >> Callers must
> >> + * hold the lock until after unmapping the buffer.
> >> + *
> >> + * This function can be used to implement
> >> &drm_gem_object_funcs.vmap_local. But
> >> + * it can also be called by drivers directly, in which case it will hide
> >> the
> >> + * differences between dma-buf imported and natively allocated objects.
> >> + *
> >> + * Acquired mappings should be cleaned up by calling
> >> drm_gem_shmem_vunmap_local().
> >> + *
> >> + * Returns:
> >> + * 0 on success or a negative error code on failure.
> >> + */
> >> +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct
> >> dma_buf_map *map)
> >> +{
> >> +struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >> +int ret;
> >> +
> >> +dma_resv_assert_held(obj->resv);
> >> +
> >> +ret = mutex_lock_interruptible(&shmem->vmap_lock);
> >
> > This bites. You need to check for shmem->import_attach and call
> > dma_buf_vmap_local directly here before you take any shmem helper locks.
> > Real fix would be to replace both vmap_lock and pages_lock with dma_resv
> > lock, but that's more work. Same for vunmap_local
>
> This comment confuses me. AFAICT vmap_lock protects vmap_use_count. Why
> does this exact code work in drm_gem_shmem_vmap() but not in _local() ?
You'd hold the dma_resv lock both inside and outside of the
->vmap_lock mutex. Which deadlocks. For the _vmap version we more or
less mandate that the caller doens't hold the dma_resv lock already,
hence why we can get away with that.
-Daniel
> Best regards
> Thomas
>
> >
> > With that fixed on the helper part of this patch:
> >
> > Reviewed-by: Daniel Vetter
> >
> >
> >> +if (ret)
> >> +return ret;
> >> +ret = drm_gem_shmem_vmap_locked(shmem, map);
> >> +mutex_unlock(&shmem->vmap_lock);
> >> +
> >> +return ret;
> >> +}
> >> +EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
> >> +
> >> static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object
> >> *shmem,
> >> struct dma_buf_map *map)
> >> {
> >> @@ -366,7 +406,7 @@ static void drm_gem_shmem_vunmap_locked(struct
> >> drm_gem_shmem_object *shmem,
> >> drm_gem_shmem_put_pages(shmem);
> >> }
> >>
> >> -/*
> >> +/**
> >>* drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object
> >>* @shmem: shmem GEM object
> >>* @map: Kernel virtual address where the SHMEM GEM object was mapped
> >> @@ -389,6 +429,33 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj,
> >> struct dma_buf_map *map)
> >> }
> >> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
> >>
> >> +/**
> >> + * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM
> >> object
> >> + * @shmem: shmem GEM object
> >> + * @map: Kernel virtual address where the SHMEM GEM object was mapped
> >> + *
> >> + * This function cleans up a kernel virtual address mapping acquired by
> >> + * drm_gem_shmem_vmap_local(). The mapping is only removed when the use
> >> count
> >> + * drops to zero.
> >> + *
> >> + * The function is called with the BO's reservation object locked.
> >> + *
> >> + * This function can be used to implement
> >> &drm_gem_object_funcs.vmap_local.
> >> + * But it can also be called by drivers directly, in which case it will
> >> hide
> >> + * the differences between dma-buf imported and natively allocated
> >> objects.
> >> + */
> >> +void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, s
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
th the BO's reservation object locked. Callers
> must
> + * hold the lock until after unmapping the buffer.
> + *
> + * This function can be used to implement &drm_gem_object_funcs.vmap_local.
> But
> + * it can also be called by drivers directly, in which case it will hide the
> + * differences between dma-buf imported and natively allocated objects.
So for the other callbacks I tried to make sure we have different entry
points for this, since it's not really the same thing and because of the
locking mess we have with dma_resv_lock vs various pre-existing local
locking scheme, it's easy to get a mess.
I think the super clean version here would be to also export just the
internal stuff for the ->v(un)map_local hooks, but that's maybe a bit too
much boilerplate for no real gain.
-Daniel
> + *
> + * Acquired mappings should be cleaned up by calling
> drm_gem_shmem_vunmap_local().
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
> *map)
> +{
> + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> + int ret;
> +
> + dma_resv_assert_held(obj->resv);
> +
> + ret = mutex_lock_interruptible(&shmem->vmap_lock);
> + if (ret)
> + return ret;
> + ret = drm_gem_shmem_vmap_locked(shmem, map, true);
> + mutex_unlock(&shmem->vmap_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
> +
> static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
> - struct dma_buf_map *map)
> + struct dma_buf_map *map, bool local)
> {
> struct drm_gem_object *obj = &shmem->base;
>
> @@ -358,7 +402,10 @@ static void drm_gem_shmem_vunmap_locked(struct
> drm_gem_shmem_object *shmem,
> return;
>
> if (obj->import_attach)
> - dma_buf_vunmap(obj->import_attach->dmabuf, map);
> + if (local)
> + dma_buf_vunmap_local(obj->import_attach->dmabuf, map);
> + else
> + dma_buf_vunmap(obj->import_attach->dmabuf, map);
> else
> vunmap(shmem->vaddr);
>
> @@ -366,7 +413,7 @@ static void drm_gem_shmem_vunmap_locked(struct
> drm_gem_shmem_object *shmem,
> drm_gem_shmem_put_pages(shmem);
> }
>
> -/*
> +/**
> * drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object
> * @shmem: shmem GEM object
> * @map: Kernel virtual address where the SHMEM GEM object was mapped
> @@ -384,11 +431,38 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj,
> struct dma_buf_map *map)
> struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>
> mutex_lock(&shmem->vmap_lock);
> - drm_gem_shmem_vunmap_locked(shmem, map);
> + drm_gem_shmem_vunmap_locked(shmem, map, false);
> mutex_unlock(&shmem->vmap_lock);
> }
> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
>
> +/**
> + * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM object
> + * @shmem: shmem GEM object
> + * @map: Kernel virtual address where the SHMEM GEM object was mapped
> + *
> + * This function cleans up a kernel virtual address mapping acquired by
> + * drm_gem_shmem_vmap_local(). The mapping is only removed when the use count
> + * drops to zero.
> + *
> + * The function is called with the BO's reservation object locked.
> + *
> + * This function can be used to implement &drm_gem_object_funcs.vmap_local.
> + * But it can also be called by drivers directly, in which case it will hide
> + * the differences between dma-buf imported and natively allocated objects.
> + */
> +void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct
> dma_buf_map *map)
> +{
> + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> +
> + dma_resv_assert_held(obj->resv);
> +
> + mutex_lock(&shmem->vmap_lock);
> + drm_gem_shmem_vunmap_locked(shmem, map, true);
> + mutex_unlock(&shmem->vmap_lock);
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_vunmap_local);
> +
> struct drm_gem_shmem_object *
> drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
>struct drm_device *dev, size_t size,
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index 434328d8a0d9..3f59bdf749aa 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -114,7 +114,9 @@ void drm_gem_shmem_put_p
Re: [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}()
On Fri, Jan 08, 2021 at 10:43:40AM +0100, Thomas Zimmermann wrote:
> VRAM-helper BO's cannot be exported, so calls for vmap and vunmap
> can only come from the BO's drivers or a kernel client. These are
> supposed use vmap_local functionality.
^to
>
> The vmap and vunmap operations in VRAM helpers are therefore unused
> and can be removed.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 98 ---
> include/drm/drm_gem_vram_helper.h | 2 -
> 2 files changed, 100 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index c7fba3a0758e..c7d166cd16df 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -379,72 +379,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_unpin);
>
> -/**
> - * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
> - * space
> - * @gbo: The GEM VRAM object to map
> - * @map: Returns the kernel virtual address of the VRAM GEM object's backing
> - * store.
> - *
> - * The vmap function pins a GEM VRAM object to its current location, either
> - * system or video memory, and maps its buffer into kernel address space.
> - * As pinned object cannot be relocated, you should avoid pinning objects
> - * permanently. Call drm_gem_vram_vunmap() with the returned address to
> - * unmap and unpin the GEM VRAM object.
> - *
> - * Returns:
> - * 0 on success, or a negative error code otherwise.
> - */
> -int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
> *map)
> -{
> - int ret;
> -
> - ret = ttm_bo_reserve(&gbo->bo, true, false, NULL);
> - if (ret)
> - return ret;
> -
> - ret = drm_gem_vram_pin_locked(gbo, 0);
> - if (ret)
> - goto err_ttm_bo_unreserve;
> - ret = drm_gem_vram_vmap_local(gbo, map);
> - if (ret)
> - goto err_drm_gem_vram_unpin_locked;
> -
> - ttm_bo_unreserve(&gbo->bo);
> -
> - return 0;
> -
> -err_drm_gem_vram_unpin_locked:
> - drm_gem_vram_unpin_locked(gbo);
> -err_ttm_bo_unreserve:
> - ttm_bo_unreserve(&gbo->bo);
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_gem_vram_vmap);
> -
> -/**
> - * drm_gem_vram_vunmap() - Unmaps and unpins a GEM VRAM object
> - * @gbo: The GEM VRAM object to unmap
> - * @map: Kernel virtual address where the VRAM GEM object was mapped
> - *
> - * A call to drm_gem_vram_vunmap() unmaps and unpins a GEM VRAM buffer. See
> - * the documentation for drm_gem_vram_vmap() for more information.
> - */
> -void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
> *map)
> -{
> - int ret;
> -
> - ret = ttm_bo_reserve(&gbo->bo, false, false, NULL);
> - if (WARN_ONCE(ret, "ttm_bo_reserve_failed(): ret=%d\n", ret))
> - return;
> -
> - drm_gem_vram_vunmap_local(gbo, map);
> - drm_gem_vram_unpin_locked(gbo);
> -
> - ttm_bo_unreserve(&gbo->bo);
> -}
> -EXPORT_SYMBOL(drm_gem_vram_vunmap);
> -
> /**
> * drm_gem_vram_vmap_local() - Maps a GEM VRAM object into kernel address
> space
> * @gbo: The GEM VRAM object to map
> @@ -870,36 +804,6 @@ static void drm_gem_vram_object_unpin(struct
> drm_gem_object *gem)
> drm_gem_vram_unpin(gbo);
> }
>
> -/**
> - * drm_gem_vram_object_vmap() -
> - * Implements &struct drm_gem_object_funcs.vmap
> - * @gem: The GEM object to map
> - * @map: Returns the kernel virtual address of the VRAM GEM object's backing
> - * store.
> - *
> - * Returns:
> - * 0 on success, or a negative error code otherwise.
> - */
> -static int drm_gem_vram_object_vmap(struct drm_gem_object *gem, struct
> dma_buf_map *map)
> -{
> - struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> -
> - return drm_gem_vram_vmap(gbo, map);
> -}
> -
> -/**
> - * drm_gem_vram_object_vunmap() -
> - * Implements &struct drm_gem_object_funcs.vunmap
> - * @gem: The GEM object to unmap
> - * @map: Kernel virtual address where the VRAM GEM object was mapped
> - */
> -static void drm_gem_vram_object_vunmap(struct drm_gem_object *gem, struct
> dma_buf_map *map)
> -{
> - struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> -
> - drm_gem_vram_vunmap(gbo, map);
> -}
> -
> static int drm_gem_vram_object_vmap_local(struct drm_gem_object *gem, struct
> dma_buf_map *map)
> {
> st
Re: [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling
On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote:
> Damage handling in mgag200 requires a short-term mapping of the source
> BO. Use drm_gem_shmem_vmap_local().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 1dfc42170059..a33e28d4c5e9 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -1552,22 +1552,32 @@ mgag200_handle_damage(struct mga_device *mdev, struct
> drm_framebuffer *fb,
> struct drm_rect *clip)
> {
> struct drm_device *dev = &mdev->base;
> + struct drm_gem_object *obj = fb->obj[0];
> struct dma_buf_map map;
> void *vmap;
> int ret;
>
> - ret = drm_gem_shmem_vmap(fb->obj[0], &map);
> + ret = dma_resv_lock(obj->resv, NULL);
> if (drm_WARN_ON(dev, ret))
> - return; /* BUG: SHMEM BO should always be vmapped */
> + return;
> + ret = drm_gem_shmem_vmap_local(obj, &map);
> + if (drm_WARN_ON(dev, ret))
> + goto err_dma_resv_unlock; /* BUG: SHMEM BO should always be
> vmapped */
> vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
>
> drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
>
> - drm_gem_shmem_vunmap(fb->obj[0], &map);
> + drm_gem_shmem_vunmap_local(obj, &map);
> + dma_resv_unlock(obj->resv);
>
> /* Always scanout image at VRAM offset 0 */
> mgag200_set_startadd(mdev, (u32)0);
> mgag200_set_offset(mdev, fb);
> +
> + return;
> +
> +err_dma_resv_unlock:
> + dma_resv_unlock(obj->resv);
> }
>
> static void
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling
On Mon, Jan 11, 2021 at 05:53:41PM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote:
> > Damage handling in mgag200 requires a short-term mapping of the source
> > BO. Use drm_gem_shmem_vmap_local().
> >
> > Signed-off-by: Thomas Zimmermann
>
> Reviewed-by: Daniel Vetter
On second thought, strike that r-b, I have a confused question.
>
> > ---
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 16 +---
> > 1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> > b/drivers/gpu/drm/mgag200/mgag200_mode.c
> > index 1dfc42170059..a33e28d4c5e9 100644
> > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> > @@ -1552,22 +1552,32 @@ mgag200_handle_damage(struct mga_device *mdev,
> > struct drm_framebuffer *fb,
> > struct drm_rect *clip)
> > {
> > struct drm_device *dev = &mdev->base;
> > + struct drm_gem_object *obj = fb->obj[0];
> > struct dma_buf_map map;
> > void *vmap;
> > int ret;
> >
> > - ret = drm_gem_shmem_vmap(fb->obj[0], &map);
> > + ret = dma_resv_lock(obj->resv, NULL);
> > if (drm_WARN_ON(dev, ret))
> > - return; /* BUG: SHMEM BO should always be vmapped */
> > + return;
> > + ret = drm_gem_shmem_vmap_local(obj, &map);
> > + if (drm_WARN_ON(dev, ret))
> > + goto err_dma_resv_unlock; /* BUG: SHMEM BO should always be
> > vmapped */
Why is this guaranteed? I tried to hunt for a vmap in mga200g code, and
dind't find any. I'd ahve expected something in prepare/finish_fb.
Also since this is not a vram-helper using driver, why convert it over to
vmap_local? I guess that should also be explained in the commit message a
bit better.
-Daniel
> > vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
> >
> > drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
> >
> > - drm_gem_shmem_vunmap(fb->obj[0], &map);
> > + drm_gem_shmem_vunmap_local(obj, &map);
> > + dma_resv_unlock(obj->resv);
> >
> > /* Always scanout image at VRAM offset 0 */
> > mgag200_set_startadd(mdev, (u32)0);
> > mgag200_set_offset(mdev, fb);
> > +
> > + return;
> > +
> > +err_dma_resv_unlock:
> > + dma_resv_unlock(obj->resv);
> > }
> >
> > static void
> > --
> > 2.29.2
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 06/13] drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling
On Fri, Jan 08, 2021 at 10:43:33AM +0100, Thomas Zimmermann wrote:
> Damage handling in cirrus requires a short-term mapping of the source
> BO. Use drm_gem_shmem_vmap_local().
>
> Signed-off-by: Thomas Zimmermann
Hm more possible errors that we don't report to userspace ... Why don't we
vmap/vunmap these in prepare/cleanup_fb? Generally we'd want a long-term
vmap here to make sure this all works nicely.
Since it's nothing new, on this patch:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/tiny/cirrus.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
> index a043e602199e..21cd7056d45f 100644
> --- a/drivers/gpu/drm/tiny/cirrus.c
> +++ b/drivers/gpu/drm/tiny/cirrus.c
> @@ -315,6 +315,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> struct cirrus_device *cirrus = to_cirrus(fb->dev);
> + struct drm_gem_object *obj = fb->obj[0];
> struct dma_buf_map map;
> void *vmap;
> int idx, ret;
> @@ -323,9 +324,12 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
> *fb,
> if (!drm_dev_enter(&cirrus->dev, &idx))
> goto out;
>
> - ret = drm_gem_shmem_vmap(fb->obj[0], &map);
> + ret = dma_resv_lock(obj->resv, NULL);
> if (ret)
> goto out_dev_exit;
> + ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
> + if (ret)
> + goto out_dma_resv_unlock;
> vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
>
> if (cirrus->cpp == fb->format->cpp[0])
> @@ -345,9 +349,11 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
> *fb,
> else
> WARN_ON_ONCE("cpp mismatch");
>
> - drm_gem_shmem_vunmap(fb->obj[0], &map);
> ret = 0;
>
> + drm_gem_shmem_vunmap_local(obj, &map);
> +out_dma_resv_unlock:
> + dma_resv_unlock(obj->resv);
> out_dev_exit:
> drm_dev_exit(idx);
> out:
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 07/13] drm/gm12u320: Use drm_gem_shmem_vmap_local() in damage handling
On Fri, Jan 08, 2021 at 10:43:34AM +0100, Thomas Zimmermann wrote:
> Damage handling in gm12u320 requires a short-term mapping of the source
> BO. Use drm_gem_shmem_vmap_local().
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/gm12u320.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
> index 33f65f4626e5..b0c6e350f2b3 100644
> --- a/drivers/gpu/drm/tiny/gm12u320.c
> +++ b/drivers/gpu/drm/tiny/gm12u320.c
> @@ -265,11 +265,16 @@ static void gm12u320_copy_fb_to_blocks(struct
> gm12u320_device *gm12u320)
> y1 = gm12u320->fb_update.rect.y1;
> y2 = gm12u320->fb_update.rect.y2;
>
> - ret = drm_gem_shmem_vmap(fb->obj[0], &map);
> + ret = dma_resv_lock(fb->obj[0]->resv, NULL);
> if (ret) {
> - GM12U320_ERR("failed to vmap fb: %d\n", ret);
> + GM12U320_ERR("failed to reserve fb: %d\n", ret);
> goto put_fb;
> }
> + ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
> + if (ret) {
> + GM12U320_ERR("failed to vmap fb: %d\n", ret);
> + goto unlock_resv;
> + }
> vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
>
> if (fb->obj[0]->import_attach) {
> @@ -321,8 +326,11 @@ static void gm12u320_copy_fb_to_blocks(struct
> gm12u320_device *gm12u320)
> if (ret)
> GM12U320_ERR("dma_buf_end_cpu_access err: %d\n", ret);
> }
> +
> +unlock_resv:
> + dma_resv_unlock(fb->obj[0]->resv);
Unlock before vunmap.
-Daniel
> vunmap:
> - drm_gem_shmem_vunmap(fb->obj[0], &map);
> + drm_gem_shmem_vunmap_local(fb->obj[0], &map);
> put_fb:
> drm_framebuffer_put(fb);
> gm12u320->fb_update.fb = NULL;
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 06/13] drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling
On Mon, Jan 11, 2021 at 06:00:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2021 at 10:43:33AM +0100, Thomas Zimmermann wrote:
> > Damage handling in cirrus requires a short-term mapping of the source
> > BO. Use drm_gem_shmem_vmap_local().
> >
> > Signed-off-by: Thomas Zimmermann
>
> Hm more possible errors that we don't report to userspace ... Why don't we
> vmap/vunmap these in prepare/cleanup_fb? Generally we'd want a long-term
> vmap here to make sure this all works nicely.
>
> Since it's nothing new, on this patch:
>
> Reviewed-by: Daniel Vetter
Ok, also strike this r-b here. This is called from that atomic commit
paths, and we cannot call dma_resv_lock here. This should splat with
lockdep enabled against the dma-fence annotations I've merged, I'm kinda
surprised it doesn't?
-Daniel
>
> > ---
> > drivers/gpu/drm/tiny/cirrus.c | 10 --
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
> > index a043e602199e..21cd7056d45f 100644
> > --- a/drivers/gpu/drm/tiny/cirrus.c
> > +++ b/drivers/gpu/drm/tiny/cirrus.c
> > @@ -315,6 +315,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
> > *fb,
> >struct drm_rect *rect)
> > {
> > struct cirrus_device *cirrus = to_cirrus(fb->dev);
> > + struct drm_gem_object *obj = fb->obj[0];
> > struct dma_buf_map map;
> > void *vmap;
> > int idx, ret;
> > @@ -323,9 +324,12 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
> > *fb,
> > if (!drm_dev_enter(&cirrus->dev, &idx))
> > goto out;
> >
> > - ret = drm_gem_shmem_vmap(fb->obj[0], &map);
> > + ret = dma_resv_lock(obj->resv, NULL);
> > if (ret)
> > goto out_dev_exit;
> > + ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
> > + if (ret)
> > + goto out_dma_resv_unlock;
> > vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
> >
> > if (cirrus->cpp == fb->format->cpp[0])
> > @@ -345,9 +349,11 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
> > *fb,
> > else
> > WARN_ON_ONCE("cpp mismatch");
> >
> > - drm_gem_shmem_vunmap(fb->obj[0], &map);
> > ret = 0;
> >
> > + drm_gem_shmem_vunmap_local(obj, &map);
> > +out_dma_resv_unlock:
> > + dma_resv_unlock(obj->resv);
> > out_dev_exit:
> > drm_dev_exit(idx);
> > out:
> > --
> > 2.29.2
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote:
> Cursor updates in vboxvideo require a short-term mapping of the
> source BO. Use drm_gem_vram_vmap_local() and avoid the pinning
> operations.
>
> Signed-off-by: Thomas Zimmermann
All these drivers patches break the dma_resv_lock vs
dma_fence_begin/end_signalling nesting rules, so this doesn't work.
Generally this is what the prepare/cleanup_fb hooks are for, that's where
mappings (including vmaps) are meant to be set up, permanently.
I'm kinda not clear on why we need all these changes, I thought the
locking problem is just in the fb helper paths, because it's outside of
the atomic path and could conflict with an atomic update at the same time?
So only that one should get the vmap_local treatment, everything else
should keep the normal vmap treatment.
-Daniel
> ---
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> index dbc0dd53c69e..215b37c78c10 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> @@ -381,7 +381,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
> *plane,
> container_of(plane->dev, struct vbox_private, ddev);
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
> struct drm_framebuffer *fb = plane->state->fb;
> - struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
> + struct drm_gem_object *obj = fb->obj[0];
> + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(obj);
> u32 width = plane->state->crtc_w;
> u32 height = plane->state->crtc_h;
> size_t data_size, mask_size;
> @@ -401,11 +402,12 @@ static void vbox_cursor_atomic_update(struct drm_plane
> *plane,
>
> vbox_crtc->cursor_enabled = true;
>
> - ret = drm_gem_vram_vmap(gbo, &map);
> + ret = dma_resv_lock(obj->resv, NULL);
> + if (ret)
> + return;
> + ret = drm_gem_vram_vmap_local(gbo, &map);
> if (ret) {
> - /*
> - * BUG: we should have pinned the BO in prepare_fb().
> - */
> + dma_resv_unlock(obj->resv);
> mutex_unlock(&vbox->hw_mutex);
> DRM_WARN("Could not map cursor bo, skipping update\n");
> return;
> @@ -421,7 +423,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
> *plane,
> data_size = width * height * 4 + mask_size;
>
> copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
> - drm_gem_vram_vunmap(gbo, &map);
> + drm_gem_vram_vunmap_local(gbo, &map);
> + dma_resv_unlock(obj->resv);
>
> flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
> VBOX_MOUSE_POINTER_ALPHA;
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
On Tue, Jan 12, 2021 at 08:54:02AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 18:06 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote:
> > > Cursor updates in vboxvideo require a short-term mapping of the
> > > source BO. Use drm_gem_vram_vmap_local() and avoid the pinning
> > > operations.
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > All these drivers patches break the dma_resv_lock vs
> > dma_fence_begin/end_signalling nesting rules, so this doesn't work.
> >
> > Generally this is what the prepare/cleanup_fb hooks are for, that's where
> > mappings (including vmaps) are meant to be set up, permanently.
> >
> > I'm kinda not clear on why we need all these changes, I thought the
> > locking problem is just in the fb helper paths, because it's outside of
> > the atomic path and could conflict with an atomic update at the same time?
> > So only that one should get the vmap_local treatment, everything else
> > should keep the normal vmap treatment.
>
> Kind of responding to all your comment on the driver changes:
>
> These drivers only require short-term mappings, so using vmap_local would be
> the natural choice. For SHMEM helpers, it's mostly a cosmetic thing. For
> VRAM helpers, I was hoping to remove the vmap/vunmap helpers entirely. One
> cannot really map the BOs for the long-term, so not having the helpers at
> all would make sense.
>
> But reading all your comments on the driver patches, I'd rather not update
> the drivers here but later convert them to use prepare_fb/cleanup_fb in the
> correct way.
Ack from me on this plan. I think I got all the other patches with an r-b
or ack?
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> > > ---
> > > drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > index dbc0dd53c69e..215b37c78c10 100644
> > > --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > @@ -381,7 +381,8 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > container_of(plane->dev, struct vbox_private, ddev);
> > > struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
> > > struct drm_framebuffer *fb = plane->state->fb;
> > > - struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
> > > + struct drm_gem_object *obj = fb->obj[0];
> > > + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(obj);
> > > u32 width = plane->state->crtc_w;
> > > u32 height = plane->state->crtc_h;
> > > size_t data_size, mask_size;
> > > @@ -401,11 +402,12 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > vbox_crtc->cursor_enabled = true;
> > > - ret = drm_gem_vram_vmap(gbo, &map);
> > > + ret = dma_resv_lock(obj->resv, NULL);
> > > + if (ret)
> > > + return;
> > > + ret = drm_gem_vram_vmap_local(gbo, &map);
> > > if (ret) {
> > > - /*
> > > - * BUG: we should have pinned the BO in prepare_fb().
> > > - */
> > > + dma_resv_unlock(obj->resv);
> > > mutex_unlock(&vbox->hw_mutex);
> > > DRM_WARN("Could not map cursor bo, skipping update\n");
> > > return;
> > > @@ -421,7 +423,8 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > data_size = width * height * 4 + mask_size;
> > > copy_cursor_image(src, vbox->cursor_data, width, height,
> > > mask_size);
> > > - drm_gem_vram_vunmap(gbo, &map);
> > > + drm_gem_vram_vunmap_local(gbo, &map);
> > > + dma_resv_unlock(obj->resv);
> > > flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
> > > VBOX_MOUSE_POINTER_ALPHA;
> > > --
> > > 2.29.2
> > >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
On Tue, Jan 12, 2021 at 02:11:24PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 17:50 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
> > > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> > > of the BO and may acquire the associated reservation object's lock.
> > > Callers that only require a mapping of the contained memory can thus
> > > interfere with other tasks that require exact pinning, such as scanout.
> > > This is less of an issue with private SHMEM buffers, but may happen
> > > with imported ones.
> > >
> > > Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
> > > drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
> > > operations. Callers have to hold the reservation lock while the mapping
> > > persists.
> > >
> > > This patch also connects GEM SHMEM helpers to GEM object functions with
> > > equivalent functionality.
> > >
> > > v4:
> > > * call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
> > > * move driver changes into separate patches (Daniel)
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
> > > include/drm/drm_gem_shmem_helper.h | 2 +
> > > 2 files changed, 84 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > index 9825c378dfa6..298832b2b43b 100644
> > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > @@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs
> > > drm_gem_shmem_funcs = {
> > > .get_sg_table = drm_gem_shmem_get_sg_table,
> > > .vmap = drm_gem_shmem_vmap,
> > > .vunmap = drm_gem_shmem_vunmap,
> > > + .vmap_local = drm_gem_shmem_vmap_local,
> > > + .vunmap_local = drm_gem_shmem_vunmap_local,
> > > .mmap = drm_gem_shmem_mmap,
> > > };
> > > @@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> > > }
> > > EXPORT_SYMBOL(drm_gem_shmem_unpin);
> > > -static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map)
> > > +static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map,
> > > + bool local)
> >
> > This is a bit spaghetti and also has the problem that we're not changing
> > shmem->vmap_use_count under different locks, depending upon which path
> > we're taking.
> >
> > I think the cleanest would be if we pull the if (import_attach) case out
> > of the _locked() version completely, for all cases, and also outside of
> > the shmem->vmap_lock. This means no caching of vmaps in the shmem layer
> > anymore for imported buffers, but this is no longer a problem: We cache
> > them in the exporters instead (I think at least, if not maybe need to fix
> > that where it's expensive).
>
> If we do that, what protects shmem->vaddr from concurrent access near line
> 281? would it be kept NULL then?
>
> Also, we have some stats in debugfs (see drm_gem_shmem_print_info) which
> would be incorrect (or misleading at least).
We'd need to disable all that for pass-through vmap of imported objects.
> Given all that, would it be possible to remove vmap_lock in favor of taking
> the resv lock in vmap/vunmap?
All possible (and imo long-term desirable), the trouble is in rolling it
out. I've looked at rolling out dma_resv as the one and only lock for
shmem helpers before, and gave up. Exynos is the worst (but not the only)
offender:
- it has it's own per-object lock
- that per-object lock is taken most often before calling into various
vfuncs, which means for a gradual transition the dma_resv lock would
nest within that existing per-object lock (until we've completely
replaced it)
- but exynos also uses dma_resv already as an outermost lock in its
command submission path
iow as soon as you add dma_resv_lock anywhere in shmem helpers, we've
angered lockdep with a deadlock.
That means the only path I think is feasible is adding dma_resv lock to
all drivers paths first, _outside_ of any existing driver specific
per-object locks. Then remove the driver-specific object locks, and only
then can we sprinkle dma_resv_assert_locked all over shmem helpers.
Ofc a
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
>
> On the success of virtio_gpu_object_create, add size of newly allocated
> bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> bo lost its last refcount, subtract the bo size from the tracked
> total_mem if the original underlying memory allocation is successful.
>
> Signed-off-by: Yiwei Zhang
Isn't this something that ideally we'd for everyone? Also tracepoint
for showing the total feels like tracepoint abuse, usually we show
totals somewhere in debugfs or similar, and tracepoint just for what's
happening (i.e. which object got deleted/created).
What is this for exactly?
-Daniel
> ---
> drivers/gpu/drm/virtio/Kconfig | 1 +
> drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index b925b8b1da16..e103b7e883b1 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> select VIRTIO_DMA_SHARED_BUFFER
> + select TRACE_GPU_MEM
> help
>This is the virtual GPU driver for virtio. It can be used with
>QEMU based VMMs (like KVM or Xen).
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6a232553c99b..7c60e7486bc4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> spinlock_t resource_export_lock;
> /* protects map state and host_visible_mm */
> spinlock_t host_visible_lock;
> +
> +#ifdef CONFIG_TRACE_GPU_MEM
> + atomic64_t total_mem;
> +#endif
> };
>
> struct virtio_gpu_fpriv {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index d69a5b6da553..1e16226cebbe 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -25,12 +25,29 @@
>
> #include
> #include
> +#ifdef CONFIG_TRACE_GPU_MEM
> +#include
> +#endif
>
> #include "virtgpu_drv.h"
>
> static int virtio_gpu_virglrenderer_workaround = 1;
> module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> 0400);
>
> +#ifdef CONFIG_TRACE_GPU_MEM
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> *vgdev,
> + s64 delta)
> +{
> + u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> +
> + trace_gpu_mem_total(0, 0, total_mem);
> +}
> +#else
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *,
> s64)
> +{
> +}
> +#endif
> +
> int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> *resid)
> {
> if (virtio_gpu_virglrenderer_workaround) {
> @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct drm_gem_object
> *obj)
> struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
>
> if (bo->created) {
> + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> virtio_gpu_cmd_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> virtio_gpu_object_attach(vgdev, bo, ents, nents);
> }
>
> + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > >
> > > On the success of virtio_gpu_object_create, add size of newly allocated
> > > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> > > bo lost its last refcount, subtract the bo size from the tracked
> > > total_mem if the original underlying memory allocation is successful.
> > >
> > > Signed-off-by: Yiwei Zhang
> >
> > Isn't this something that ideally we'd for everyone? Also tracepoint
> > for showing the total feels like tracepoint abuse, usually we show
> > totals somewhere in debugfs or similar, and tracepoint just for what's
> > happening (i.e. which object got deleted/created).
> >
> > What is this for exactly?
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/virtio/Kconfig | 1 +
> > > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > > 3 files changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/virtio/Kconfig
> > > b/drivers/gpu/drm/virtio/Kconfig
> > > index b925b8b1da16..e103b7e883b1 100644
> > > --- a/drivers/gpu/drm/virtio/Kconfig
> > > +++ b/drivers/gpu/drm/virtio/Kconfig
> > > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > > select DRM_KMS_HELPER
> > > select DRM_GEM_SHMEM_HELPER
> > > select VIRTIO_DMA_SHARED_BUFFER
> > > + select TRACE_GPU_MEM
> > > help
> > >This is the virtual GPU driver for virtio. It can be used with
> > >QEMU based VMMs (like KVM or Xen).
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > index 6a232553c99b..7c60e7486bc4 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > > spinlock_t resource_export_lock;
> > > /* protects map state and host_visible_mm */
> > > spinlock_t host_visible_lock;
> > > +
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > + atomic64_t total_mem;
> > > +#endif
> > > };
> > >
> > > struct virtio_gpu_fpriv {
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > index d69a5b6da553..1e16226cebbe 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > @@ -25,12 +25,29 @@
> > >
> > > #include
> > > #include
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > +#include
> > > +#endif
> > >
> > > #include "virtgpu_drv.h"
> > >
> > > static int virtio_gpu_virglrenderer_workaround = 1;
> > > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> > > 0400);
> > >
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > *vgdev,
> > > + s64 delta)
> > > +{
> > > + u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> > > +
> > > + trace_gpu_mem_total(0, 0, total_mem);
> > > +}
> > > +#else
> > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > *, s64)
> > > +{
> > > +}
> > > +#endif
> > > +
> > > int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> > > *resid)
> > > {
> > > if (virtio_gpu_virglrenderer_workaround) {
> > > @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct
> > > drm_gem_object *obj)
> > > struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
> > >
> > > if (bo->created) {
> > > + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > > virtio_gpu_notify(vgdev);
> > > /* completion handler calls virtio_gpu_cleanup_object() */
> > > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_de
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang wrote:
>
> On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > > >
> > > > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang
> > > > wrote:
> > > > >
> > > > > On the success of virtio_gpu_object_create, add size of newly
> > > > > allocated
> > > > > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the
> > > > > gem
> > > > > bo lost its last refcount, subtract the bo size from the tracked
> > > > > total_mem if the original underlying memory allocation is successful.
> > > > >
> > > > > Signed-off-by: Yiwei Zhang
> > > >
> > > > Isn't this something that ideally we'd for everyone? Also tracepoint
> > > > for showing the total feels like tracepoint abuse, usually we show
> > > > totals somewhere in debugfs or similar, and tracepoint just for what's
> > > > happening (i.e. which object got deleted/created).
> > > >
> > > > What is this for exactly?
> > > > -Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/virtio/Kconfig | 1 +
> > > > > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > > > > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > > > > 3 files changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/virtio/Kconfig
> > > > > b/drivers/gpu/drm/virtio/Kconfig
> > > > > index b925b8b1da16..e103b7e883b1 100644
> > > > > --- a/drivers/gpu/drm/virtio/Kconfig
> > > > > +++ b/drivers/gpu/drm/virtio/Kconfig
> > > > > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > > > > select DRM_KMS_HELPER
> > > > > select DRM_GEM_SHMEM_HELPER
> > > > > select VIRTIO_DMA_SHARED_BUFFER
> > > > > + select TRACE_GPU_MEM
> > > > > help
> > > > >This is the virtual GPU driver for virtio. It can be used
> > > > > with
> > > > >QEMU based VMMs (like KVM or Xen).
> > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > index 6a232553c99b..7c60e7486bc4 100644
> > > > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > > > > spinlock_t resource_export_lock;
> > > > > /* protects map state and host_visible_mm */
> > > > > spinlock_t host_visible_lock;
> > > > > +
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > + atomic64_t total_mem;
> > > > > +#endif
> > > > > };
> > > > >
> > > > > struct virtio_gpu_fpriv {
> > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > index d69a5b6da553..1e16226cebbe 100644
> > > > > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > @@ -25,12 +25,29 @@
> > > > >
> > > > > #include
> > > > > #include
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +#include
> > > > > +#endif
> > > > >
> > > > > #include "virtgpu_drv.h"
> > > > >
> > > > > static int virtio_gpu_virglrenderer_workaround = 1;
> > > > > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround,
> > > > > int, 0400);
> > > > >
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > virtio_gpu_device *vgdev,
> > > > > + s64 delta)
> > > > > +{
> > > > > + u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> > > > > +
> > > > > + trace_gpu_mem_total(0, 0, total_mem);
> > > > >
Re: [PATCH v4] drm/virtio: Track total GPU memory for virtio driver
cular device. Using which approach to account for the > overlap wouldn't block this small integration from my understanding. > > Besides, there's no plan for adding per-process gem total tracking in > virtio-gpu at this moment. This patch should be light enough to carry > without worrying about tech debt I believe. The tracepoint is clearly more generic than just what you implement here, to support the full use cases on Android's closed stacks. And it is uapi. Tech debt isn't measured in lines of code, but in how expensive it's going to be to fix up the mess in the future. uapi is expensive no matter how few lines are used to implement it. So yeah this needs to be properly thought out, properly implemented (not just on the virtual demo stack but something that looks like actual production stack), with open drivers, proper alignment with other efforts like tracking memory with cgroups, and the interactions with dma-buf tracking resolved, and igt testcases (this is meant to be generic after all), and at least solid proposals for rolling this out across the drm drivers, and ... In other words, new uapi needs to be done right. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 2/4] drm/qxl: unpin release objects
On Fri, Jan 22, 2021 at 2:35 PM Gerd Hoffmann wrote: > > On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote: > > Hi > > > > Am 20.01.21 um 12:12 schrieb Gerd Hoffmann: > > > Balances the qxl_create_bo(..., pinned=true, ...); > > > call in qxl_release_bo_alloc(). > > > > > > Signed-off-by: Gerd Hoffmann > > > --- > > > drivers/gpu/drm/qxl/qxl_release.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/qxl/qxl_release.c > > > b/drivers/gpu/drm/qxl/qxl_release.c > > > index 0fcfc952d5e9..add979cba11b 100644 > > > --- a/drivers/gpu/drm/qxl/qxl_release.c > > > +++ b/drivers/gpu/drm/qxl/qxl_release.c > > > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release) > > > entry = container_of(release->bos.next, > > > struct qxl_bo_list, tv.head); > > > bo = to_qxl_bo(entry->tv.bo); > > > + bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */ > > > > This code looks like a workaround or a bug. > > > > AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you > > remove the pinned flag entirely and handle pinning as part of > > dumb_shadow_bo's code. > > No, the release objects are pinned too, and they must be > pinned (qxl commands are in there, and references are > placed in the qxl rings, so allowing them to roam is > a non-starter). > > > if (pin_count) > > ttm_bo_unpin(); > > WARN_ON(pin_count); /* should always be 0 now */ > > Well, the pin_count is 1 at this point. > No need for the if(). > > Just calling ttm_bo_unpin() here makes lockdep unhappy. How does that one splat? But yeah if that's a problem should be explained in the comment. I'd then also only do a pin_count--; to make sure you can still catch other pin leaks if you have them. Setting it to 0 kinda defeats the warning. -Daniel > > Not calling ttm_bo_unpin() makes ttm_bo_release() throw > a WARN() because of the pin. > > Clearing pin_count (which is how ttm fixes things up > in the error path) works. > > I'm open to better ideas. > > take care, > Gerd > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
On Wed, Jan 27, 2021 at 01:08:05PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 17:50 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
> > > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> > > of the BO and may acquire the associated reservation object's lock.
> > > Callers that only require a mapping of the contained memory can thus
> > > interfere with other tasks that require exact pinning, such as scanout.
> > > This is less of an issue with private SHMEM buffers, but may happen
> > > with imported ones.
> > >
> > > Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
> > > drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
> > > operations. Callers have to hold the reservation lock while the mapping
> > > persists.
> > >
> > > This patch also connects GEM SHMEM helpers to GEM object functions with
> > > equivalent functionality.
> > >
> > > v4:
> > > * call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
> > > * move driver changes into separate patches (Daniel)
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
> > > include/drm/drm_gem_shmem_helper.h | 2 +
> > > 2 files changed, 84 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > index 9825c378dfa6..298832b2b43b 100644
> > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > @@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs
> > > drm_gem_shmem_funcs = {
> > > .get_sg_table = drm_gem_shmem_get_sg_table,
> > > .vmap = drm_gem_shmem_vmap,
> > > .vunmap = drm_gem_shmem_vunmap,
> > > + .vmap_local = drm_gem_shmem_vmap_local,
> > > + .vunmap_local = drm_gem_shmem_vunmap_local,
> > > .mmap = drm_gem_shmem_mmap,
> > > };
> > > @@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> > > }
> > > EXPORT_SYMBOL(drm_gem_shmem_unpin);
> > > -static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map)
> > > +static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map,
> > > + bool local)
> >
> > This is a bit spaghetti and also has the problem that we're not changing
> > shmem->vmap_use_count under different locks, depending upon which path
> > we're taking.
> >
> > I think the cleanest would be if we pull the if (import_attach) case out
> > of the _locked() version completely, for all cases, and also outside of
> > the shmem->vmap_lock. This means no caching of vmaps in the shmem layer
> > anymore for imported buffers, but this is no longer a problem: We cache
> > them in the exporters instead (I think at least, if not maybe need to fix
> > that where it's expensive).
>
> There's no vmap refcounting in amdgpu AFAICT. So importing pages from there
> into an SHMEM object has the potential of breaking. IIRC same fro radeon and
> nouveau.
As long as the pinning is refcounted I think it should be fine, it's just
that if you have multiple vmaps (e.g. 2 udl devices plugged in) we'll set
up 2 vmaps. Which is a point pointless, but not really harmful. At least
on 64bit where there's enough virtual address space.
> So I'm somewhat reluctant to making this change. I guess I'll look elsewhere
> first to fix some of the locking issues (e.g., my recent ast cursor
> patches).
If this would break for amdgpu/radeon/nouveau then we already have a bug,
since 2 udl devices can provoke this issue already as-is. So I don't think
this should be a blocker.
-Daniel
>
> Best regards
> Thomas
>
> >
> > Other option would be to unly pull it out for the _vmap_local case, but
> > that's a bit ugly because no longer symmetrical in the various paths.
> >
> > > {
> > > struct drm_gem_object *obj = &shmem->base;
> > > int ret = 0;
> > > @@ -272,7 +275,10 @@ static int drm_gem_shmem_vmap_locked(struct
> > > drm_gem_shmem_object *shmem, struct
> > > }
> > > if (obj->import_attach) {
> > > -
Re: [PATCH v4 5/5] drm/qxl: properly free qxl releases
On Tue, Jan 26, 2021 at 05:58:12PM +0100, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.h | 1 +
> drivers/gpu/drm/qxl/qxl_kms.c | 22 --
> drivers/gpu/drm/qxl/qxl_release.c | 2 ++
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 01354b43c413..1c57b587b6a7 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -214,6 +214,7 @@ struct qxl_device {
> spinlock_t release_lock;
> struct idr release_idr;
> uint32_trelease_seqno;
> + atomic_trelease_count;
> spinlock_t release_idr_lock;
> struct mutexasync_io_mutex;
> unsigned int last_sent_io_cmd;
> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> index 4a60a52ab62e..f177f72bfc12 100644
> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> @@ -25,6 +25,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -286,8 +287,25 @@ int qxl_device_init(struct qxl_device *qdev,
>
> void qxl_device_fini(struct qxl_device *qdev)
> {
> - qxl_bo_unref(&qdev->current_release_bo[0]);
> - qxl_bo_unref(&qdev->current_release_bo[1]);
> + int cur_idx, try;
> +
> + for (cur_idx = 0; cur_idx < 3; cur_idx++) {
> + if (!qdev->current_release_bo[cur_idx])
> + continue;
> + qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
> + qxl_bo_unref(&qdev->current_release_bo[cur_idx]);
> + qdev->current_release_bo_offset[cur_idx] = 0;
> + qdev->current_release_bo[cur_idx] = NULL;
> + }
> +
> + /*
> + * Ask host to release resources (+fill release ring),
> + * then wait for the release actually happening.
> + */
> + qxl_io_notify_oom(qdev);
> + for (try = 0; try < 20 && atomic_read(&qdev->release_count) > 0; try++)
> + msleep(20);
A bit icky, why not use a wait queue or something like that instead of
hand-rolling this? Not for perf reasons, just so it's a bit clear who
waits for whom and why.
-Daniel
> +
> qxl_gem_fini(qdev);
> qxl_bo_fini(qdev);
> flush_work(&qdev->gc_work);
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index 28013fd1f8ea..43a5436853b7 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -196,6 +196,7 @@ qxl_release_free(struct qxl_device *qdev,
> qxl_release_free_list(release);
> kfree(release);
> }
> + atomic_dec(&qdev->release_count);
> }
>
> static int qxl_release_bo_alloc(struct qxl_device *qdev,
> @@ -344,6 +345,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
> unsigned long size,
> *rbo = NULL;
> return idr_ret;
> }
> + atomic_inc(&qdev->release_count);
>
> mutex_lock(&qdev->release_mutex);
> if (qdev->current_release_bo_offset[cur_idx] + 1 >=
> releases_per_bo[cur_idx]) {
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/6] drm/shmem-helper: Add additional KMS helpers
set_shadow_plane(&pipe->plane);
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_simple_kms_reset_shadow_plane);
> +
> +struct drm_plane_state *
> +drm_gem_shmem_simple_kms_duplicate_shadow_plane_state(struct
> drm_simple_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state)
> +{
> + return drm_gem_shmem_duplicate_shadow_plane_state(&pipe->plane,
> plane_state);
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_simple_kms_duplicate_shadow_plane_state);
> +
> +void drm_gem_shmem_simple_kms_destroy_shadow_plane_state(struct
> drm_simple_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state)
> +{
> + drm_gem_shmem_destroy_shadow_plane_state(&pipe->plane, plane_state);
> +}
> +EXPORT_SYMBOL(drm_gem_shmem_simple_kms_destroy_shadow_plane_state);
> diff --git a/include/drm/drm_gem_shmem_kms_helper.h
> b/include/drm/drm_gem_shmem_kms_helper.h
> new file mode 100644
> index ..bd42c9c0a39e
> --- /dev/null
> +++ b/include/drm/drm_gem_shmem_kms_helper.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __DRM_GEM_SHMEM_KMS_HELPER_H__
> +#define __DRM_GEM_SHMEM_KMS_HELPER_H__
> +
> +#include
> +
> +#include
> +
> +struct drm_simple_display_pipe;
> +
> +struct drm_gem_shmem_shadow_plane_state {
> + struct drm_plane_state base;
> +
> + /* Transitional state - do not export or duplicate */
> +
> + struct dma_buf_map map[4];
> +};
> +
> +static inline struct drm_gem_shmem_shadow_plane_state *
> +to_drm_gem_shmem_shadow_plane_state(struct drm_plane_state *state)
> +{
> + return container_of(state, struct drm_gem_shmem_shadow_plane_state,
> base);
> +}
> +
> +/*
> + * Simple KMS helpers
> + */
> +
> +int drm_gem_shmem_simple_kms_prepare_shadow_fb(struct
> drm_simple_display_pipe *pipe,
> +struct drm_plane_state
> *plane_state);
> +void drm_gem_shmem_simple_kms_cleanup_shadow_fb(struct
> drm_simple_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state);
> +void drm_gem_shmem_simple_kms_reset_shadow_plane(struct
> drm_simple_display_pipe *pipe);
> +struct drm_plane_state *
> +drm_gem_shmem_simple_kms_duplicate_shadow_plane_state(struct
> drm_simple_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state);
> +void
> +drm_gem_shmem_simple_kms_destroy_shadow_plane_state(struct
> drm_simple_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state);
> +
> +/**
> + * DRM_GEM_SHMEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS -
> + * Initializes struct drm_simple_display_pipe_funcs for SHMEM shadow planes
> + *
> + * Drivers may use GEM SHMEM BOs as shadow buffers over the framebuffer
> memory. This
> + * macro initializes struct drm_simple_display_pipe_funcs to use the rsp
> helper functions.
> + */
> +#define DRM_GEM_SHMEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS \
> + .prepare_fb = drm_gem_shmem_simple_kms_prepare_shadow_fb, \
> + .cleanup_fb = drm_gem_shmem_simple_kms_cleanup_shadow_fb, \
> + .reset_plane = drm_gem_shmem_simple_kms_reset_shadow_plane, \
> + .duplicate_plane_state =
> drm_gem_shmem_simple_kms_duplicate_shadow_plane_state, \
> + .destroy_plane_state =
> drm_gem_shmem_simple_kms_destroy_shadow_plane_state
> +
> +#endif /* __DRM_GEM_SHMEM_KMS_HELPER_H__ */
> --
> 2.30.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/6] drm/shmem-helper: Add additional KMS helpers
On Wed, Feb 3, 2021 at 3:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.02.21 um 15:01 schrieb Daniel Vetter:
> > On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote:
> >> Several drivers use GEM SHMEM buffer objects as shadow buffers for
> >> the actual framebuffer memory. Right now, drivers do these vmap
> >> operations in their commit tail, which is actually not allowed by the
> >> locking rules for the dma-buf reservation lock. The involved SHMEM
> >> BO has to be vmapped in the plane's prepare_fb callback and vunmapped
> >> in cleanup_fb.
> >>
> >> This patch introduces a DRM library that implements KMS helpers for
> >> GEM SHMEM buffer objects. The first set of helpers is the plane state
> >> for shadow planes. The provided implementations for prepare_fb and
> >> cleanup_fb vmap and vunmap all BOs of struct drm_plane_state.fb. The
> >> mappings are afterwards available in the plane's commit-tail functions.
> >>
> >> All rsp drivers use the simple KMS helpers, so we add the plane callbacks
> >> and wrappers for simple KMS.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> ---
> >> drivers/gpu/drm/Kconfig| 7 +
> >> drivers/gpu/drm/Makefile | 1 +
> >> drivers/gpu/drm/drm_gem_shmem_kms_helper.c | 159 +
> >> include/drm/drm_gem_shmem_kms_helper.h | 56
> >> 4 files changed, 223 insertions(+)
> >> create mode 100644 drivers/gpu/drm/drm_gem_shmem_kms_helper.c
> >> create mode 100644 include/drm/drm_gem_shmem_kms_helper.h
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 8bf103de1594..b8d8b00ab5d4 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -214,6 +214,13 @@ config DRM_GEM_SHMEM_HELPER
> >> help
> >>Choose this if you need the GEM shmem helper functions
> >>
> >> +config DRM_GEM_SHMEM_KMS_HELPER
> >> +bool
> >> +depends on DRM_GEM_SHMEM_HELPER
> >> +help
> >> +help
> >> + Choose this if you need the GEM SHMEM helper functions for KMS
> >
> > I think we should just stuff this into simple pipe helpers directly. Also
> > needs some kerneldoc and ideally intro section of some sorts, but I guess
> > that was just missing for RFC.
>
> The missing docs is why it's an RFC. i was concerned about the
> additional simple-pipe callbacks, but I'm glad you're OK with them. I
> thought about simple_pipe state (as you mentioned below) or
> drm_private_state, but found it all too complex for this simple problem.
Yeah I think for this it's overkill, and it shouldn't be hard to add a
simple_pipe_state later on. Imo once you need a private state your
driver has proably outgrown simple pipe helpers.
> > Thinking a bit bigger and looking at the first patch, I wonder whether we
> > shouldn't outright integrate this simple pipe helpers. Adding all the
> > hooks for plane_state (instead of a simple_pipe_state or something like
> > that) feels a bit icky to me. But on the driver side the integration with
> > just the single macro line is very neat, so that's redeeming feature.
>
> I do disagree with integrating the shadow-plane code into simple-pipe.
> Right now it's SHMEM-depended and CMA-based simple-pipe drivers would
> probably not want to depend on this. The other reason is that I can
> certainly generalize the shadow planes away from SHMEM helpers; and use
> them for these vbox and ast patchsets as well. These drivers use VRAM
> helpers and full KMS helpers. I guess shadow planes could then be moved
> into drm_gem_framebuffer.c. There's other plane-helper code there already.
>
> Unfortunately, I only realized this after sending out the patch set. :)
Yeah I also noticed we have the current simple gem fb helper in there
already, so maybe just stuff it in there. Whether the simple glue for
shme/gem/cma/whatever integration is in drm_simple_pipe.c or
drm_gem_framebuffer.c kinda doesn't matter much. Just yet another
library felt a bit like overkill.
Cheers, Daniel
>
> Best regards
> Thomas
>
> >
> > Note doing a drm_simple_display_pipe_state would be a bit tricky to do,
> > since we'd need custome duplicate_state functions to make sure there's
> > only ever exactly one:
> >
> > struct drm_simple_display_pipe_state {
> > struct drm_crtc_state crtc_state;
> > struct drm_plane_state plane_state;
> >
> &
Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
t file *filp, void *data);
> +
> +struct virtio_vdmabuf_ioctl_desc {
> + unsigned int cmd;
> + int flags;
> + virtio_vdmabuf_ioctl_t func;
> + const char *name;
> +};
> +
> +#define VIRTIO_VDMABUF_IOCTL_DEF(ioctl, _func, _flags) \
> + [_IOC_NR(ioctl)] = {\
> + .cmd = ioctl, \
> + .func = _func, \
> + .flags = _flags,\
> + .name = #ioctl \
> +}
> +
> +#define VIRTIO_VDMABUF_VMID(buf_id) buf_id).id) >> 32) & 0x)
> +
> +/* Messages between Host and Guest */
> +
> +/* List of commands from Guest to Host:
> + *
> + * --
> + * A. NEED_VMID
> + *
> + * guest asks the host to provide its vmid
> + *
> + * req:
> + *
> + * cmd: VIRTIO_VDMABUF_NEED_VMID
> + *
> + * ack:
> + *
> + * cmd: same as req
> + * op[0] : vmid of guest
> + *
> + * --
> + * B. EXPORT
> + *
> + * export dmabuf to host
> + *
> + * req:
> + *
> + * cmd: VIRTIO_VDMABUF_CMD_EXPORT
> + * op0~op3 : HDMABUF ID
> + * op4 : number of pages to be shared
> + * op5 : offset of data in the first page
> + * op6 : length of data in the last page
> + * op7 : upper 32 bit of top-level ref of shared buf
> + * op8 : lower 32 bit of top-level ref of shared buf
> + * op9 : size of private data
> + * op10 ~ op64: User private date associated with the buffer
> + * (e.g. graphic buffer's meta info)
> + *
> + * --
> + *
> + * List of commands from Host to Guest
> + *
> + * --
> + * A. RELEASE
> + *
> + * notifying guest that the shared buffer is released by an importer
> + *
> + * req:
> + *
> + * cmd: VIRTIO_VDMABUF_CMD_DMABUF_REL
> + * op0~op3 : VDMABUF ID
> + *
> + * --
> + */
> +
> +/* msg structures */
> +struct virtio_vdmabuf_msg {
> + struct list_head list;
> + unsigned int cmd;
> + unsigned int op[64];
> +};
> +
> +enum {
> + VDMABUF_VQ_RECV = 0,
> + VDMABUF_VQ_SEND = 1,
> + VDMABUF_VQ_MAX = 2,
> +};
> +
> +enum virtio_vdmabuf_cmd {
> + VIRTIO_VDMABUF_CMD_NEED_VMID,
> + VIRTIO_VDMABUF_CMD_EXPORT = 0x10,
> + VIRTIO_VDMABUF_CMD_DMABUF_REL
> +};
> +
> +enum virtio_vdmabuf_ops {
> + VIRTIO_VDMABUF_HDMABUF_ID_ID = 0,
> + VIRTIO_VDMABUF_HDMABUF_ID_RNG_KEY0,
> + VIRTIO_VDMABUF_HDMABUF_ID_RNG_KEY1,
> + VIRTIO_VDMABUF_NUM_PAGES_SHARED = 4,
> + VIRTIO_VDMABUF_FIRST_PAGE_DATA_OFFSET,
> + VIRTIO_VDMABUF_LAST_PAGE_DATA_LENGTH,
> + VIRTIO_VDMABUF_REF_ADDR_UPPER_32BIT,
> + VIRTIO_VDMABUF_REF_ADDR_LOWER_32BIT,
> + VIRTIO_VDMABUF_PRIVATE_DATA_SIZE,
> + VIRTIO_VDMABUF_PRIVATE_DATA_START
> +};
> +
> +/* adding exported/imported vdmabuf info to hash */
> +static inline int
> +virtio_vdmabuf_add_buf(struct virtio_vdmabuf_info *info,
> + struct virtio_vdmabuf_buf *new)
> +{
> + hash_add(info->buf_list, &new->node, new->bu
Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
On Mon, Feb 08, 2021 at 08:57:48AM +0100, Gerd Hoffmann wrote: > Hi, > > > > +/* extract pages referenced by sgt */ > > > +static struct page **extr_pgs(struct sg_table *sgt, int *nents, int > > > *last_len) > > > > Nack, this doesn't work on dma-buf. And it'll blow up at runtime when you > > enable the very recently merged CONFIG_DMABUF_DEBUG (would be good to test > > with that, just to make sure). > > > Aside from this, for virtio/kvm use-cases we've already merged the udmabuf > > driver. Does this not work for your usecase? > > udmabuf can be used on the host side to make a collection of guest pages > available as host dmabuf. It's part of the puzzle, but not a complete > solution. > > As I understand it the intended workflow is this: > > (1) guest gpu driver exports some object as dma-buf > (2) dma-buf is imported into this new driver. > (3) driver sends the pages to the host. > (4) hypervisor uses udmabuf to create a host dma-buf. > (5) host dma-buf is passed on. > > And step (3) is the problematic one as this will not > work in case the dma-buf doesn't live in guest ram but > in -- for example -- gpu device memory. Yup, vram or similar special ram is the reason why an importer can't look at the pages behind a dma-buf sg table. > Reversing the driver roles in the guest (virtio driver > allocates pages and exports the dma-buf to the guest > gpu driver) should work fine. Yup, this needs to flow the other way round than in these patches. > Which btw is something you can do today with virtio-gpu. > Maybe it makes sense to have the option to run virtio-gpu > in render-only mode for that use case. Yeah that sounds like a useful addition. Also, the same flow should work for real gpus passed through as pci devices. What we need is some way to surface the dma-buf on the guest side, which I think doesn't exist yet stand-alone. But this role could be fulfilled by virtio-gpu in render-only mode I think. And (assuming I've understood the recent discussions around virtio dma-buf sharing using virtio ids) this would give you some neat zero-copy tricks for free if you share multiple devices. Also if you really want seamless buffer sharing between devices that are passed to the guest and devices on the host side (like displays I guess? or maybe video encode if this is for cloug gaming?), then using virtio-gpu in render mode should also allow you to pass the dma_fence back&forth. Which we'll need too, not just the dma-buf. So at a first guess I'd say "render-only virtio-gpu mode" sounds like something rather useful. But I might be totally off here. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote: > Platform devices might operate on firmware framebuffers, such as VESA or > EFI. Before a native driver for the graphics hardware can take over the > device, it has to remove any platform driver that operates on the firmware > framebuffer. Aperture helpers provide the infrastructure for platform > drivers to acquire firmware framebuffers, and for native drivers to remove > them later on. > > It works similar to the related fbdev mechanism. During initialization, the > platform driver acquires the firmware framebuffer's I/O memory and provides > a callback to be removed. The native driver later uses this information to > remove any platform driver for it's framebuffer I/O memory. > > The aperture removal code is integrated into the existing code for removing > conflicting framebuffers, so native drivers use it automatically. > > v2: > * rename plaform helpers to aperture helpers > * tie to device lifetime with devm_ functions > * removed unsued remove() callback > * rename kickout to detach > * make struct drm_aperture private > * rebase onto existing drm_aperture.h header file > * use MIT license only for simplicity > * documentation > > Signed-off-by: Thomas Zimmermann > Tested-by: nerdopolis Bunch of bikesheds for your considerations below, but overall lgtm. Acked-by: Daniel Vetter Cheers, Daniel > --- > Documentation/gpu/drm-internals.rst | 6 + > drivers/gpu/drm/Kconfig | 7 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/drm_aperture.c | 287 > include/drm/drm_aperture.h | 38 +++- > 5 files changed, 338 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/drm_aperture.c > > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index 4c7642d2ca34..06af044c882f 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -78,9 +78,15 @@ DRM_IOCTL_VERSION ioctl. > Managing Ownership of the Framebuffer Aperture > -- > > +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c > + :doc: overview > + > .. kernel-doc:: include/drm/drm_aperture.h > :internal: > > +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c > + :export: > + > Device Instance and Driver Handling > --- > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1461652921be..b9d3fb91d22d 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -221,6 +221,13 @@ config DRM_SCHED > tristate > depends on DRM > > +config DRM_APERTURE > + bool > + depends on DRM > + help > + Controls ownership of graphics apertures. Required to > + synchronize with firmware-based drivers. Uh I'm not a big fan of Kconfig and .ko modules for every little helper code. Imo just stuff this into the drm kms helpers and done. Or stuff it into drm core code, I think either is a good case for this. Everything is its own module means we need to EXPORT_SYMBOL more stuff, and then drivers get funny ideas about using these internals ... > + > source "drivers/gpu/drm/i2c/Kconfig" > > source "drivers/gpu/drm/arm/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 5eb5bf7c16e3..c9ecb02df0f3 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o > drm-$(CONFIG_PCI) += drm_pci.o > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o > drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > +drm-$(CONFIG_DRM_APERTURE) += drm_aperture.o > > drm_vram_helper-y := drm_gem_vram_helper.o > obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o > diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c > new file mode 100644 > index ..4b02b5fed0a1 > --- /dev/null > +++ b/drivers/gpu/drm/drm_aperture.c > @@ -0,0 +1,287 @@ > +// SPDX-License-Identifier: MIT > + > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +/** > + * DOC: overview > + * > + * A graphics device might be supported by different drivers, but only one > + * driver can be active at any given time. Many systems load a generic > + * graphics drivers, such as EFI-GOP or VESA, early during the boot process. > + * During later boot stages, they replace the generic driver with a > dedicated, &g
Re: [PATCH v2 03/10] drm/aperture: Move fbdev conflict helpers into drm_aperture.h
On Thu, Mar 18, 2021 at 11:29:14AM +0100, Thomas Zimmermann wrote:
> Fbdev's helpers for handling conflicting framebuffers are related to
> framebuffer apertures, not console emulation. Therefore move them into a
> drm_aperture.h, which will contain the interfaces for the new aperture
> helpers.
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: nerdopolis
> ---
> Documentation/gpu/drm-internals.rst | 6 +++
> include/drm/drm_aperture.h | 60 +
> include/drm/drm_fb_helper.h | 56 ++-
> 3 files changed, 69 insertions(+), 53 deletions(-)
> create mode 100644 include/drm/drm_aperture.h
>
> diff --git a/Documentation/gpu/drm-internals.rst
> b/Documentation/gpu/drm-internals.rst
> index 12272b168580..4c7642d2ca34 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -75,6 +75,12 @@ update it, its value is mostly useless. The DRM core
> prints it to the
> kernel log at initialization time and passes it to userspace through the
> DRM_IOCTL_VERSION ioctl.
>
> +Managing Ownership of the Framebuffer Aperture
> +--
> +
> +.. kernel-doc:: include/drm/drm_aperture.h
> + :internal:
> +
> Device Instance and Driver Handling
> ---
>
> diff --git a/include/drm/drm_aperture.h b/include/drm/drm_aperture.h
> new file mode 100644
> index ..13766efe9517
> --- /dev/null
> +++ b/include/drm/drm_aperture.h
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +#ifndef _DRM_APERTURE_H_
> +#define _DRM_APERTURE_H_
> +
> +#include
> +#include
> +
> +/**
> + * drm_fb_helper_remove_conflicting_framebuffers - remove
> firmware-configured framebuffers
Annoying bikeshed, but I'd give them drm_aperture_ prefixes, for ocd
consistency. Also make them real functions, they're quite big and will
grow more in the next patch.
I'm also not super happy about the naming here but oh well.
Either way: Acked-by: Daniel Vetter
> + * @a: memory range, users of which are to be removed
> + * @name: requesting driver name
> + * @primary: also kick vga16fb if present
> + *
> + * This function removes framebuffer devices (initialized by
> firmware/bootloader)
> + * which use memory range described by @a. If @a is NULL all such devices are
> + * removed.
> + */
> +static inline int
> +drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> + const char *name, bool primary)
> +{
> +#if IS_REACHABLE(CONFIG_FB)
> + return remove_conflicting_framebuffers(a, name, primary);
> +#else
> + return 0;
> +#endif
> +}
> +
> +/**
> + * drm_fb_helper_remove_conflicting_pci_framebuffers - remove
> firmware-configured
> + * framebuffers for PCI
> devices
> + * @pdev: PCI device
> + * @name: requesting driver name
> + *
> + * This function removes framebuffer devices (eg. initialized by firmware)
> + * using memory range configured for any of @pdev's memory bars.
> + *
> + * The function assumes that PCI device with shadowed ROM drives a primary
> + * display and so kicks out vga16fb.
> + */
> +static inline int
> +drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> + const char *name)
> +{
> + int ret = 0;
> +
> + /*
> + * WARNING: Apparently we must kick fbdev drivers before vgacon,
> + * otherwise the vga fbdev driver falls over.
> + */
> +#if IS_REACHABLE(CONFIG_FB)
> + ret = remove_conflicting_pci_framebuffers(pdev, name);
> +#endif
> + if (ret == 0)
> + ret = vga_remove_vgacon(pdev);
> + return ret;
> +}
> +
> +#endif
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 3b273f9ca39a..d06a3942fddb 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -30,13 +30,13 @@
> #ifndef DRM_FB_HELPER_H
> #define DRM_FB_HELPER_H
>
> -struct drm_fb_helper;
> -
> +#include
> #include
> #include
> #include
> #include
> -#include
> +
> +struct drm_fb_helper;
>
> enum mode_set_atomic {
> LEAVE_ATOMIC_MODE_SET,
> @@ -451,54 +451,4 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned
> int preferred_bpp)
>
> #endif
>
> -/**
> - * drm_fb_helper_remove_conflicting_framebuffers - remove
> firmware-configured framebuffers
> - * @a: memory range, users of which are to be removed
> - * @name: requesting d
Re: [PATCH v2 00/10] drm: Support simple-framebuffer devices and firmware fbs
his is anything but trivial to implement. For simpledrm it's a bit simple, since state recover boils down to reading out the fb and putting it into the new one, since there's not even provisions (afaiui) for simpledrm to enable/disable the output physically. So i915 is the exception here allowing flicker-free boot, not the rule. -Daniel > > BTW if you have the time I'd appreciate your review of the patchset. > > Sorry, but I'm burried under a whole pile of other work. So although I would > like to help it is better to say no. > > Regards, > > Hans > > > > > > >>> But we need to keep the display content stored in a framebuffer, so > >>> read-out helpers are required. There are more users of these read-out > >>> helpers. Adding them at some point probably makes sense. > >>> > >>> Other drivers might also want to read the initial config from simpledrm > >>> via read-out helpers. I think only i915 currently supports something like > >>> that ATM. > >>> > >>> Best regards > >>> Thomas > >>> > >>>> > >>>> An addition to the above sequence, if at any time either the kernel or > >>>> userspace > >>>> prints a message to the console; and at that time a fbdev is registered > >>>> then fbcon > >>>> will takeover as the console driver from the dummy driver and it will > >>>> start drawing > >>>> to the registered fbdev (1), destroying the framebuffer contents. Also > >>>> if any messages > >>>> where printend while no fbdev was registered, then fbcon will takeover > >>>> the console > >>>> as soon as a fbdev gets registered. > >>>> > >>>> So since we already have deferred-takeover in the fbcon code, I wonder > >>>> what you > >>>> mean when you are talking about "provide deferred takeover" for > >>>> simplekms? > >>>> > >>>> Regards, > >>>> > >>>> Hans > >>>> > >>>> > >>>> 1) Except when the VT has been switched to GFX mode when this happens, > >>>> then fbcon > >>>> will delay using the fbdev until the VT is switched back to text mode. > >>>> > >>>> > >>>> p.s. > >>>> > >>>> This has the interesting side effect then when logging into a desktop > >>>> GUI session: > >>>> kernel -> plymouth -> gdm -> GNOME user session > >>>> > >>>> There never is any output to the text-console and fbcon never > >>>> takes-over, so on > >>>> many Laptops running say Fedora workstation the fbcon code is actually > >>>> unused > >>>> until the user manually switches to another virtual-console to log in in > >>>> text-mode: > >>>> > >>>> [hans@x1 ~]$ dmesg | grep -E 'fbcon|Console:|Truecolor' > >>>> [ 0.258904] Console: colour dummy device 80x25 > >>>> [ 1.274726] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > >>>> [ 1.274768] fbcon: Deferring console take-over > >>>> [ 2.540894] fbcon: i915drmfb (fb0) is primary device > >>>> [ 2.540896] fbcon: Deferring console take-over > >>>> [hans@x1 ~]$ uptime > >>>> 12:29:39 up 4:19, 1 user, load average: 0.58, 0.75, 0.81 > >>>> > >>>> Look mom no fbcon > >>>> > >>>> > >>>> > >>>> > >>>>> * provide bootsplash DRM client > >>>>> * make simplekms usable with ARM-EFI fbs > >>>>> > >>>>> v2: > >>>>> * rename to simpledrm, aperture helpers > >>>>> * reorganized patches > >>>>> * use hotplug helpers for removal (Daniel) > >>>>> * added DT match tables (Rob) > >>>>> * use shadow-plane helpers > >>>>> * lots of minor cleanups > >>>>> > >>>>> [1] > >>>>> https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9bwmvfu-o...@mail.gmail.com/ > >>>>> [2] https://lore.kernel.org/dri-devel/1761762.3HQLrFs1K7@nerdopolis/ > >>>>> > >>>>> Thomas Zimmermann (10): > >>>>> drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip() > >>>>> drm/format-helper: Add blitter functions > >>>>> drm/aperture: Move fbdev conflict helpers into drm_aperture.h > >>>>> drm/aperture: Add infrastructure for aperture ownership > >>>>> drm: Add simpledrm driver > >>>>> drm/simpledrm: Add fbdev emulation > >>>>> drm/simpledrm: Initialize framebuffer data from device-tree node > >>>>> drm/simpledrm: Acquire clocks from DT device node > >>>>> drm/simpledrm: Acquire regulators from DT device node > >>>>> drm/simpledrm: Acquire memory aperture for framebuffer > >>>>> > >>>>> Documentation/gpu/drm-internals.rst | 12 + > >>>>> MAINTAINERS | 7 + > >>>>> drivers/gpu/drm/Kconfig | 7 + > >>>>> drivers/gpu/drm/Makefile | 1 + > >>>>> drivers/gpu/drm/drm_aperture.c | 287 > >>>>> drivers/gpu/drm/drm_format_helper.c | 96 ++- > >>>>> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > >>>>> drivers/gpu/drm/tiny/Kconfig | 17 + > >>>>> drivers/gpu/drm/tiny/Makefile | 1 + > >>>>> drivers/gpu/drm/tiny/cirrus.c | 2 +- > >>>>> drivers/gpu/drm/tiny/simpledrm.c | 932 > >>>>> + > >>>>> include/drm/drm_aperture.h | 96 +++ > >>>>> include/drm/drm_fb_helper.h | 56 +- > >>>>> include/drm/drm_format_helper.h | 10 +- > >>>>> 14 files changed, 1466 insertions(+), 60 deletions(-) > >>>>> create mode 100644 drivers/gpu/drm/drm_aperture.c > >>>>> create mode 100644 drivers/gpu/drm/tiny/simpledrm.c > >>>>> create mode 100644 include/drm/drm_aperture.h > >>>>> > >>>>> -- > >>>>> 2.30.1 > >>>>> > >>>> > >>> > >> > >> ___ > >> dri-devel mailing list > >> dri-de...@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote: > The implementation of drm_driver.dumb_map_offset is the same for several > TTM-based drivers. Provide a common function in GEM-TTM helpers. Out of curiosity, why does this not fit for radeon/amdgpu? -Daniel > > Thomas Zimmermann (4): > drm/gem-ttm-helper: Provide helper for struct > drm_driver.dumb_map_offset > drm/vram-helper: Use drm_gem_ttm_dumb_map_offset() > drm/nouveau: Use drm_gem_ttm_dumb_map_offset() > drm/qxl: Use drm_gem_ttm_dumb_map_offset() > > drivers/gpu/drm/drm_gem_ttm_helper.c | 33 > drivers/gpu/drm/drm_gem_vram_helper.c | 48 --- > drivers/gpu/drm/nouveau/nouveau_display.c | 18 - > drivers/gpu/drm/nouveau/nouveau_display.h | 2 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > drivers/gpu/drm/qxl/qxl_drv.c | 3 +- > drivers/gpu/drm/qxl/qxl_drv.h | 3 -- > drivers/gpu/drm/qxl/qxl_dumb.c| 17 > drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +- > drivers/gpu/drm/qxl/qxl_object.h | 5 --- > include/drm/drm_gem_ttm_helper.h | 5 ++- > include/drm/drm_gem_vram_helper.h | 7 +--- > 12 files changed, 45 insertions(+), 103 deletions(-) > > -- > 2.30.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers
On Thu, Apr 08, 2021 at 01:34:03PM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 13:16 schrieb Daniel Vetter: > > On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote: > > > The implementation of drm_driver.dumb_map_offset is the same for several > > > TTM-based drivers. Provide a common function in GEM-TTM helpers. > > > > Out of curiosity, why does this not fit for radeon/amdgpu? > > These drivers perform additional permission checks in their implementations. > > But those checks are also part of the actual mmap code. I want to propose a > patch to use the generic drm_gem_ttm_map_offset in amdgpu/radeon, and then > rely on mmap to fail if necessary. It might result in a longer discussion, > so that's for another patchset. Ah cool, makes sense. -Daniel > > Best regards > Thomas > > > -Daniel > > > > > > > > Thomas Zimmermann (4): > > >drm/gem-ttm-helper: Provide helper for struct > > > drm_driver.dumb_map_offset > > >drm/vram-helper: Use drm_gem_ttm_dumb_map_offset() > > >drm/nouveau: Use drm_gem_ttm_dumb_map_offset() > > >drm/qxl: Use drm_gem_ttm_dumb_map_offset() > > > > > > drivers/gpu/drm/drm_gem_ttm_helper.c | 33 > > > drivers/gpu/drm/drm_gem_vram_helper.c | 48 --- > > > drivers/gpu/drm/nouveau/nouveau_display.c | 18 - > > > drivers/gpu/drm/nouveau/nouveau_display.h | 2 - > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > > > drivers/gpu/drm/qxl/qxl_drv.c | 3 +- > > > drivers/gpu/drm/qxl/qxl_drv.h | 3 -- > > > drivers/gpu/drm/qxl/qxl_dumb.c| 17 > > > drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +- > > > drivers/gpu/drm/qxl/qxl_object.h | 5 --- > > > include/drm/drm_gem_ttm_helper.h | 5 ++- > > > include/drm/drm_gem_vram_helper.h | 7 +--- > > > 12 files changed, 45 insertions(+), 103 deletions(-) > > > > > > -- > > > 2.30.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
On Fri, Apr 09, 2021 at 09:06:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 11:48 schrieb Daniel Vetter:
> >
> > Maybe just me, but to avoid overstretching the attention spawn of doc
> > readers I'd avoid this example here. And maybe make the recommendation
> > stronger, e.g. "PCI device drivers can avoid open-coding
> > remove_conflicting_framebuffers() by calling
> > drm_fb_helper_remove_conflicting_pci_framebuffers()."
>
> It's a tutorial. In my expectation, everyone just copies the tutorial code
> and fills the gaps.
Sure, but we also have default functions for most common cases, so most
people just end up copypasting the single function call. Feels like
overkill to have a tutorial for that.
Imo tutorial/pseudo-code are good if there's more involved code flow that
many places need to copypaste and customize. Or to show how different
functions work together collectively. This doesn't quite feel like it's
clearing that bar.
And please don't get me wrong, solid docs is great. It's just that I think
we need to have reader's attention span in mind too (and mine personally
might be on the extremely short side here) to make sure our docs are
effective at conveying information.
> > > + *
> > > + * .. code-block:: c
> > > + *
> > > + * static int probe(struct pci_dev *pdev)
> > > + * {
> > > + * int ret;
> > > + *
> > > + * // Remove any generic drivers...
> > > + * ret =
> > > drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "example driver");
> > > + * if (ret)
> > > + * return ret;
> > > + *
> > > + * // ... and initialize the hardware.
> > > + * ...
> > > + *
> > > + * drm_dev_register();
> > > + *
> > > + * return 0;
> > > + * }
> > > + *
> > > + * Drivers that are susceptible to being removed be other drivers, such
> > > as
> > > + * generic EFI or VESA drivers, have to register themselves as owners of
> > > their
> > > + * given framebuffer memory. Ownership of the framebuffer memory is
> > > achived
> > > + * by calling devm_aperture_acquire(). On success, the driver is the
> > > owner
> > > + * of the framebuffer range. The function fails if the framebuffer is
> > > already
> > > + * by another driver. See below for an example.
> > > + *
> > > + * .. code-block:: c
> > > + *
> > > + * static struct drm_aperture_funcs ap_funcs = {
> > > + * .detach = ...
> >
> > Is there really value in allowing/forcing drivers to set up their own
> > detach ops? You already make this specific to struct drm_device, an
> > implementation that just calls drm_dev_unplug feels like the right thing
> > to do?
>
> Is it that easy? simepldrm's detach function has code to synchronize with
> concurrent hotplug removals. If we can use drm_dev_unplug() for everything,
> I'm all for it.
Uh, I should have looked at the code instead of just asking silly
questions :-)
Now I'm even more scared, and also more convinced that we're recreating a
bad version of some of the core driver model concepts.
I think the ideal option here would be if drm_aperture could unload
(unbind really) the platform driver for us, through the driver model. Then
there's only one place that keeps track whether the driver is unbound or
not. I'm not sure whether this can be done fully generic on a struct
device, or whether we need special code for each type. Since atm we only
have simpledrm we can just specialize on platform_device and it's good
enough.
I think best here would be to Cc: gregkh on this patch and the simpledrm
->detach implementatation, and ask for his feedback as driver model
maintainer. Maybe if you could hack together the platform_device unbind
path as proof of concept would be even better.
Either way, this is really tricky.
-Daniel
>
> Best regards
> Thomas
>
> >
> > Or maybe we should tie this more into the struct device mode and force an
> > unload that way? That way devm cleanup would work as one expects, and
> > avoid the need for anything specific (hopefully) in this detach callback.
> >
> > Just feels a bit like we're reinventing half of the driver model here,
> > badly.
> >
> > > + * };
> > > + *
> > > + * static int acquire_framebuffers(struct drm_device *dev, struct
> > > pci_dev
Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
On Fri, Apr 09, 2021 at 09:54:03AM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 11:48 schrieb Daniel Vetter: > > On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote: > > > Platform devices might operate on firmware framebuffers, such as VESA or > > > EFI. Before a native driver for the graphics hardware can take over the > > > device, it has to remove any platform driver that operates on the firmware > > > framebuffer. Aperture helpers provide the infrastructure for platform > > > drivers to acquire firmware framebuffers, and for native drivers to remove > > > them later on. > > > > > > It works similar to the related fbdev mechanism. During initialization, > > > the > > > platform driver acquires the firmware framebuffer's I/O memory and > > > provides > > > a callback to be removed. The native driver later uses this information to > > > remove any platform driver for it's framebuffer I/O memory. > > > > > > The aperture removal code is integrated into the existing code for > > > removing > > > conflicting framebuffers, so native drivers use it automatically. > > > > > > v2: > > > * rename plaform helpers to aperture helpers > > > * tie to device lifetime with devm_ functions > > > * removed unsued remove() callback > > > * rename kickout to detach > > > * make struct drm_aperture private > > > * rebase onto existing drm_aperture.h header file > > > * use MIT license only for simplicity > > > * documentation > > > > > > Signed-off-by: Thomas Zimmermann > > > Tested-by: nerdopolis > > > > Bunch of bikesheds for your considerations below, but overall lgtm. > > > > Acked-by: Daniel Vetter > > > > Cheers, Daniel > > > > > --- > > > Documentation/gpu/drm-internals.rst | 6 + > > > drivers/gpu/drm/Kconfig | 7 + > > > drivers/gpu/drm/Makefile| 1 + > > > drivers/gpu/drm/drm_aperture.c | 287 > > > include/drm/drm_aperture.h | 38 +++- > > > 5 files changed, 338 insertions(+), 1 deletion(-) > > > create mode 100644 drivers/gpu/drm/drm_aperture.c > > > > > > diff --git a/Documentation/gpu/drm-internals.rst > > > b/Documentation/gpu/drm-internals.rst > > > index 4c7642d2ca34..06af044c882f 100644 > > > --- a/Documentation/gpu/drm-internals.rst > > > +++ b/Documentation/gpu/drm-internals.rst > > > @@ -78,9 +78,15 @@ DRM_IOCTL_VERSION ioctl. > > > Managing Ownership of the Framebuffer Aperture > > > -- > > > +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c > > > + :doc: overview > > > + > > > .. kernel-doc:: include/drm/drm_aperture.h > > > :internal: > > > +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c > > > + :export: > > > + > > > Device Instance and Driver Handling > > > --- > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > > index 1461652921be..b9d3fb91d22d 100644 > > > --- a/drivers/gpu/drm/Kconfig > > > +++ b/drivers/gpu/drm/Kconfig > > > @@ -221,6 +221,13 @@ config DRM_SCHED > > > tristate > > > depends on DRM > > > +config DRM_APERTURE > > > + bool > > > + depends on DRM > > > + help > > > + Controls ownership of graphics apertures. Required to > > > + synchronize with firmware-based drivers. > > > > Uh I'm not a big fan of Kconfig and .ko modules for every little helper > > code. Imo just stuff this into the drm kms helpers and done. Or stuff it > > into drm core code, I think either is a good case for this. Everything is > > its own module means we need to EXPORT_SYMBOL more stuff, and then drivers > > get funny ideas about using these internals ... > > The code lives in the DRM core module. There's no extra ko file. But I'd > like to keep the Kconfig option. The aperture helpers will only be required > if there are generic drivers in the kernel and for many systems this is not > the case. Imo this kind of optimization is what LTO is for. Having hundreds of Kconfig symbols just to shave of 2 functions, or something like that, in each case just doesn't feel like it's justified spending of effort and complexity. Configuring out entire subsystems, sure, but not indi
Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.04.21 um 11:22 schrieb Daniel Vetter:
> > > Is it that easy? simepldrm's detach function has code to synchronize with
> > > concurrent hotplug removals. If we can use drm_dev_unplug() for
> > > everything,
> > > I'm all for it.
> >
> > Uh, I should have looked at the code instead of just asking silly
> > questions :-)
> >
> > Now I'm even more scared, and also more convinced that we're recreating
> a
> > bad version of some of the core driver model concepts.
> >
> > I think the ideal option here would be if drm_aperture could unload
> > (unbind really) the platform driver for us, through the driver model. Then
> > there's only one place that keeps track whether the driver is unbound or
> > not. I'm not sure whether this can be done fully generic on a struct
> > device, or whether we need special code for each type. Since atm we only
> > have simpledrm we can just specialize on platform_device and it's good
> > enough.
>
> I meanwhile found that calling platform_device_unregister() is the right
> thing to do. It is like a hot-unplug event. It's simple to implement and
> removes the generic device as well. Any memory ranges for the generic device
> are gone as well. Only the native driver's native device will remain. That's
> better than the existing simplefb driver.
That sounds great.
> Which unregister function to call still driver-specific, so I kept the
> callback.
Could we have the callback in core code, and you do something like
drm_aperture_acquire_platform (and later on drm_aperture_acquire_pci or
whatever, although tbh I'm not sure we ever get anything else than
platform). That function can do a runtime check that drm_device->dev is
actually a platform dev.
Another idea: Do the runtime casting in the core without anything? Atm we
have platform that needs support, maybe pci device, so we could easily
extend this and just let it do the right thing. Then no callback is
needed. I.e.
if (is_platform_dev(drm_device->dev))
platform_device_unregister(drm_device->dev);
else
WARN(1, "not yet implemented\n");
or something like that.
I just find the callback to essentially unregister a device a bit
redundant.
-Daniel
>
> Best regards
> Thomas
>
> >
> > I think best here would be to Cc: gregkh on this patch and the simpledrm
> > ->detach implementatation, and ask for his feedback as driver model
> > maintainer. Maybe if you could hack together the platform_device unbind
> > path as proof of concept would be even better.
> >
> > Either way, this is really tricky.
> > -Daniel
> >
> > >
> > > Best regards
> > > Thomas
> > >
> > > >
> > > > Or maybe we should tie this more into the struct device mode and force
> > > > an
> > > > unload that way? That way devm cleanup would work as one expects, and
> > > > avoid the need for anything specific (hopefully) in this detach
> > > > callback.
> > > >
> > > > Just feels a bit like we're reinventing half of the driver model here,
> > > > badly.
> > > >
> > > > > + * };
> > > > > + *
> > > > > + * static int acquire_framebuffers(struct drm_device *dev, struct
> > > > > pci_dev *pdev)
> > > > > + * {
> > > > > + * resource_size_t start, len;
> > > > > + * struct drm_aperture *ap;
> > > > > + *
> > > > > + * base = pci_resource_start(pdev, 0);
> > > > > + * size = pci_resource_len(pdev, 0);
> > > > > + *
> > > > > + * ap = devm_acquire_aperture(dev, base, size, &ap_funcs);
> > > > > + * if (IS_ERR(ap))
> > > > > + * return PTR_ERR(ap);
> > > > > + *
> > > > > + * return 0;
> > > > > + * }
> > > > > + *
> > > > > + * static int probe(struct pci_dev *pdev)
> > > > > + * {
> > > > > + * struct drm_device *dev;
> > > > > + * int ret;
> > > > > + *
> > > > > + * // ... Initialize the device...
> > > > > + * dev = devm_drm_dev_alloc();
> > > > > + * ...
> > > > > + *
> > > > > + * // ... and acquire
Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership
On Thu, Apr 15, 2021 at 09:12:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 15.04.21 um 14:57 schrieb Daniel Vetter: > > On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 09.04.21 um 11:22 schrieb Daniel Vetter: > > > > > Is it that easy? simepldrm's detach function has code to > > > > > synchronize > with > > > > > concurrent hotplug removals. If we can use drm_dev_unplug() for > > > > > everything, > > > > > I'm all for it. > > > > > > > > Uh, I should have looked at the code instead of just asking silly > > > > questions :-) > > > > > > > > Now I'm even more scared, and also more convinced that we're recreating > > > a > > > > bad version of some of the core driver model concepts. > > > > > > > > I think the ideal option here would be if drm_aperture could unload > > > > (unbind really) the platform driver for us, through the driver > > > > model. > Then > > > > there's only one place that keeps track whether the driver is > > > > unbound > or > > > > not. I'm not sure whether this can be done fully generic on a struct > > > > device, or whether we need special code for each type. Since atm we only > > > > have simpledrm we can just specialize on platform_device and it's good > > > > enough. > > > > > > I meanwhile found that calling platform_device_unregister() is the right > > > thing to do. It is like a hot-unplug event. It's simple to implement and > > > removes the generic device as well. Any memory ranges for the generic > > > device > > > are gone as well. Only the native driver's native device will remain. > > > That's > > > better than the existing simplefb driver. > > > > That sounds great. > > > > > Which unregister function to call still driver-specific, so I kept the > > > callback. > > > > Could we have the callback in core code, and you do something like > > drm_aperture_acquire_platform (and later on drm_aperture_acquire_pci or > > whatever, although tbh I'm not sure we ever get anything else than > > platform). That function can do a runtime check that drm_device->dev is > > actually a platform dev. > > Somehow I knew you wouldn't like the current abstraction. :) > > > > > Another idea: Do the runtime casting in the core without anything? Atm we > > have platform that needs support, maybe pci device, so we could easily > > extend this and just let it do the right thing. Then no callback is > > needed. I.e. > > > > if (is_platform_dev(drm_device->dev)) > > platform_device_unregister(drm_device->dev); > > else > > WARN(1, "not yet implemented\n"); > > > > or something like that. > > I don't like that. I spend time to remove the usb and pci device pointers > from code and structs. I don't want to introduce a new hard-coded special > case here. > > > > > I just find the callback to essentially unregister a device a bit > > redundant. > > I'd like to go with your first idea. The callback would be internal and the > public acquire function is specifically for firmware-based platform devices. > That covers simple-framebuffer, VESA, EFI, and probably any other generic > interface that fbdev supported in the last 20+ yrs. I don't think we'll ever > need anything else. > > Still, I'd like to have some abstraction between the internals of the > aperture helpers and our actual use case. I'll update the patchset > accordingly. Makes sense and I'm happy with that pick of color choice. That keeps the noise out of drivers, and also keeps the concepts clean internally. -Daniel > > Best regards > Thomas > > > -Daniel > > > > > > > > Best regards > > > Thomas > > > > > > > > > > > I think best here would be to Cc: gregkh on this patch and the simpledrm > > > > ->detach implementatation, and ask for his feedback as driver model > > > > maintainer. Maybe if you could hack together the platform_device unbind > > > > path as proof of concept would be even better. > > > > > > > > Either way, this is really tricky. > > > > -Daniel > > > > > > > > > > > > > > Best reg
Re: [PATCH] drm: Fix fbcon blank on QEMU graphics drivers
On Fri, Apr 16, 2021 at 2:53 PM Takashi Iwai wrote:
>
> Currently the DRM fbcon helper for console blank,
> drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
> returns zero, supposing the driver dealing with DPMS or atomic
> crtc->active flip to handle blanking the screen. It works on most of
> devices, but broken on most of KVM/QEMU graphics: bochs, qxl and
> cirrus drivers just ignore crtc->active state change as blanking (or
> cirrus ignoring DPMS). In practice, when you run like
> % setterm --blank force
> on a VT console, the screen freezes without actually blanking.
>
> A simple fix for this problem would be not to rely on DPMS but let
> fbcon performs the generic blank code. This can be achieved just by
> returning an error from drm_fb_helper_blank().
>
> In this patch, we add a flag, no_dpms_blank, to drm_fb_helper for
> indicating that the driver doesn't handle blank via DPMS or
> crtc->active flip. When this flag is set, drm_fb_helper_blank()
> simply returns an error, so that fbcon falls back to its generic blank
> handler. The flag is set to both bochs and qxl drivers in this patch,
> while cirrus is left untouched as it's declared as to-be-deprecated.
>
> Link: https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1095700
> Signed-off-by: Takashi Iwai
Uh we're supposed to fix these drivers to actually blank (scan out
black, worst case), not paper over it in higher levels. Atomic kms is
meant to be a somewhat useful abstraction. So now fbcon blanks, but
your desktop still just freezes.
> ---
>
> Here I whip a dead horse again, revisiting the long-standing issue
> stated in the previous patch set in 2017:
> https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/
>
> I thought to refresh the previous patch set at first, but it seems
> invalid for the atomic modeset case. And for the atomic, it's even
> more difficult to propagate the return from the bottom to up.
> So I ended up with this approach as it's much simpler.
Yeah that's because atomic assume you can at least blank your screen to black.
-Daniel
> But if there is any better way (even simpler or more robust), I'd
> happily rewrite, too.
>
> ---
> drivers/gpu/drm/bochs/bochs_drv.c | 3 +++
> drivers/gpu/drm/drm_fb_helper.c | 5 +
> drivers/gpu/drm/qxl/qxl_drv.c | 3 +++
> include/drm/drm_fb_helper.h | 8
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index b469624fe40d..816899a266ff 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -132,6 +132,9 @@ static int bochs_pci_probe(struct pci_dev *pdev,
> goto err_unload;
>
> drm_fbdev_generic_setup(dev, 32);
> + if (dev->fb_helper)
> + dev->fb_helper->no_dpms_blank = true;
> +
> return ret;
>
> err_unload:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6baa2046124..b892f02ff2f1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -332,9 +332,14 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> */
> int drm_fb_helper_blank(int blank, struct fb_info *info)
> {
> + struct drm_fb_helper *fb_helper = info->par;
> +
> if (oops_in_progress)
> return -EBUSY;
>
> + if (fb_helper->no_dpms_blank)
> + return -EINVAL;
> +
> switch (blank) {
> /* Display: On; HSync: On, VSync: On */
> case FB_BLANK_UNBLANK:
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 1864467f1063..58ecfaeed7c1 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -120,6 +120,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> goto modeset_cleanup;
>
> drm_fbdev_generic_setup(&qdev->ddev, 32);
> + if (qdev->fb_helper)
> + qdev->fb_helper->no_dpms_blank = true;
> +
> return 0;
>
> modeset_cleanup:
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 3b273f9ca39a..151be4219c32 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -176,6 +176,14 @@ struct drm_fb_helper {
> */
> bool deferred_setup;
>
> + /**
> +* @no_dpms_blank:
> +*
> +* A flag indicating that the driver doesn't support blan
Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs
On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > Hi Thomas, > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > wrote: > > This patchset adds support for simple-framebuffer platform devices and > > a handover mechanism for native drivers to take-over control of the > > hardware. > > > > The new driver, called simpledrm, binds to a simple-frambuffer platform > > device. The kernel's boot code creates such devices for firmware-provided > > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot > > loader sets up the framebuffers. Description via device tree is also an > > option. > > I guess this can be used as a replacement for offb, too... > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During > > if support for 8-bit frame buffers would be added? Is that 8-bit greyscale or 8-bit indexed with 256 entry palette? Former shouldn't be a big thing, but the latter is only really supported by the overall drm ecosystem in theory. Most userspace assumes that xrgb works, and we keep that illusion up by emulating it in kernel for hw which just doesn't support it. But reformatting xrgb to c8 is tricky at best. The uapis are all there for setting the palette, and C8 is a defined format even with atomic kms interface, but really there's not much userspace for it. In other words, it would work as well as current offb would, but that's at least that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs
On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote: > Hi Daniel, > > On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote: > > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > > > wrote: > > > > This patchset adds support for simple-framebuffer platform devices and > > > > a handover mechanism for native drivers to take-over control of the > > > > hardware. > > > > > > > > The new driver, called simpledrm, binds to a simple-frambuffer platform > > > > device. The kernel's boot code creates such devices for > > > > firmware-provided > > > > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot > > > > loader sets up the framebuffers. Description via device tree is also an > > > > option. > > > > > > I guess this can be used as a replacement for offb, too... > > > > > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM > > > > helpers > > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. > > > > During > > > > > > if support for 8-bit frame buffers would be added? > > > > Is that 8-bit greyscale or 8-bit indexed with 256 entry palette? Former > > 8-bit indexed with 256 entry palette. > > > shouldn't be a big thing, but the latter is only really supported by the > > overall drm ecosystem in theory. Most userspace assumes that xrgb > > works, and we keep that illusion up by emulating it in kernel for hw which > > just doesn't support it. But reformatting xrgb to c8 is tricky at > > best. The uapis are all there for setting the palette, and C8 is a defined > > format even with atomic kms interface, but really there's not much > > userspace for it. In other words, it would work as well as current offb > > would, but that's at least that. > > Oh, that's good to know! > Does this mean fbdev is not deprecated for anything <= C8? ;-) Nope. It just means you wont be able to use drm-only userspace with it most likely, without also investing a ton of effort into porting those over. > A while ago, I was looking into converting an fbdev driver to drm, and > one of the things I ran into is lack of C4, C2, C1, Y8, Y4, Y2, and > monochrome support. On top of that, lots of internal code seems to > assume pixels are never smaller than a byte (thus ignoring > char_per_block[]/block_w). The lack of support for planar modes isn't > that bad, combined with the need for copying, as c2p conversion can be > done while copying, thus even making life easier for userspace > applications that can just always work on chunky data. > Then real work kicked in, before I got anything working... We support drm_fourcc, so adding more pixel formats is not problem at all. Anything indexed/paletted will simply not work great with unchanged drm userspace, because you can't really convert it over from the common denominator of xrgb888. But if it's just about adding support, adding more fourcc codes isn't a big deal. The fbdev layer hasn't been taught about fourcc codes yet, but that's also just for lack of need by anyone. Also we support abitrary uneven pixel packing too, with some generic support for anything that's at least somewhat regular. That's been the case for a while now. It was added for fancy tiling and compression formats, but works equally well for anything else that's aligned different than what can be described with simplistic bytes-per-pixel only. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs
On Mon, Apr 26, 2021 at 02:18:05PM +0200, Thomas Zimmermann wrote: > Hi > > Am 20.04.21 um 10:46 schrieb Daniel Vetter: > > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > > Hi Thomas, > > > > > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > > > wrote: > > > > This patchset adds support for simple-framebuffer platform devices and > > > > a handover mechanism for native drivers to take-over control of the > > > > hardware. > > > > > > > > The new driver, called simpledrm, binds to a simple-frambuffer platform > > > > device. The kernel's boot code creates such devices for > > > > firmware-provided > > > > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot > > > > loader sets up the framebuffers. Description via device tree is also an > > > > option. > > > > > > I guess this can be used as a replacement for offb, too... > > > > > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM > > > > helpers > > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. > > > > During > > > > > > if support for 8-bit frame buffers would be added? > > Offb doesn't seem to be tied to the simple-framebuffer support. So adding a > new driver or extending the simple-framebuffer code would be required. Not a > big deal, though. Patch 3 of this patchset adds the ability to create > generic drivers within DRM. > > > > > Is that 8-bit greyscale or 8-bit indexed with 256 entry palette? Former > > shouldn't be a big thing, but the latter is only really supported by the > > overall drm ecosystem in theory. Most userspace assumes that xrgb > > works, and we keep that illusion up by emulating it in kernel for hw which > > just doesn't support it. But reformatting xrgb to c8 is tricky at > > best. The uapis are all there for setting the palette, and C8 is a defined > > format even with atomic kms interface, but really there's not much > > userspace for it. In other words, it would work as well as current offb > > would, but that's at least that. > > I think we can just use a shadow palette in the drm driver: If the drm > framebuffer is in C8, use the userspace's palette. If the drm framebuffer is > in XRGB, use a palette that represents RGB332. The driver would do > on-the-fly conversion; just like cirrus does. Hm yeah rgb332 palette sounds like a reasonable idea. Could even have that palette defined/generated in format conversion helpers, and then an xrgb->rgb332 converter. Lower palettes probably stop making sense as rgb, maybe there we just do greyscale or something like that for the xrgb emulation. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/3] drm/bochs: Move to tiny/
On Wed, Jun 30, 2021 at 04:06:57PM +0200, Thomas Zimmermann wrote: > The bochs driver is only ~600 lines of code. Putting it into tiny/ > cleans up the DRM directory slightly. Some style problems were fixed > and unneeded include statements were removed. No functional changes. > > Signed-off-by: Thomas Zimmermann Really nice! On the series: Acked-by: Daniel Vetter I think I've found one missing static below. Cheers, Daniel > --- > MAINTAINERS | 2 +- > drivers/gpu/drm/Kconfig | 2 - > drivers/gpu/drm/Makefile | 1 - > drivers/gpu/drm/bochs/Kconfig | 11 - > drivers/gpu/drm/bochs/Makefile| 4 - > drivers/gpu/drm/bochs/bochs.h | 98 > drivers/gpu/drm/bochs/bochs_drv.c | 205 > drivers/gpu/drm/bochs/bochs_hw.c | 323 - > drivers/gpu/drm/bochs/bochs_kms.c | 178 --- > drivers/gpu/drm/bochs/bochs_mm.c | 24 - > drivers/gpu/drm/tiny/Kconfig | 13 + > drivers/gpu/drm/tiny/Makefile | 1 + > drivers/gpu/drm/tiny/bochs.c | 768 ++ > 13 files changed, 783 insertions(+), 847 deletions(-) > delete mode 100644 drivers/gpu/drm/bochs/Kconfig > delete mode 100644 drivers/gpu/drm/bochs/Makefile > delete mode 100644 drivers/gpu/drm/bochs/bochs.h > delete mode 100644 drivers/gpu/drm/bochs/bochs_drv.c > delete mode 100644 drivers/gpu/drm/bochs/bochs_hw.c > delete mode 100644 drivers/gpu/drm/bochs/bochs_kms.c > delete mode 100644 drivers/gpu/drm/bochs/bochs_mm.c > create mode 100644 drivers/gpu/drm/tiny/bochs.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index dcb5f0d32303..95bad8d45200 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5680,7 +5680,7 @@ M: Gerd Hoffmann > L: virtualization@lists.linux-foundation.org > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > -F: drivers/gpu/drm/bochs/ > +F: drivers/gpu/drm/tiny/bochs.c > > DRM DRIVER FOR BOE HIMAX8279D PANELS > M: Jerry Han > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1366d8d4610a..0d372354c2d0 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -322,8 +322,6 @@ source "drivers/gpu/drm/tilcdc/Kconfig" > > source "drivers/gpu/drm/qxl/Kconfig" > > -source "drivers/gpu/drm/bochs/Kconfig" > - > source "drivers/gpu/drm/virtio/Kconfig" > > source "drivers/gpu/drm/msm/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 12e6f4e485ed..ad1112154898 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -98,7 +98,6 @@ obj-y += omapdrm/ > obj-$(CONFIG_DRM_SUN4I) += sun4i/ > obj-y+= tilcdc/ > obj-$(CONFIG_DRM_QXL) += qxl/ > -obj-$(CONFIG_DRM_BOCHS) += bochs/ > obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/ > obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig > deleted file mode 100644 > index 7bcdf294fed8.. > --- a/drivers/gpu/drm/bochs/Kconfig > +++ /dev/null > @@ -1,11 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0-only > -config DRM_BOCHS > - tristate "DRM Support for bochs dispi vga interface (qemu stdvga)" > - depends on DRM && PCI && MMU > - select DRM_KMS_HELPER > - select DRM_VRAM_HELPER > - select DRM_TTM > - select DRM_TTM_HELPER > - help > - Choose this option for qemu. > - If M is selected the module will be called bochs-drm. > diff --git a/drivers/gpu/drm/bochs/Makefile b/drivers/gpu/drm/bochs/Makefile > deleted file mode 100644 > index 55473371300f.. > --- a/drivers/gpu/drm/bochs/Makefile > +++ /dev/null > @@ -1,4 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0-only > -bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_hw.o > - > -obj-$(CONFIG_DRM_BOCHS) += bochs-drm.o > diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h > deleted file mode 100644 > index e9645c612aff.. > --- a/drivers/gpu/drm/bochs/bochs.h > +++ /dev/null > @@ -1,98 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > - > -#include > -#include > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -/* -- */ > - > -#define VBE_DISPI_IOPORT_INDEX 0x01CE > -#define VBE_DISPI_IOPORT_DATA0x01CF > - > -#define VBE_DISPI_INDEX_ID 0x0 > -#define VBE_DISPI_INDEX_XRES
Re: [PATCH v7 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification
On Mon, 17 Oct 2022 at 19:25, Dmitry Osipenko
wrote:
>
> Move dma_buf_mmap() function to the dynamic locking specification by
> taking the reservation lock. Neither of the today's drivers take the
> reservation lock within the mmap() callback, hence it's safe to enforce
> the locking.
>
> Acked-by: Sumit Semwal
> Acked-by: Christian König
> Signed-off-by: Dmitry Osipenko
Just noticed this while reading code ... this patch seems to have
missed dma_buf_mmap_internal()?
Might be good if at least some drivers gain a dma_resv_assert_held in
that path to make sure we're not quite this bad, together with fixing
this issue.
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f54c649f922a..f149b384f4dd 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1390,6 +1390,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
> int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
> unsigned long pgoff)
> {
> + int ret;
> +
> if (WARN_ON(!dmabuf || !vma))
> return -EINVAL;
>
> @@ -1410,7 +1412,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
> vm_area_struct *vma,
> vma_set_file(vma, dmabuf->file);
> vma->vm_pgoff = pgoff;
>
> - return dmabuf->ops->mmap(dmabuf, vma);
> + dma_resv_lock(dmabuf->resv, NULL);
> + ret = dmabuf->ops->mmap(dmabuf, vma);
> + dma_resv_unlock(dmabuf->resv);
> +
> + return ret;
> }
> EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
>
> --
> 2.37.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/qxl: Fix missing free_irq
On Tue, Nov 08, 2022 at 11:16:01PM +0800, Wei Li wrote:
> When doing "cat /proc/interrupts" after qxl.ko is unloaded, an oops occurs:
>
> BUG: unable to handle page fault for address: c0274769
> PGD 2a0d067 P4D 2a0d067 PUD 2a0f067 PMD 103f39067 PTE 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 6 PID: 246 Comm: cat Not tainted 6.1.0-rc2 #24
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1
> 04/01/2014
> RIP: 0010:string_nocheck+0x34/0x50
> Code: 66 85 c0 74 3c 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88
> 07 48 83 c7
> RSP: 0018:c9893bb8 EFLAGS: 00010046
> RAX: RBX: c9893c50 RCX: 0a00ff04
> RDX: c0274769 RSI: 888102812000 RDI: 88810281133e
> RBP: 888102812000 R08: 823fa5e6 R09: 0007
> R10: 888102812000 R11: 88820281133d R12: c0274769
> R13: 0a00ff04 R14: 0cc4 R15: 823276b4
> FS: 0214f8c0() GS:88842fd8() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: c0274769 CR3: 0001025c4005 CR4: 00770ee0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> PKRU: 5554
> Call Trace:
>
> string+0x46/0x60
> vsnprintf+0x27a/0x4f0
> seq_vprintf+0x34/0x50
> seq_printf+0x53/0x70
> ? seq_read_iter+0x365/0x450
> show_interrupts+0x259/0x330
> seq_read_iter+0x2a3/0x450
> proc_reg_read_iter+0x47/0x70
> generic_file_splice_read+0x94/0x160
> splice_direct_to_actor+0xb0/0x230
> ? do_splice_direct+0xd0/0xd0
> do_splice_direct+0x8b/0xd0
> do_sendfile+0x345/0x4f0
> __x64_sys_sendfile64+0xa1/0xc0
> do_syscall_64+0x38/0x90
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x4bb0ce
> Code: c3 0f 1f 00 4c 89 d2 4c 89 c6 e9 bd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f
> 1f 44 00 00
> RSP: 002b:7ffd99dc3fb8 EFLAGS: 0246 ORIG_RAX: 0028
> RAX: ffda RBX: 0100 RCX: 004bb0ce
> RDX: RSI: 0003 RDI: 0001
> RBP: 0001 R08: 0068f240 R09: 0100
> R10: 0100 R11: 0246 R12: 0003
> R13: 0001 R14: R15:
>
>
> It seems that qxl doesn't free the interrupt it requests during unload,
> fix this by adding the missing free_irq().
>
> Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
> Signed-off-by: Wei Li
Could we go right ahead and switch over to devm_request_irq? Or does that
not quite do the right thing here?
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_kms.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> index dc3828db1991..d591084824de 100644
> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> @@ -283,6 +283,8 @@ int qxl_device_init(struct qxl_device *qdev,
> void qxl_device_fini(struct qxl_device *qdev)
> {
> int cur_idx;
> + struct drm_device *ddev = &qdev->ddev;
> + struct pci_dev *pdev = to_pci_dev(ddev->dev);
>
> /* check if qxl_device_init() was successful (gc_work is initialized
> last) */
> if (!qdev->gc_work.func)
> @@ -305,6 +307,7 @@ void qxl_device_fini(struct qxl_device *qdev)
> wait_event_timeout(qdev->release_event,
> atomic_read(&qdev->release_count) == 0,
> HZ);
> + free_irq(pdev->irq, ddev);
> flush_work(&qdev->gc_work);
> qxl_surf_evict(qdev);
> qxl_vram_evict(qdev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] drm/fb-helper: Don't use the preferred depth for the BPP default
On Wed, Nov 16, 2022 at 05:09:17PM +0100, Thomas Zimmermann wrote:
> If no preferred value for bits-per-pixel has been given, fall back
> to 32. Never use the preferred depth. The color depth is the number
> of color/alpha bits per pixel, while bpp is the overall number of
> bits in most cases.
>
> Most noteworthy, XRGB has a depth of 24 and a bpp value of 32.
> Using depth for bpp would make the value 24 as well and format
> selection in fbdev helpers fails. Unfortunately XRGB is the most
> common format and the old heuristic therefore fails for most of
> the drivers (unless they implement the 24-bit RGB888 format).
>
> Picking a bpp of 32 will lateron result in a default depth of 24
> and the format XRGB. As XRGB is the default format for most
> of the current and legacy graphics stack, all drivers must support
> it. So it is the safe choice.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fbdev_generic.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index ab86956692795..0a4c160e0e58a 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -431,7 +431,6 @@ static const struct drm_client_funcs
> drm_fbdev_client_funcs = {
> * drm_fbdev_generic_setup() - Setup generic fbdev emulation
> * @dev: DRM device
> * @preferred_bpp: Preferred bits per pixel for the device.
> - * @dev->mode_config.preferred_depth is used if this is zero.
> *
> * This function sets up generic fbdev emulation for drivers that supports
> * dumb buffers with a virtual address and that can be mmap'ed.
> @@ -475,12 +474,16 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
> }
>
> /*
> - * FIXME: This mixes up depth with bpp, which results in a glorious
> - * mess, resulting in some drivers picking wrong fbdev defaults and
> - * others wrong preferred_depth defaults.
> + * Pick a preferred bpp of 32 if no value has been given. This
> + * will select XRGB for the framebuffer formats. All drivers
> + * have to support XRGB for backwards compatibility with legacy
> + * userspace, so it's the safe choice here.
> + *
> + * TODO: Replace struct drm_mode_config.preferred_depth and this
> + * bpp value with a preferred format that is given as struct
> + * drm_format_info. Then derive all other values from the
> + * format.
I concur on this being the right design. What I've attempted years ago,
but never managed to finish, is sort the formats list on the primary plane
in preference order (since that seems useful for other reasons), and then
let everyone derive the preferred_whatever from the first format of the
first primary plane automatically.
But doing that is a pretty huge refactor, since you get to audit every
driver. So I kinda gave up on that. But I still thing something in that
direction would be a good design overall, since then userspace could also
use the same trick to infer format preferences ...
Anyway on the series, since it pushes in a direction I wanted to fix years
ago but gave up because too ambitious :-)
Acked-by: Daniel Vetter
>*/
> - if (!preferred_bpp)
> - preferred_bpp = dev->mode_config.preferred_depth;
> if (!preferred_bpp)
> preferred_bpp = 32;
> fb_helper->preferred_bpp = preferred_bpp;
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v10 00/11] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote: > On 1/27/23 11:13, Gerd Hoffmann wrote: > > On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote: > >> Hello Thomas and Gerd, > >> > >> On 1/9/23 00:04, Dmitry Osipenko wrote: > >>> This series: > >>> > >>> 1. Makes minor fixes for drm_gem_lru and Panfrost > >>> 2. Brings refactoring for older code > >>> 3. Adds common drm-shmem memory shrinker > >>> 4. Enables shrinker for VirtIO-GPU driver > >>> 5. Switches Panfrost driver to the common shrinker > >>> > >>> Changelog: > >>> > >>> v10:- Rebased on a recent linux-next. > >>> > >>> - Added Rob's ack to MSM "Prevent blocking within shrinker loop" > >>> patch. > >>> > >>> - Added Steven's ack/r-b/t-b for the Panfrost patches. > >>> > >>> - Fixed missing export of the new drm_gem_object_evict() function. > >>> > >>> - Added fixes tags to the first two patches that are making minor > >>> fixes, > >>> for consistency. > >> > >> Do you have comments on this version? Otherwise ack will be appreciated. > >> Thanks in advance! > > > > Don't feel like signing off on the locking changes, I'm not that > > familiar with the drm locking rules. So someone else looking at them > > would be good. Otherwise the series and specifically the virtio changes > > look good to me. > > > > Acked-by: Gerd Hoffmann > > Thomas was looking at the the DRM core changes. I expect he'll ack them. > > Thank you for reviewing the virtio patches! I think best-case would be an ack from msm people that this looks good (even better a conversion for msm to start using this). Otherwise I think the locking looks reasonable, I think the tricky bits have been moving the dma-buf rules, but if you want I can try to take another in-depth look. But would need to be in 2 weeks since I'm going on vacations, pls ping me on irc if I'm needed. Otherwise would be great if we can land this soon, so that it can soak the entire linux-next cycle to catch any driver specific issues. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v10 00/11] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On Thu, Feb 16, 2023 at 11:43:38PM +0300, Dmitry Osipenko wrote: > On 2/16/23 15:15, Daniel Vetter wrote: > > On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote: > >> On 1/27/23 11:13, Gerd Hoffmann wrote: > >>> On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote: > >>>> Hello Thomas and Gerd, > >>>> > >>>> On 1/9/23 00:04, Dmitry Osipenko wrote: > >>>>> This series: > >>>>> > >>>>> 1. Makes minor fixes for drm_gem_lru and Panfrost > >>>>> 2. Brings refactoring for older code > >>>>> 3. Adds common drm-shmem memory shrinker > >>>>> 4. Enables shrinker for VirtIO-GPU driver > >>>>> 5. Switches Panfrost driver to the common shrinker > >>>>> > >>>>> Changelog: > >>>>> > >>>>> v10:- Rebased on a recent linux-next. > >>>>> > >>>>> - Added Rob's ack to MSM "Prevent blocking within shrinker loop" > >>>>> patch. > >>>>> > >>>>> - Added Steven's ack/r-b/t-b for the Panfrost patches. > >>>>> > >>>>> - Fixed missing export of the new drm_gem_object_evict() function. > >>>>> > >>>>> - Added fixes tags to the first two patches that are making minor > >>>>> fixes, > >>>>> for consistency. > >>>> > >>>> Do you have comments on this version? Otherwise ack will be appreciated. > >>>> Thanks in advance! > >>> > >>> Don't feel like signing off on the locking changes, I'm not that > >>> familiar with the drm locking rules. So someone else looking at them > >>> would be good. Otherwise the series and specifically the virtio changes > >>> look good to me. > >>> > >>> Acked-by: Gerd Hoffmann > >> > >> Thomas was looking at the the DRM core changes. I expect he'll ack them. > >> > >> Thank you for reviewing the virtio patches! > > > > I think best-case would be an ack from msm people that this looks good > > (even better a conversion for msm to start using this). > > The MSM pretty much isn't touched by this patchset, apart from the minor > common shrinker fix. Moving whole MSM to use drm_shmem should be a big > change to the driver. > > The Panfrost and VirtIO-GPU drivers already got the acks. I also tested > the Lima driver, which uses drm-shmem helpers. Other DRM drivers should > be unaffected by this series. Ah that sounds good, I somehow thought that etnaviv also uses the helpers, but there we only had problems with dma-buf. So that's all sorted. > > Otherwise I think the locking looks reasonable, I think the tricky bits > > have been moving the dma-buf rules, but if you want I can try to take > > another in-depth look. But would need to be in 2 weeks since I'm going on > > vacations, pls ping me on irc if I'm needed. > > The locking conversion is mostly a straightforward replacement of mutex > with resv lock for drm-shmem. The dma-buf rules were tricky, another > tricky part was fixing the lockdep warning for the bogus report of > fs_reclaim vs GEM shrinker at the GEM destroy time where I borrowed the > drm_gem_shmem_resv_assert_held() solution from the MSM driver where Rob > had a similar issue. Ah I missed that detail, if msm solved that the same way then I think very high chances it all ends up being compatible. Which is really what matters, not so much whether every last driver actually has converted over. > > Otherwise would be great if we can land this soon, so that it can soak the > > entire linux-next cycle to catch any driver specific issues. > > That will be great. Was waiting for Thomas to ack the shmem patches > since he reviewed the previous versions, but if you or anyone else could > ack them, then will be good too. Thanks! I'm good for an ack, but maybe ping Thomas for a review on irc since I'm out next week. Also maybe Thomas has some series you can help land for cross review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] drm/virtio: Add option to disable KMS support
if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) {
> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) &&
> + virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_EDID)) {
> vgdev->has_edid = true;
> }
> if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) {
> @@ -218,17 +219,19 @@ int virtio_gpu_init(struct virtio_device *vdev, struct
> drm_device *dev)
> goto err_vbufs;
> }
>
> - /* get display info */
> - virtio_cread_le(vgdev->vdev, struct virtio_gpu_config,
> - num_scanouts, &num_scanouts);
> - vgdev->num_scanouts = min_t(uint32_t, num_scanouts,
> - VIRTIO_GPU_MAX_SCANOUTS);
> - if (!vgdev->num_scanouts) {
> - DRM_ERROR("num_scanouts is zero\n");
> - ret = -EINVAL;
> - goto err_scanouts;
> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) {
> + /* get display info */
> + virtio_cread_le(vgdev->vdev, struct virtio_gpu_config,
> + num_scanouts, &num_scanouts);
> + vgdev->num_scanouts = min_t(uint32_t, num_scanouts,
> + VIRTIO_GPU_MAX_SCANOUTS);
> + if (!vgdev->num_scanouts) {
> + DRM_ERROR("num_scanouts is zero\n");
> + ret = -EINVAL;
> + goto err_scanouts;
> + }
> + DRM_INFO("number of scanouts: %d\n", num_scanouts);
> }
> - DRM_INFO("number of scanouts: %d\n", num_scanouts);
>
> virtio_cread_le(vgdev->vdev, struct virtio_gpu_config,
> num_capsets, &num_capsets);
> @@ -246,10 +249,12 @@ int virtio_gpu_init(struct virtio_device *vdev, struct
> drm_device *dev)
> virtio_gpu_get_capsets(vgdev, num_capsets);
> if (vgdev->has_edid)
> virtio_gpu_cmd_get_edids(vgdev);
> - virtio_gpu_cmd_get_display_info(vgdev);
> - virtio_gpu_notify(vgdev);
> - wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
> -5 * HZ);
> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) {
> + virtio_gpu_cmd_get_display_info(vgdev);
> + virtio_gpu_notify(vgdev);
> + wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
> +5 * HZ);
> + }
> return 0;
>
> err_scanouts:
> --
> 2.39.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] drm/bochs: Explicitly include linux/module.h
On Wed, Apr 13, 2022 at 06:12:59PM +0200, Michel Dänzer wrote: > From: Michel Dänzer > > Instead of relying on it getting pulled in indirectly. > > Signed-off-by: Michel Dänzer Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/tiny/bochs.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c > index ed971c8bb446..4f8bf86633df 100644 > --- a/drivers/gpu/drm/tiny/bochs.c > +++ b/drivers/gpu/drm/tiny/bochs.c > @@ -1,5 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0-or-later > > +#include > #include > > #include > -- > 2.35.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Mon, Apr 18, 2022 at 10:18:54PM +0300, Dmitry Osipenko wrote:
> Hello,
>
> On 4/18/22 21:38, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
> >> Replace drm_gem_shmem locks with the reservation lock to make GEM
> >> lockings more consistent.
> >>
> >> Previously drm_gem_shmem_vmap() and drm_gem_shmem_get_pages() were
> >> protected by separate locks, now it's the same lock, but it doesn't
> >> make any difference for the current GEM SHMEM users. Only Panfrost
> >> and Lima drivers use vmap() and they do it in the slow code paths,
> >> hence there was no practical justification for the usage of separate
> >> lock in the vmap().
> >>
> >> Suggested-by: Daniel Vetter
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> ...
> >> @@ -310,7 +306,7 @@ static int drm_gem_shmem_vmap_locked(struct
> >> drm_gem_shmem_object *shmem,
> >> } else {
> >> pgprot_t prot = PAGE_KERNEL;
> >> - ret = drm_gem_shmem_get_pages(shmem);
> >> + ret = drm_gem_shmem_get_pages_locked(shmem);
> >> if (ret)
> >> goto err_zero_use;
> >> @@ -360,11 +356,11 @@ int drm_gem_shmem_vmap(struct
> >> drm_gem_shmem_object *shmem,
> >> {
> >> int ret;
> >> - ret = mutex_lock_interruptible(&shmem->vmap_lock);
> >> + ret = dma_resv_lock_interruptible(shmem->base.resv, NULL);
> >> if (ret)
> >> return ret;
> >> ret = drm_gem_shmem_vmap_locked(shmem, map);
> >
> > Within drm_gem_shmem_vmap_locked(), there's a call to dma_buf_vmap() for
> > imported pages. If the exporter side also holds/acquires the same
> > reservation lock as our object, the whole thing can deadlock. We cannot
> > move dma_buf_vmap() out of the CS, because we still need to increment
> > the reference counter. I honestly don't know how to easily fix this
> > problem. There's a TODO item about replacing these locks at [1]. As
> > Daniel suggested this patch, we should talk to him about the issue.
> >
> > Best regards
> > Thomas
> >
> > [1]
> > https://www.kernel.org/doc/html/latest/gpu/todo.html#move-buffer-object-locking-to-dma-resv-lock
>
> Indeed, good catch! Perhaps we could simply use a separate lock for the
> vmapping of the *imported* GEMs? The vmap_use_count is used only by
> vmap/vunmap, so it doesn't matter which lock is used by these functions
> in the case of imported GEMs since we only need to protect the
> vmap_use_count.
Apologies for the late reply, I'm flooded.
I discussed this with Daniel Stone last week in a chat, roughly what we
need to do is:
1. Pick a function from shmem helpers.
2. Go through all drivers that call this, and make sure that we acquire
dma_resv_lock in the top level driver entry point for this.
3. Once all driver code paths are converted, add a dma_resv_assert_held()
call to that function to make sure you have it all correctly.
4. Repeate 1-3 until all shmem helper functions are converted over.
5. Ditch the 3 different shmem helper locks.
The trouble is that I forgot that vmap is a thing, so that needs more
work. I think there's two approaches here:
- Do the vmap at import time. This is the trick we used to untangle the
dma_resv_lock issues around dma_buf_attachment_map()
- Change the dma_buf_vmap rules that callers must hold the dma_resv_lock.
- Maybe also do what you suggest and keep a separate lock for this, but
the fundamental issue is that this doesn't really work - if you share
buffers both ways with two drivers using shmem helpers, then the
ordering of this vmap_count_mutex vs dma_resv_lock is inconsistent and
you can get some nice deadlocks. So not a great approach (and also the
reason why we really need to get everyone to move towards dma_resv_lock
as _the_ buffer object lock, since otherwise we'll never get a
consistent lock nesting hierarchy).
The trouble here is that trying to be clever and doing the conversion just
in shmem helpers wont work, because there's a lot of cases where the
drivers are all kinds of inconsistent with their locking.
Adding Daniel S, also maybe for questions it'd be fastest to chat on irc?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
geable state, and a bo in purgeable state should not be allowed to be pinned. - Drivers need to hold dma_resv_lock for long enough in their command submission, i.e. from the point where the reserve the buffers and make sure that mappings exists, to the point where the request is submitted to hw or drm/sched and fences are installed. But I think a lot of current shmem users just pin as part of execbuf, so this won't work quite so well right out of the box. Anyway with that design I don't think there should ever be a need to disable shrinking. > >> + > >> + /** > >> + * @pages_state: Current state of shmem pages. Used internally by > >> + * memory shrinker. > >> + */ > >> + enum drm_gem_shmem_pages_state pages_state; > >> + > >> + /** > >> + * @evicted: True if shmem pages were evicted by the memory > >> shrinker. > >> + * Used internally by memory shrinker. > >> + */ > >> + bool evicted; > >> + > >> + /** > >> + * @pages_shrinkable: True if shmem pages can be evicted or purged > >> + * by the memory shrinker. Used internally by memory shrinker. > >> + */ > >> + bool pages_shrinkable; > > > > As commented before, this state can be foundby looking at existing > > fields. No need to store it separately. > > When we're transitioning from "evictable" to a "purgeable" state, we > must not add pages twice to the "shrinkable_count" variable. Hence this > is not a state, but a variable which prevents the double accounting of > the pages. Please see drm_gem_shmem_add_pages_to_shrinker() in this patch. > > Perhaps something like "pages_accounted_by_shrinker" could be a better > name for the variable. I'll revisit this for v5. Hm not sure we need to account this? Usually the shrinker just counts when it's asked to do so, not practively maintain that count. Once you start shrinking burning cpu time is generally not too terrible. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v5 15/17] drm/shmem-helper: Make drm_gem_shmem_get_pages() private
On Sun, Apr 24, 2022 at 10:04:22PM +0300, Dmitry Osipenko wrote:
> VirtIO-GPU driver was the only user of drm_gem_shmem_get_pages()
> and it now uses drm_gem_shmem_get_pages_sgt(). Make the get_pages()
> private to drm_gem_shmem_helper.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +--
> include/drm/drm_gem_shmem_helper.h | 1 -
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 25e9bc2803ee..7ec5f8002f68 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -490,7 +490,7 @@ static int drm_gem_shmem_get_pages_locked(struct
> drm_gem_shmem_object *shmem)
> * Returns:
> * 0 on success or a negative error code on failure.
> */
We also delete the kerneldoc for functions not exported (kerneldoc is
geared towards driver writes). If there's anything critical the comment
explains about the internals, you can keep that as a normal C style
comment without the /** but generally there's no need for these anymore.
-Daniel
> -int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> {
> int ret;
>
> @@ -507,7 +507,6 @@ int drm_gem_shmem_get_pages(struct drm_gem_shmem_object
> *shmem)
>
> return ret;
> }
> -EXPORT_SYMBOL(drm_gem_shmem_get_pages);
>
> static void drm_gem_shmem_get_pages_no_fail(struct drm_gem_shmem_object
> *shmem)
> {
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index 638cb16a4576..5b351933c293 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -180,7 +180,6 @@ struct drm_gem_shmem_object {
> struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
> size_t size);
> void drm_gem_shmem_free(struct drm_gem_shmem_object *shmem);
>
> -int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem);
> void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem);
> int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem);
> void drm_gem_shmem_unpin(struct drm_gem_shmem_object *shmem);
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Thu, Apr 28, 2022 at 09:31:00PM +0300, Dmitry Osipenko wrote:
> Hello Daniel,
>
> 27.04.2022 17:50, Daniel Vetter пишет:
> > On Mon, Apr 18, 2022 at 10:18:54PM +0300, Dmitry Osipenko wrote:
> >> Hello,
> >>
> >> On 4/18/22 21:38, Thomas Zimmermann wrote:
> >>> Hi
> >>>
> >>> Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
> >>>> Replace drm_gem_shmem locks with the reservation lock to make GEM
> >>>> lockings more consistent.
> >>>>
> >>>> Previously drm_gem_shmem_vmap() and drm_gem_shmem_get_pages() were
> >>>> protected by separate locks, now it's the same lock, but it doesn't
> >>>> make any difference for the current GEM SHMEM users. Only Panfrost
> >>>> and Lima drivers use vmap() and they do it in the slow code paths,
> >>>> hence there was no practical justification for the usage of separate
> >>>> lock in the vmap().
> >>>>
> >>>> Suggested-by: Daniel Vetter
> >>>> Signed-off-by: Dmitry Osipenko
> >>>> ---
> >> ...
> >>>> @@ -310,7 +306,7 @@ static int drm_gem_shmem_vmap_locked(struct
> >>>> drm_gem_shmem_object *shmem,
> >>>> } else {
> >>>> pgprot_t prot = PAGE_KERNEL;
> >>>> - ret = drm_gem_shmem_get_pages(shmem);
> >>>> + ret = drm_gem_shmem_get_pages_locked(shmem);
> >>>> if (ret)
> >>>> goto err_zero_use;
> >>>> @@ -360,11 +356,11 @@ int drm_gem_shmem_vmap(struct
> >>>> drm_gem_shmem_object *shmem,
> >>>> {
> >>>> int ret;
> >>>> - ret = mutex_lock_interruptible(&shmem->vmap_lock);
> >>>> + ret = dma_resv_lock_interruptible(shmem->base.resv, NULL);
> >>>> if (ret)
> >>>> return ret;
> >>>> ret = drm_gem_shmem_vmap_locked(shmem, map);
> >>>
> >>> Within drm_gem_shmem_vmap_locked(), there's a call to dma_buf_vmap() for
> >>> imported pages. If the exporter side also holds/acquires the same
> >>> reservation lock as our object, the whole thing can deadlock. We cannot
> >>> move dma_buf_vmap() out of the CS, because we still need to increment
> >>> the reference counter. I honestly don't know how to easily fix this
> >>> problem. There's a TODO item about replacing these locks at [1]. As
> >>> Daniel suggested this patch, we should talk to him about the issue.
> >>>
> >>> Best regards
> >>> Thomas
> >>>
> >>> [1]
> >>> https://www.kernel.org/doc/html/latest/gpu/todo.html#move-buffer-object-locking-to-dma-resv-lock
> >>
> >> Indeed, good catch! Perhaps we could simply use a separate lock for the
> >> vmapping of the *imported* GEMs? The vmap_use_count is used only by
> >> vmap/vunmap, so it doesn't matter which lock is used by these functions
> >> in the case of imported GEMs since we only need to protect the
> >> vmap_use_count.
> >
> > Apologies for the late reply, I'm flooded.
> >
> > I discussed this with Daniel Stone last week in a chat, roughly what we
> > need to do is:
> >
> > 1. Pick a function from shmem helpers.
> >
> > 2. Go through all drivers that call this, and make sure that we acquire
> > dma_resv_lock in the top level driver entry point for this.
> >
> > 3. Once all driver code paths are converted, add a dma_resv_assert_held()
> > call to that function to make sure you have it all correctly.
> > 4. Repeate 1-3 until all shmem helper functions are converted over.
> Somehow I didn't notice the existence of dma_resv_assert_held(), thank
> you for the suggestion :)
>
> >
> > 5. Ditch the 3 different shmem helper locks.
> >
> > The trouble is that I forgot that vmap is a thing, so that needs more
> > work. I think there's two approaches here:
> > - Do the vmap at import time. This is the trick we used to untangle the
> > dma_resv_lock issues around dma_buf_attachment_map()
>
> > - Change the dma_buf_vmap rules that callers must hold the dma_resv_lock.
>
> I'll consider this option for v6, thank you.
>
> I see now that you actually want to define the new rules for the
> dma-bufs in general and not only in the context of the DRM code, this
> now makes much more sense to me.
Yeah dma-buf is a cross driver inter
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Thu, Apr 28, 2022 at 09:20:15PM +0300, Dmitry Osipenko wrote:
> 27.04.2022 18:03, Daniel Vetter wrote:
> >> ...
> >>>> @@ -172,6 +172,41 @@ struct drm_gem_object_funcs {
> >>>> * This is optional but necessary for mmap support.
> >>>> */
> >>>> const struct vm_operations_struct *vm_ops;
> >>>> +
> >>>> + /**
> >>>> + * @purge:
> >>>> + *
> >>>> + * Releases the GEM object's allocated backing storage to the
> >>>> system.
> >>>> + *
> >>>> + * Returns the number of pages that have been freed by purging
> >>>> the GEM object.
> >>>> + *
> >>>> + * This callback is used by the GEM shrinker.
> >>>> + */
> >>>> + unsigned long (*purge)(struct drm_gem_object *obj);
> >
> > Hm I feel like drivers shouldn't need to know the difference here?
> >
> > Like shmem helpers can track what's purgeable, and for eviction/purging
> > the driver callback should do the same?
> >
> > The only difference is when we try to re-reserve the backing storage. When
> > the object has been evicted that should suceed, but when the object is
> > purged that will fail.
> >
> > That's the difference between evict and purge for drivers?
>
> When buffer is purged, we can permanently release the backing storage
> and the reserved IOV space, re-using the freed space by new BOs.
>
> When buffer is evicted, the BO's IOV should be kept reserved and the
> re-reservation of the backing storage should succeed.
Yeah but what's the difference for driver callbacks? In both cases the
driver callback needs to tear down gpu mappings and pagetables. The only
difference happens after that in the shmem helper: For purge we ditch the
shmem object, for evict we keep it. Drivers shouldn't need to care about
that difference, hence why the two callbacks?
>
> >>>> +
> >>>> + /**
> >>>> + * @evict:
> >>>> + *
> >>>> + * Unpins the GEM object's allocated backing storage, allowing
> >>>> shmem pages
> >>>> + * to be swapped out.
> >>>
> >>> What's the difference to the existing unpin() callback?
> >>
> >> Drivers need to do more than just unpinning pages when GEMs are evicted.
> >> Unpinning is only a part of the eviction process. I'll improve the
> >> doc-comment in v5.
> >>
> >> For example, for VirtIO-GPU driver we need to to detach host from the
> >> guest's memory before pages are evicted [1].
> >>
> >> [1]
> >> https://gitlab.collabora.com/dmitry.osipenko/linux-kernel-rd/-/blob/932eb03198bce3a21353b09ab71e95f1c19b84c2/drivers/gpu/drm/virtio/virtgpu_object.c#L145
> >>
> >> In case of Panfrost driver, we will need to remove mappings before pages
> >> are evicted.
> >
> > It might be good to align this with ttm, otoh that all works quite a bit
> > differently for ttm since ttm supports buffer moves and a lot more fancy
> > stuff.
> >
> > I'm bringing this up since I have this fancy idea that eventually we could
> > glue shmem helpers into ttm in some cases for managing buffers when they
> > sit in system memory (as opposed to vram).
>
> I'll take a look at ttm for v6.
>
> >>>> + *
> >>>> + * Returns the number of pages that have been unpinned.
> >>>> + *
> >>>> + * This callback is used by the GEM shrinker.
> >>>> + */
> >>>> + unsigned long (*evict)(struct drm_gem_object *obj);
> >>>> +
> >>>> + /**
> >>>> + * @swap_in:
> >>>> + *
> >>>> + * Pins GEM object's allocated backing storage if it was
> >>>> previously evicted,
> >>>> + * moving swapped out pages back to memory.
> >>>> + *
> >>>> + * Returns 0 on success, or -errno on error.
> >>>> + *
> >>>> + * This callback is used by the GEM shrinker.
> >>>> + */
> >>>> + int (*swap_in)(struct drm_gem_object *obj);
> >>>
> >>> Why do you need swap_in()? This can be done on-demand as part of a pin
> >>> or vmap operation.
> >>
> >> Similarly to the unpinning, the pining of pages is only a part of what
> >&g
Re: [PATCH 4/4] drm/qxl: add drm_gem_plane_helper_prepare_fb
On Fri, Apr 29, 2022 at 03:42:30PM +0200, Christian König wrote: > We could need to wait for the pin to complete here. > > Signed-off-by: Christian König > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc: virtualization@lists.linux-foundation.org > Cc: spice-de...@lists.freedesktop.org Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/qxl/qxl_display.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/qxl/qxl_display.c > b/drivers/gpu/drm/qxl/qxl_display.c > index 9a9c29b1d3e1..9a64fa4c7530 100644 > --- a/drivers/gpu/drm/qxl/qxl_display.c > +++ b/drivers/gpu/drm/qxl/qxl_display.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include "qxl_drv.h" > #include "qxl_object.h" > @@ -829,6 +830,7 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane, > struct qxl_device *qdev = to_qxl(plane->dev); > struct drm_gem_object *obj; > struct qxl_bo *user_bo; > + int ret; > > if (!new_state->fb) > return 0; > @@ -852,7 +854,11 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane, > qxl_free_cursor(old_cursor_bo); > } > > - return qxl_bo_pin(user_bo); > + ret = qxl_bo_pin(user_bo); > + if (ret) > + return ret; > + > + return drm_gem_plane_helper_prepare_fb(plane, new_state); > } > > static void qxl_plane_cleanup_fb(struct drm_plane *plane, > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote: > On 5/4/22 11:21, Daniel Vetter wrote: > ... > >>> - Maybe also do what you suggest and keep a separate lock for this, but > >>> the fundamental issue is that this doesn't really work - if you share > >>> buffers both ways with two drivers using shmem helpers, then the > >>> ordering of this vmap_count_mutex vs dma_resv_lock is inconsistent and > >>> you can get some nice deadlocks. So not a great approach (and also the > >>> reason why we really need to get everyone to move towards dma_resv_lock > >>> as _the_ buffer object lock, since otherwise we'll never get a > >>> consistent lock nesting hierarchy). > >> > >> The separate locks should work okay because it will be always the > >> exporter that takes the dma_resv_lock. But I agree that it's less ideal > >> than defining the new rules for dma-bufs since sometime you will take > >> the resv lock and sometime not, potentially hiding bugs related to > >> lockings. > > > > That's the issue, some importers need to take the dma_resv_lock for > > dma_buf_vmap too (e.g. to first nail the buffer in place when it's a > > dynamic memory manager). In practice it'll work as well as what we have > > currently, which is similarly inconsistent, except with per-driver locks > > instead of shared locks from shmem helpers or dma-buf, so less obvious > > that things are inconsistent. > > > > So yeah if it's too messy maybe the approach is to have a separate lock > > for vmap for now, land things, and then fix up dma_buf_vmap in a follow up > > series. > > The amdgpu driver was the fist who introduced the concept of movable > memory for dma-bufs. Now we want to support it for DRM SHMEM too. For > both amdgpu ttm and shmem drivers we will want to hold the reservation > lock when we're touching moveable buffers. The current way of denoting > that dma-buf is movable is to implement the pin/unpin callbacks of the > dma-buf ops, should be doable for shmem. Hm that sounds like a bridge too far? I don't think we want to start adding moveable dma-bufs for shmem, thus far at least no one asked for that. Goal here is just to streamline the locking a bit and align across all the different ways of doing buffers in drm. Or do you mean something else and I'm just completely lost? > A day ago I found that mapping of imported dma-bufs is broken at least > for the Tegra DRM driver (and likely for others too) because driver > doesn't assume that anyone will try to mmap imported buffer and just > doesn't handle this case at all, so we're getting a hard lockup on > touching mapped memory because we're mapping something else than the > dma-buf. Huh that sounds bad, how does this happen? Pretty much all pieces of dma-buf (cpu vmap, userspace mmap, heck even dma_buf_attach) are optional or at least can fail for various reasons. So exporters not providing mmap support is fine, but importers then dying is not. > My plan is to move the dma-buf management code to the level of DRM core > and make it aware of the reservation locks for the dynamic dma-bufs. > This way we will get the proper locking for dma-bufs and fix mapping of > imported dma-bufs for Tegra and other drivers. So maybe we're completely talking past each another, or coffee is not working here on my end, but I've no idea what you mean. We do have some helpers for taking care of the dma_resv_lock dance, and Christian König has an rfc patch set to maybe unify this further. But that should be fairly orthogonal to reworking shmem (it might help a bit with reworking shmem though). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
e);
> > + mutex_init(&gem_shrinker->lock);
> > +
> > + dev->shmem_shrinker = gem_shrinker;
> > +
> > + err = register_shrinker(&gem_shrinker->base);
> > + if (err) {
> > + dev->shmem_shrinker = NULL;
> > + kfree(gem_shrinker);
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_gem_shmem_shrinker_register);
> > +
> > +/**
> > + * drm_gem_shmem_shrinker_unregister() - Unregister shmem shrinker
> > + * @dev: DRM device
> > + */
> > +void drm_gem_shmem_shrinker_unregister(struct drm_device *dev)
> > +{
> > + struct drm_gem_shmem_shrinker *gem_shrinker = dev->shmem_shrinker;
> > +
> > + if (gem_shrinker) {
> > + unregister_shrinker(&gem_shrinker->base);
> > + WARN_ON(!list_empty(&gem_shrinker->lru_purgeable));
> > + WARN_ON(!list_empty(&gem_shrinker->lru_evictable));
> > + WARN_ON(!list_empty(&gem_shrinker->lru_evicted));
> > + WARN_ON(!list_empty(&gem_shrinker->lru_active));
> > + mutex_destroy(&gem_shrinker->lock);
> > + dev->shmem_shrinker = NULL;
> > + kfree(gem_shrinker);
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(drm_gem_shmem_shrinker_unregister);
> > +
> > MODULE_DESCRIPTION("DRM SHMEM memory-management helpers");
> > MODULE_IMPORT_NS(DMA_BUF);
> > MODULE_LICENSE("GPL v2");
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index 9923c7a6885e..929546cad894 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -16,6 +16,7 @@ struct drm_vblank_crtc;
> > struct drm_vma_offset_manager;
> > struct drm_vram_mm;
> > struct drm_fb_helper;
> > +struct drm_gem_shmem_shrinker;
> > struct inode;
> > @@ -277,6 +278,9 @@ struct drm_device {
> > /** @vram_mm: VRAM MM memory manager */
> > struct drm_vram_mm *vram_mm;
> > + /** @shmem_shrinker: SHMEM GEM memory shrinker */
> > + struct drm_gem_shmem_shrinker *shmem_shrinker;
> > +
> > /**
> > * @switch_power_state:
> > *
> > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > index 9d7c61a122dc..390d1ce08ed3 100644
> > --- a/include/drm/drm_gem.h
> > +++ b/include/drm/drm_gem.h
> > @@ -172,6 +172,41 @@ struct drm_gem_object_funcs {
> > * This is optional but necessary for mmap support.
> > */
> > const struct vm_operations_struct *vm_ops;
> > +
> > + /**
> > + * @purge:
> > +*
> > +* Releases the GEM object's allocated backing storage to the system.
> > +*
> > +* Returns the number of pages that have been freed by purging the GEM
> > object.
>
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Fri, May 06, 2022 at 01:49:12AM +0300, Dmitry Osipenko wrote: > On 5/5/22 11:12, Daniel Vetter wrote: > > On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote: > >> On 5/4/22 11:21, Daniel Vetter wrote: > >> ... > >>>>> - Maybe also do what you suggest and keep a separate lock for this, but > >>>>> the fundamental issue is that this doesn't really work - if you share > >>>>> buffers both ways with two drivers using shmem helpers, then the > >>>>> ordering of this vmap_count_mutex vs dma_resv_lock is inconsistent and > >>>>> you can get some nice deadlocks. So not a great approach (and also the > >>>>> reason why we really need to get everyone to move towards > >>>>> dma_resv_lock > >>>>> as _the_ buffer object lock, since otherwise we'll never get a > >>>>> consistent lock nesting hierarchy). > >>>> > >>>> The separate locks should work okay because it will be always the > >>>> exporter that takes the dma_resv_lock. But I agree that it's less ideal > >>>> than defining the new rules for dma-bufs since sometime you will take > >>>> the resv lock and sometime not, potentially hiding bugs related to > >>>> lockings. > >>> > >>> That's the issue, some importers need to take the dma_resv_lock for > >>> dma_buf_vmap too (e.g. to first nail the buffer in place when it's a > >>> dynamic memory manager). In practice it'll work as well as what we have > >>> currently, which is similarly inconsistent, except with per-driver locks > >>> instead of shared locks from shmem helpers or dma-buf, so less obvious > >>> that things are inconsistent. > >>> > >>> So yeah if it's too messy maybe the approach is to have a separate lock > >>> for vmap for now, land things, and then fix up dma_buf_vmap in a follow up > >>> series. > >> > >> The amdgpu driver was the fist who introduced the concept of movable > >> memory for dma-bufs. Now we want to support it for DRM SHMEM too. For > >> both amdgpu ttm and shmem drivers we will want to hold the reservation > >> lock when we're touching moveable buffers. The current way of denoting > >> that dma-buf is movable is to implement the pin/unpin callbacks of the > >> dma-buf ops, should be doable for shmem. > > > > Hm that sounds like a bridge too far? I don't think we want to start > > adding moveable dma-bufs for shmem, thus far at least no one asked for > > that. Goal here is just to streamline the locking a bit and align across > > all the different ways of doing buffers in drm. > > > > Or do you mean something else and I'm just completely lost? > > I'm talking about aligning DRM locks with the dma-buf locks. The problem > is that the convention of dma-bufs isn't specified yet. In particular > there is no convention for the mapping operations. > > If we want to switch vmapping of shmem to use reservation lock, then > somebody will have to hold this lock for dma_buf_vmap() and the locking > convention needs to be specified firmly. Ah yes that makes sense. > In case of dynamic buffers, we will also need to specify whether > dma_buf_vmap() should imply the implicit pinning by exporter or the > buffer must be pinned explicitly by importer before dma_buf_vmap() is > invoked. > > Perhaps I indeed shouldn't care about this for this patchset. The > complete locking model of dma-bufs must be specified first. Hm I thought vmap is meant to pin itself, and not rely on any other pinning done already. And from a quick look through the long call chain for amd (which is currently the only driver supporting dynamic dma-buf) that seems to be the case. But yeah the locking isn't specificied yet, and that makes it a bit a mess :-( > >> A day ago I found that mapping of imported dma-bufs is broken at least > >> for the Tegra DRM driver (and likely for others too) because driver > >> doesn't assume that anyone will try to mmap imported buffer and just > >> doesn't handle this case at all, so we're getting a hard lockup on > >> touching mapped memory because we're mapping something else than the > >> dma-buf. > > > > Huh that sounds bad, how does this happen? Pretty much all pieces of > > dma-buf (cpu vmap, userspace mmap, heck even dma_buf_attach) are optional > > or at least can fail for various reasons. So exporters not providing mmap > > s
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Fri, May 06, 2022 at 03:10:43AM +0300, Dmitry Osipenko wrote: > On 5/5/22 11:34, Thomas Zimmermann wrote: > > Hi > > > > Am 18.04.22 um 00:37 schrieb Dmitry Osipenko: > >> Introduce a common DRM SHMEM shrinker. It allows to reduce code > >> duplication among DRM drivers that implement theirs own shrinkers. > >> This is initial version of the shrinker that covers basic needs of > >> GPU drivers, both purging and eviction of shmem objects are supported. > >> > >> This patch is based on a couple ideas borrowed from Rob's Clark MSM > >> shrinker and Thomas' Zimmermann variant of SHMEM shrinker. > >> > >> In order to start using DRM SHMEM shrinker drivers should: > >> > >> 1. Implement new purge(), evict() + swap_in() GEM callbacks. > >> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device). > >> 3. Use drm_gem_shmem_set_purgeable_and_evictable(shmem) and alike API > >> functions to activate shrinking of GEMs. > > > > Honestly speaking, after reading the patch and the discussion here I > > really don't like where all tis is going. The interfaces and > > implementation are overengineered. Descisions about evicting and > > purging should be done by the memory manager. For the most part, it's > > none of the driver's business. > > Daniel mostly suggesting to make interface more flexible for future > drivers, so we won't need to re-do it later on. My version of the > interface is based on what drivers need today. > > Why do you think it's a problem to turn shmem helper into the simple > generic memory manager? I don't see how it's better to have drivers > duplicating the exactly same efforts and making different mistakes. > > The shmem shrinker implementation is mostly based on the freedreno's > shrinker and it's very easy to enable generic shrinker for VirtIO and > Panfrost drivers. I think in the future freedreno and other drivers > could switch to use drm shmem instead of open coding the memory management. Yeah I think we have enough shrinkers all over drm to actually design something solid here. There's also the i915 shrinker and some kinda shrinker in ttm too. So we are definitely past the "have 3 examples to make sure you design something solid" rule of thumb. I also have a bit an idea that we could try to glue the shmem shrinker into ttm, at least at a very high level that's something that would make some sense. > > I'd like to ask you to reduce the scope of the patchset and build the > > shrinker only for virtio-gpu. I know that I first suggested to build > > upon shmem helpers, but it seems that it's easier to do that in a later > > patchset. > > The first version of the VirtIO shrinker didn't support memory eviction. > Memory eviction support requires page fault handler to be aware of the > evicted pages, what should we do about it? The page fault handling is a > part of memory management, hence to me drm-shmem is already kinda a MM. Hm I still don't get that part, why does that also not go through the shmem helpers? I'm still confused why drivers need to know the difference between evition and purging. Or maybe I'm confused again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote: > On 5/9/22 16:42, Daniel Vetter wrote: > > On Fri, May 06, 2022 at 01:49:12AM +0300, Dmitry Osipenko wrote: > >> On 5/5/22 11:12, Daniel Vetter wrote: > >>> On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote: > >>>> On 5/4/22 11:21, Daniel Vetter wrote: > >>>> ... > >>>>>>> - Maybe also do what you suggest and keep a separate lock for this, > >>>>>>> but > >>>>>>> the fundamental issue is that this doesn't really work - if you > >>>>>>> share > >>>>>>> buffers both ways with two drivers using shmem helpers, then the > >>>>>>> ordering of this vmap_count_mutex vs dma_resv_lock is inconsistent > >>>>>>> and > >>>>>>> you can get some nice deadlocks. So not a great approach (and also > >>>>>>> the > >>>>>>> reason why we really need to get everyone to move towards > >>>>>>> dma_resv_lock > >>>>>>> as _the_ buffer object lock, since otherwise we'll never get a > >>>>>>> consistent lock nesting hierarchy). > >>>>>> > >>>>>> The separate locks should work okay because it will be always the > >>>>>> exporter that takes the dma_resv_lock. But I agree that it's less ideal > >>>>>> than defining the new rules for dma-bufs since sometime you will take > >>>>>> the resv lock and sometime not, potentially hiding bugs related to > >>>>>> lockings. > >>>>> > >>>>> That's the issue, some importers need to take the dma_resv_lock for > >>>>> dma_buf_vmap too (e.g. to first nail the buffer in place when it's a > >>>>> dynamic memory manager). In practice it'll work as well as what we have > >>>>> currently, which is similarly inconsistent, except with per-driver locks > >>>>> instead of shared locks from shmem helpers or dma-buf, so less obvious > >>>>> that things are inconsistent. > >>>>> > >>>>> So yeah if it's too messy maybe the approach is to have a separate lock > >>>>> for vmap for now, land things, and then fix up dma_buf_vmap in a follow > >>>>> up > >>>>> series. > >>>> > >>>> The amdgpu driver was the fist who introduced the concept of movable > >>>> memory for dma-bufs. Now we want to support it for DRM SHMEM too. For > >>>> both amdgpu ttm and shmem drivers we will want to hold the reservation > >>>> lock when we're touching moveable buffers. The current way of denoting > >>>> that dma-buf is movable is to implement the pin/unpin callbacks of the > >>>> dma-buf ops, should be doable for shmem. > >>> > >>> Hm that sounds like a bridge too far? I don't think we want to start > >>> adding moveable dma-bufs for shmem, thus far at least no one asked for > >>> that. Goal here is just to streamline the locking a bit and align across > >>> all the different ways of doing buffers in drm. > >>> > >>> Or do you mean something else and I'm just completely lost? > >> > >> I'm talking about aligning DRM locks with the dma-buf locks. The problem > >> is that the convention of dma-bufs isn't specified yet. In particular > >> there is no convention for the mapping operations. > >> > >> If we want to switch vmapping of shmem to use reservation lock, then > >> somebody will have to hold this lock for dma_buf_vmap() and the locking > >> convention needs to be specified firmly. > > > > Ah yes that makes sense. > > > >> In case of dynamic buffers, we will also need to specify whether > >> dma_buf_vmap() should imply the implicit pinning by exporter or the > >> buffer must be pinned explicitly by importer before dma_buf_vmap() is > >> invoked. > >> > >> Perhaps I indeed shouldn't care about this for this patchset. The > >> complete locking model of dma-bufs must be specified first. > > > > Hm I thought vmap is meant to pin itself, and not rely on any other > > pinning done already. And from a quick look through the long call chain > > for amd (which is currently the only driver supporting dynamic dma-buf)
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Tue, May 10, 2022 at 04:47:52PM +0300, Dmitry Osipenko wrote: > On 5/9/22 16:49, Daniel Vetter wrote: > > On Fri, May 06, 2022 at 03:10:43AM +0300, Dmitry Osipenko wrote: > >> On 5/5/22 11:34, Thomas Zimmermann wrote: > >>> Hi > >>> > >>> Am 18.04.22 um 00:37 schrieb Dmitry Osipenko: > >>>> Introduce a common DRM SHMEM shrinker. It allows to reduce code > >>>> duplication among DRM drivers that implement theirs own shrinkers. > >>>> This is initial version of the shrinker that covers basic needs of > >>>> GPU drivers, both purging and eviction of shmem objects are supported. > >>>> > >>>> This patch is based on a couple ideas borrowed from Rob's Clark MSM > >>>> shrinker and Thomas' Zimmermann variant of SHMEM shrinker. > >>>> > >>>> In order to start using DRM SHMEM shrinker drivers should: > >>>> > >>>> 1. Implement new purge(), evict() + swap_in() GEM callbacks. > >>>> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device). > >>>> 3. Use drm_gem_shmem_set_purgeable_and_evictable(shmem) and alike API > >>>> functions to activate shrinking of GEMs. > >>> > >>> Honestly speaking, after reading the patch and the discussion here I > >>> really don't like where all tis is going. The interfaces and > >>> implementation are overengineered. Descisions about evicting and > >>> purging should be done by the memory manager. For the most part, it's > >>> none of the driver's business. > >> > >> Daniel mostly suggesting to make interface more flexible for future > >> drivers, so we won't need to re-do it later on. My version of the > >> interface is based on what drivers need today. > >> > >> Why do you think it's a problem to turn shmem helper into the simple > >> generic memory manager? I don't see how it's better to have drivers > >> duplicating the exactly same efforts and making different mistakes. > >> > >> The shmem shrinker implementation is mostly based on the freedreno's > >> shrinker and it's very easy to enable generic shrinker for VirtIO and > >> Panfrost drivers. I think in the future freedreno and other drivers > >> could switch to use drm shmem instead of open coding the memory management. > > > > Yeah I think we have enough shrinkers all over drm to actually design > > something solid here. > > > > There's also the i915 shrinker and some kinda shrinker in ttm too. So we > > are definitely past the "have 3 examples to make sure you design something > > solid" rule of thumb. > > > > I also have a bit an idea that we could try to glue the shmem shrinker > > into ttm, at least at a very high level that's something that would make > > some sense. > > Before gluing the shmem shrinker into ttm, the drivers should be > switched to ttm? Or do you mean something else by the gluing? No, drivers which don't need ttm shouldn't be forced to use it. > Perhaps it should be possible to have a common drm-shrinker helper that > will do the basic-common things like tracking the eviction size and > check whether BO is exported or locked, but we shouldn't consider doing > this for now. For the starter more reasonable should be to create a > common shrinker base for drivers that use drm-shmem, IMO. Yeah that might be the more practical approach. But really this was just an aside, absolutely no need to worry about this for now. I just wanted to point out that there really is a lot of use for this. > >>> I'd like to ask you to reduce the scope of the patchset and build the > >>> shrinker only for virtio-gpu. I know that I first suggested to build > >>> upon shmem helpers, but it seems that it's easier to do that in a later > >>> patchset. > >> > >> The first version of the VirtIO shrinker didn't support memory eviction. > >> Memory eviction support requires page fault handler to be aware of the > >> evicted pages, what should we do about it? The page fault handling is a > >> part of memory management, hence to me drm-shmem is already kinda a MM. > > > > Hm I still don't get that part, why does that also not go through the > > shmem helpers? > > The drm_gem_shmem_vm_ops includes the page faults handling, it's a > helper by itself that is used by DRM drivers. > > I could try to move all the shrinker logic to the VirtIO an
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Wed, May 11, 2022 at 04:24:28PM +0200, Christian König wrote: > Am 11.05.22 um 15:00 schrieb Daniel Vetter: > > On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote: > > > [SNIP] > > > Since vmapping implies implicit pinning, we can't use a separate lock in > > > drm_gem_shmem_vmap() because we need to protect the > > > drm_gem_shmem_get_pages(), which is invoked by drm_gem_shmem_vmap() to > > > pin the pages and requires the dma_resv_lock to be locked. > > > > > > Hence the problem is: > > > > > > 1. If dma-buf importer holds the dma_resv_lock and invokes > > > dma_buf_vmap() -> drm_gem_shmem_vmap(), then drm_gem_shmem_vmap() shall > > > not take the dma_resv_lock. > > > > > > 2. Since dma-buf locking convention isn't specified, we can't assume > > > that dma-buf importer holds the dma_resv_lock around dma_buf_vmap(). > > > > > > The possible solutions are: > > > > > > 1. Specify the dma_resv_lock convention for dma-bufs and make all > > > drivers to follow it. > > > > > > 2. Make only DRM drivers to hold dma_resv_lock around dma_buf_vmap(). > > > Other non-DRM drivers will get the lockdep warning. > > > > > > 3. Make drm_gem_shmem_vmap() to take the dma_resv_lock and get deadlock > > > if dma-buf importer holds the lock. > > > > > > ... > > Yeah this is all very annoying. > > Ah, yes that topic again :) > > I think we could relatively easily fix that by just defining and enforcing > that the dma_resv_lock must have be taken by the caller when dma_buf_vmap() > is called. > > A two step approach should work: > 1. Move the call to dma_resv_lock() into the dma_buf_vmap() function and > remove all lock taking from the vmap callback implementations. > 2. Move the call to dma_resv_lock() into the callers of dma_buf_vmap() and > enforce that the function is called with the lock held. > > It shouldn't be that hard to clean up. The last time I looked into it my > main problem was that we didn't had any easy unit test for it. Yeah I think it's doable or at least a lot less work than the map/unmap side, which really was unfixable without just pinning at import time to avoid the locking fun. But vmap is used a lot less, and mostly by display drivers (where locking is a lot easier against dma_resv_lock), so it might be possible to pull off. -Daniel > > Regards, > Christian. > > > > > > There are actually very few drivers in kernel that use dma_buf_vmap() > > > [1], so perhaps it's not really a big deal to first try to define the > > > locking and pinning convention for the dma-bufs? At least for > > > dma_buf_vmap()? Let me try to do this. > > > > > > [1] https://elixir.bootlin.com/linux/v5.18-rc6/C/ident/dma_buf_vmap > > Yeah looking through the code there's largely two classes of drivers that > > need vmap: > > > > - display drivers that need to do cpu upload (usb, spi, i2c displays). > >Those generally set up the vmap at import time or when creating the > >drm_framebuffer object (e.g. see > >drm_gem_cma_prime_import_sg_table_vmap()), because that's really the > >only place where you can safely do that without running into locking > >inversion issues sooner or later > > > > - lots of other drivers (and shmem helpers) seem to do dma_buf_vmap just > >because they can, but only actually ever use vmap on native objects, > >never on imported objects. Or at least I think so. > > > > So maybe another approach here: > > > > 1. In general drivers which need a vmap need to set that up at dma_buf > > import time - the same way we pin the buffers at import time for > > non-dynamic importers because that's the only place where across all > > drivers it's ok to just take dma_resv_lock. > > > > 2. We remove the "just because we can" dma_buf_vmap support from > > helpers/drivers - the paths all already can cope with NULL since > > dma_buf_vmap can fail. vmap will only work on native objects, not imported > > ones. > > > > 3. If there is any driver using shmem helpers that absolutely needs vmap > > to also work on imported it needs a special import function (like cma > > helpers) which sets up the vmap at import time. > > > > So since this is all very tricky ... what did I miss this time around? > > > > > I envision that the extra dma_resv_locks for dma-bufs potentially may > > > create unnecessary bottlenecks
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Wed, May 11, 2022 at 06:14:00PM +0300, Dmitry Osipenko wrote: > On 5/11/22 17:24, Christian König wrote: > > Am 11.05.22 um 15:00 schrieb Daniel Vetter: > >> On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote: > >>> [SNIP] > >>> Since vmapping implies implicit pinning, we can't use a separate lock in > >>> drm_gem_shmem_vmap() because we need to protect the > >>> drm_gem_shmem_get_pages(), which is invoked by drm_gem_shmem_vmap() to > >>> pin the pages and requires the dma_resv_lock to be locked. > >>> > >>> Hence the problem is: > >>> > >>> 1. If dma-buf importer holds the dma_resv_lock and invokes > >>> dma_buf_vmap() -> drm_gem_shmem_vmap(), then drm_gem_shmem_vmap() shall > >>> not take the dma_resv_lock. > >>> > >>> 2. Since dma-buf locking convention isn't specified, we can't assume > >>> that dma-buf importer holds the dma_resv_lock around dma_buf_vmap(). > >>> > >>> The possible solutions are: > >>> > >>> 1. Specify the dma_resv_lock convention for dma-bufs and make all > >>> drivers to follow it. > >>> > >>> 2. Make only DRM drivers to hold dma_resv_lock around dma_buf_vmap(). > >>> Other non-DRM drivers will get the lockdep warning. > >>> > >>> 3. Make drm_gem_shmem_vmap() to take the dma_resv_lock and get deadlock > >>> if dma-buf importer holds the lock. > >>> > >>> ... > >> Yeah this is all very annoying. > > > > Ah, yes that topic again :) > > > > I think we could relatively easily fix that by just defining and > > enforcing that the dma_resv_lock must have be taken by the caller when > > dma_buf_vmap() is called. > > > > A two step approach should work: > > 1. Move the call to dma_resv_lock() into the dma_buf_vmap() function and > > remove all lock taking from the vmap callback implementations. > > 2. Move the call to dma_resv_lock() into the callers of dma_buf_vmap() > > and enforce that the function is called with the lock held. > > I've doubts about the need to move out the dma_resv_lock() into the > callers of dma_buf_vmap().. > > I looked through all the dma_buf_vmap() users and neither of them > interacts with dma_resv_lock() at all, i.e. nobody takes the lock > in/outside of dma_buf_vmap(). Hence it's easy and more practical to make > dma_buf_mmap/vmap() to take the dma_resv_lock by themselves. i915_gem_dmabuf_vmap -> i915_gem_object_pin_map_unlocked -> i915_gem_object_lock -> dma_resv_lock And all the ttm drivers should work similarly. So there's definitely drivers which grab dma_resv_lock from their vmap callback. > It's unclear to me which driver may ever want to do the mapping under > the dma_resv_lock. But if we will ever have such a driver that will need > to map imported buffer under dma_resv_lock, then we could always add the > dma_buf_vmap_locked() variant of the function. In this case the locking > rule will sound like this: > > "All dma-buf importers are responsible for holding the dma-reservation > lock around the dmabuf->ops->mmap/vmap() calls." > > > It shouldn't be that hard to clean up. The last time I looked into it my > > main problem was that we didn't had any easy unit test for it. > > Do we have any tests for dma-bufs at all? It's unclear to me what you > are going to test in regards to the reservation locks, could you please > clarify? Unfortunately not really :-/ Only way really is to grab a driver which needs vmap (those are mostly display drivers) on an imported buffer, and see what happens. 2nd best is liberally sprinkling lockdep annotations all over the place and throwing it at intel ci (not sure amd ci is accessible to the public) and then hoping that's good enough. Stuff like might_lock and dma_resv_assert_held. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Wed, May 11, 2022 at 06:40:32PM +0300, Dmitry Osipenko wrote: > On 5/11/22 18:29, Daniel Vetter wrote: > > On Wed, May 11, 2022 at 06:14:00PM +0300, Dmitry Osipenko wrote: > >> On 5/11/22 17:24, Christian König wrote: > >>> Am 11.05.22 um 15:00 schrieb Daniel Vetter: > >>>> On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote: > >>>>> [SNIP] > >>>>> Since vmapping implies implicit pinning, we can't use a separate lock in > >>>>> drm_gem_shmem_vmap() because we need to protect the > >>>>> drm_gem_shmem_get_pages(), which is invoked by drm_gem_shmem_vmap() to > >>>>> pin the pages and requires the dma_resv_lock to be locked. > >>>>> > >>>>> Hence the problem is: > >>>>> > >>>>> 1. If dma-buf importer holds the dma_resv_lock and invokes > >>>>> dma_buf_vmap() -> drm_gem_shmem_vmap(), then drm_gem_shmem_vmap() shall > >>>>> not take the dma_resv_lock. > >>>>> > >>>>> 2. Since dma-buf locking convention isn't specified, we can't assume > >>>>> that dma-buf importer holds the dma_resv_lock around dma_buf_vmap(). > >>>>> > >>>>> The possible solutions are: > >>>>> > >>>>> 1. Specify the dma_resv_lock convention for dma-bufs and make all > >>>>> drivers to follow it. > >>>>> > >>>>> 2. Make only DRM drivers to hold dma_resv_lock around dma_buf_vmap(). > >>>>> Other non-DRM drivers will get the lockdep warning. > >>>>> > >>>>> 3. Make drm_gem_shmem_vmap() to take the dma_resv_lock and get deadlock > >>>>> if dma-buf importer holds the lock. > >>>>> > >>>>> ... > >>>> Yeah this is all very annoying. > >>> Ah, yes that topic again :) > >>> > >>> I think we could relatively easily fix that by just defining and > >>> enforcing that the dma_resv_lock must have be taken by the caller when > >>> dma_buf_vmap() is called. > >>> > >>> A two step approach should work: > >>> 1. Move the call to dma_resv_lock() into the dma_buf_vmap() function and > >>> remove all lock taking from the vmap callback implementations. > >>> 2. Move the call to dma_resv_lock() into the callers of dma_buf_vmap() > >>> and enforce that the function is called with the lock held. > >> I've doubts about the need to move out the dma_resv_lock() into the > >> callers of dma_buf_vmap().. > >> > >> I looked through all the dma_buf_vmap() users and neither of them > >> interacts with dma_resv_lock() at all, i.e. nobody takes the lock > >> in/outside of dma_buf_vmap(). Hence it's easy and more practical to make > >> dma_buf_mmap/vmap() to take the dma_resv_lock by themselves. > > i915_gem_dmabuf_vmap -> i915_gem_object_pin_map_unlocked -> > > i915_gem_object_lock -> dma_resv_lock > > > > And all the ttm drivers should work similarly. So there's definitely > > drivers which grab dma_resv_lock from their vmap callback. > > Grr.. I'll take another look. > > >> It's unclear to me which driver may ever want to do the mapping under > >> the dma_resv_lock. But if we will ever have such a driver that will need > >> to map imported buffer under dma_resv_lock, then we could always add the > >> dma_buf_vmap_locked() variant of the function. In this case the locking > >> rule will sound like this: > >> > >> "All dma-buf importers are responsible for holding the dma-reservation > >> lock around the dmabuf->ops->mmap/vmap() calls." > > Are you okay with this rule? Yeah I think long-term it's where we want to be, just trying to find clever ways to get there. And I think Christian agrees with that? > >>> It shouldn't be that hard to clean up. The last time I looked into it my > >>> main problem was that we didn't had any easy unit test for it. > >> Do we have any tests for dma-bufs at all? It's unclear to me what you > >> are going to test in regards to the reservation locks, could you please > >> clarify? > > Unfortunately not really :-/ Only way really is to grab a driver which > > needs vmap (those are mostly display drivers) on an imported buffer, and > > see what happens. > > > > 2nd best is liberally sprinkling lockdep annotations all over the place > > and throwing it at intel ci (not sure amd ci is accessible to the public) > > and then hoping that's good enough. Stuff like might_lock and > > dma_resv_assert_held. > > Alright So throwing it at intel-gfx-ci can't hurt I think, but that only covers i915 so doesn't really help with the bigger issue of catching all the drivers. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote: > On 5/11/22 16:09, Daniel Vetter wrote: > >>>>> I'd like to ask you to reduce the scope of the patchset and build the > >>>>> shrinker only for virtio-gpu. I know that I first suggested to build > >>>>> upon shmem helpers, but it seems that it's easier to do that in a later > >>>>> patchset. > >>>> The first version of the VirtIO shrinker didn't support memory eviction. > >>>> Memory eviction support requires page fault handler to be aware of the > >>>> evicted pages, what should we do about it? The page fault handling is a > >>>> part of memory management, hence to me drm-shmem is already kinda a MM. > >>> Hm I still don't get that part, why does that also not go through the > >>> shmem helpers? > >> The drm_gem_shmem_vm_ops includes the page faults handling, it's a > >> helper by itself that is used by DRM drivers. > >> > >> I could try to move all the shrinker logic to the VirtIO and re-invent > >> virtio_gem_shmem_vm_ops, but what is the point of doing this for each > >> driver if we could have it once and for all in the common drm-shmem code? > >> > >> Maybe I should try to factor out all the shrinker logic from drm-shmem > >> into a new drm-shmem-shrinker that could be shared by drivers? Will you > >> be okay with this option? > > I think we're talking past each another a bit. I'm only bringing up the > > purge vs eviction topic we discussed in the other subthread again. > > Thomas asked to move the whole shrinker code to the VirtIO driver and > I's saying that this is not a great idea to me, or am I misunderstanding > the Thomas' suggestion? Thomas? I think it was just me creating a confusion here. fwiw I do also think that shrinker in shmem helpers makes sense, just in case that was also lost in confusion. > >>> I'm still confused why drivers need to know the difference > >>> between evition and purging. Or maybe I'm confused again. > >> Example: > >> > >> If userspace uses IOV addresses, then these addresses must be kept > >> reserved while buffer is evicted. > >> > >> If BO is purged, then we don't need to retain the IOV space allocated > >> for the purged BO. > > Yeah but is that actually needed by anyone? If userspace fails to allocate > > another bo because of lack of gpu address space then it's very easy to > > handle that: > > > > 1. Make a rule that "out of gpu address space" gives you a special errno > > code like ENOSPC > > > > 2. If userspace gets that it walks the list of all buffers it marked as > > purgeable and nukes them (whether they have been evicted or not). Then it > > retries the bo allocation. > > > > Alternatively you can do step 2 also directly from the bo alloc ioctl in > > step 1. Either way you clean up va space, and actually a lot more (you > > potentially nuke all buffers marked as purgeable, not just the ones that > > have been purged already) and only when va cleanup is actually needed > > > > Trying to solve this problem at eviction time otoh means: > > - we have this difference between eviction and purging > > - it's still not complete, you still need to glue step 2 above into your > > driver somehow, and once step 2 above is glued in doing additional > > cleanup in the purge function is just duplicated logic > > > > So at least in my opinion this isn't the justification we need. And we > > should definitely not just add that complication "in case, for the > > future", if we don't have a real need right now. Adding it later on is > > easy, removing it later on because it just gets in the way and confuses is > > much harder. > > The IOVA space is only one example. > > In case of the VirtIO driver, we may have two memory allocation for a > BO. One is the shmem allcation in guest and the other is in host's vram. > If we will only release the guest's memory on purge, then the vram will > remain allocated until BO is destroyed, which unnecessarily sub-optimal. Hm but why don't you just nuke the memory on the host side too when you evict? Allowing the guest memory to be swapped out while keeping the host memory allocation alive also doesn't make a lot of sense for me. Both can be recreated (I guess at least?) on swap-in. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks
On Thu, May 12, 2022 at 09:29:35AM +0200, Christian König wrote: > Am 11.05.22 um 21:05 schrieb Daniel Vetter: > > [SNIP] > > > > > It's unclear to me which driver may ever want to do the mapping under > > > > > the dma_resv_lock. But if we will ever have such a driver that will > > > > > need > > > > > to map imported buffer under dma_resv_lock, then we could always add > > > > > the > > > > > dma_buf_vmap_locked() variant of the function. In this case the > > > > > locking > > > > > rule will sound like this: > > > > > > > > > > "All dma-buf importers are responsible for holding the dma-reservation > > > > > lock around the dmabuf->ops->mmap/vmap() calls." > > > Are you okay with this rule? > > Yeah I think long-term it's where we want to be, just trying to find > > clever ways to get there. > > > > And I think Christian agrees with that? > > Yes, completely. > > A design where most DMA-buf functions are supposed to be called with the > reservation lock held is exactly what I have in mind for the long term. > > > > > > > It shouldn't be that hard to clean up. The last time I looked into > > > > > > it my > > > > > > main problem was that we didn't had any easy unit test for it. > > > > > Do we have any tests for dma-bufs at all? It's unclear to me what you > > > > > are going to test in regards to the reservation locks, could you > > > > > please > > > > > clarify? > > > > Unfortunately not really :-/ Only way really is to grab a driver which > > > > needs vmap (those are mostly display drivers) on an imported buffer, and > > > > see what happens. > > > > > > > > 2nd best is liberally sprinkling lockdep annotations all over the place > > > > and throwing it at intel ci (not sure amd ci is accessible to the > > > > public) > > > > and then hoping that's good enough. Stuff like might_lock and > > > > dma_resv_assert_held. > > > Alright > > So throwing it at intel-gfx-ci can't hurt I think, but that only covers > > i915 so doesn't really help with the bigger issue of catching all the > > drivers. > > BTW: We have now somebody working on converting the existing libdrm_amdgpu > unit tests over to igt. This sounds awesome. /me throws a happy dance Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Thu, 12 May 2022 at 13:36, Dmitry Osipenko wrote: > > On 5/11/22 22:09, Daniel Vetter wrote: > > On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote: > >> On 5/11/22 16:09, Daniel Vetter wrote: > >>>>>>> I'd like to ask you to reduce the scope of the patchset and build the > >>>>>>> shrinker only for virtio-gpu. I know that I first suggested to build > >>>>>>> upon shmem helpers, but it seems that it's easier to do that in a > >>>>>>> later > >>>>>>> patchset. > >>>>>> The first version of the VirtIO shrinker didn't support memory > >>>>>> eviction. > >>>>>> Memory eviction support requires page fault handler to be aware of the > >>>>>> evicted pages, what should we do about it? The page fault handling is a > >>>>>> part of memory management, hence to me drm-shmem is already kinda a MM. > >>>>> Hm I still don't get that part, why does that also not go through the > >>>>> shmem helpers? > >>>> The drm_gem_shmem_vm_ops includes the page faults handling, it's a > >>>> helper by itself that is used by DRM drivers. > >>>> > >>>> I could try to move all the shrinker logic to the VirtIO and re-invent > >>>> virtio_gem_shmem_vm_ops, but what is the point of doing this for each > >>>> driver if we could have it once and for all in the common drm-shmem code? > >>>> > >>>> Maybe I should try to factor out all the shrinker logic from drm-shmem > >>>> into a new drm-shmem-shrinker that could be shared by drivers? Will you > >>>> be okay with this option? > >>> I think we're talking past each another a bit. I'm only bringing up the > >>> purge vs eviction topic we discussed in the other subthread again. > >> > >> Thomas asked to move the whole shrinker code to the VirtIO driver and > >> I's saying that this is not a great idea to me, or am I misunderstanding > >> the Thomas' suggestion? Thomas? > > > > I think it was just me creating a confusion here. > > > > fwiw I do also think that shrinker in shmem helpers makes sense, just in > > case that was also lost in confusion. > > Okay, good that we're on the same page now. > > >>>>> I'm still confused why drivers need to know the difference > >>>>> between evition and purging. Or maybe I'm confused again. > >>>> Example: > >>>> > >>>> If userspace uses IOV addresses, then these addresses must be kept > >>>> reserved while buffer is evicted. > >>>> > >>>> If BO is purged, then we don't need to retain the IOV space allocated > >>>> for the purged BO. > >>> Yeah but is that actually needed by anyone? If userspace fails to allocate > >>> another bo because of lack of gpu address space then it's very easy to > >>> handle that: > >>> > >>> 1. Make a rule that "out of gpu address space" gives you a special errno > >>> code like ENOSPC > >>> > >>> 2. If userspace gets that it walks the list of all buffers it marked as > >>> purgeable and nukes them (whether they have been evicted or not). Then it > >>> retries the bo allocation. > >>> > >>> Alternatively you can do step 2 also directly from the bo alloc ioctl in > >>> step 1. Either way you clean up va space, and actually a lot more (you > >>> potentially nuke all buffers marked as purgeable, not just the ones that > >>> have been purged already) and only when va cleanup is actually needed > >>> > >>> Trying to solve this problem at eviction time otoh means: > >>> - we have this difference between eviction and purging > >>> - it's still not complete, you still need to glue step 2 above into your > >>> driver somehow, and once step 2 above is glued in doing additional > >>> cleanup in the purge function is just duplicated logic > >>> > >>> So at least in my opinion this isn't the justification we need. And we > >>> should definitely not just add that complication "in case, for the > >>> future", if we don't have a real need right now. Adding it later on is > >>> easy, removing it later on because it just gets in the way and confuses is
Re: [PATCH v4 11/15] drm/shmem-helper: Add generic memory shrinker
On Thu, May 12, 2022 at 10:04:53PM +0300, Dmitry Osipenko wrote: > On 5/12/22 20:04, Daniel Vetter wrote: > > On Thu, 12 May 2022 at 13:36, Dmitry Osipenko > > wrote: > >> > >> On 5/11/22 22:09, Daniel Vetter wrote: > >>> On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote: > >>>> On 5/11/22 16:09, Daniel Vetter wrote: > >>>>>>>>> I'd like to ask you to reduce the scope of the patchset and build > >>>>>>>>> the > >>>>>>>>> shrinker only for virtio-gpu. I know that I first suggested to build > >>>>>>>>> upon shmem helpers, but it seems that it's easier to do that in a > >>>>>>>>> later > >>>>>>>>> patchset. > >>>>>>>> The first version of the VirtIO shrinker didn't support memory > >>>>>>>> eviction. > >>>>>>>> Memory eviction support requires page fault handler to be aware of > >>>>>>>> the > >>>>>>>> evicted pages, what should we do about it? The page fault handling > >>>>>>>> is a > >>>>>>>> part of memory management, hence to me drm-shmem is already kinda a > >>>>>>>> MM. > >>>>>>> Hm I still don't get that part, why does that also not go through the > >>>>>>> shmem helpers? > >>>>>> The drm_gem_shmem_vm_ops includes the page faults handling, it's a > >>>>>> helper by itself that is used by DRM drivers. > >>>>>> > >>>>>> I could try to move all the shrinker logic to the VirtIO and re-invent > >>>>>> virtio_gem_shmem_vm_ops, but what is the point of doing this for each > >>>>>> driver if we could have it once and for all in the common drm-shmem > >>>>>> code? > >>>>>> > >>>>>> Maybe I should try to factor out all the shrinker logic from drm-shmem > >>>>>> into a new drm-shmem-shrinker that could be shared by drivers? Will you > >>>>>> be okay with this option? > >>>>> I think we're talking past each another a bit. I'm only bringing up the > >>>>> purge vs eviction topic we discussed in the other subthread again. > >>>> > >>>> Thomas asked to move the whole shrinker code to the VirtIO driver and > >>>> I's saying that this is not a great idea to me, or am I misunderstanding > >>>> the Thomas' suggestion? Thomas? > >>> > >>> I think it was just me creating a confusion here. > >>> > >>> fwiw I do also think that shrinker in shmem helpers makes sense, just in > >>> case that was also lost in confusion. > >> > >> Okay, good that we're on the same page now. > >> > >>>>>>> I'm still confused why drivers need to know the difference > >>>>>>> between evition and purging. Or maybe I'm confused again. > >>>>>> Example: > >>>>>> > >>>>>> If userspace uses IOV addresses, then these addresses must be kept > >>>>>> reserved while buffer is evicted. > >>>>>> > >>>>>> If BO is purged, then we don't need to retain the IOV space allocated > >>>>>> for the purged BO. > >>>>> Yeah but is that actually needed by anyone? If userspace fails to > >>>>> allocate > >>>>> another bo because of lack of gpu address space then it's very easy to > >>>>> handle that: > >>>>> > >>>>> 1. Make a rule that "out of gpu address space" gives you a special errno > >>>>> code like ENOSPC > >>>>> > >>>>> 2. If userspace gets that it walks the list of all buffers it marked as > >>>>> purgeable and nukes them (whether they have been evicted or not). Then > >>>>> it > >>>>> retries the bo allocation. > >>>>> > >>>>> Alternatively you can do step 2 also directly from the bo alloc ioctl in > >>>>> step 1. Either way you clean up va space, and actually a lot more (you > >>>>> potentially nuke all buffers marked as purgeable, not just the ones that > >>>>>
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
destroy(&gem_shrinker->lock);
> + dev->shmem_shrinker = NULL;
> + kfree(gem_shrinker);
> + }
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_shrinker_unregister);
> +
> MODULE_DESCRIPTION("DRM SHMEM memory-management helpers");
> MODULE_IMPORT_NS(DMA_BUF);
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
> b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
> index a4bedfeb2ec4..7cc32556f908 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
> @@ -15,6 +15,13 @@
> #include "panfrost_gem.h"
> #include "panfrost_mmu.h"
>
> +static bool panfrost_gem_shmem_is_purgeable(struct drm_gem_shmem_object
> *shmem)
> +{
> + return (shmem->madv > 0) &&
> + !shmem->pages_pin_count && shmem->sgt &&
> + !shmem->base.dma_buf && !shmem->base.import_attach;
> +}
> +
> static unsigned long
> panfrost_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control
> *sc)
> {
> @@ -27,7 +34,7 @@ panfrost_gem_shrinker_count(struct shrinker *shrinker,
> struct shrink_control *sc
> return 0;
>
> list_for_each_entry(shmem, &pfdev->shrinker_list, madv_list) {
> - if (drm_gem_shmem_is_purgeable(shmem))
> + if (panfrost_gem_shmem_is_purgeable(shmem))
> count += shmem->base.size >> PAGE_SHIFT;
> }
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index b2d93cb12ebf..81bacc7e1873 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -89,6 +89,7 @@ struct virtio_gpu_object {
> uint32_t hw_res_handle;
> bool dumb;
> bool created;
> + bool detached;
> bool host3d_blob, guest_blob;
> uint32_t blob_mem, blob_flags;
>
> @@ -453,6 +454,8 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
>
> bool virtio_gpu_is_shmem(struct virtio_gpu_object *bo);
>
> +int virtio_gpu_reattach_shmem_object(struct virtio_gpu_object *bo);
> +
> int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
>uint32_t *resid);
> /* virtgpu_prime.c */
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 9923c7a6885e..929546cad894 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -16,6 +16,7 @@ struct drm_vblank_crtc;
> struct drm_vma_offset_manager;
> struct drm_vram_mm;
> struct drm_fb_helper;
> +struct drm_gem_shmem_shrinker;
>
> struct inode;
>
> @@ -277,6 +278,9 @@ struct drm_device {
> /** @vram_mm: VRAM MM memory manager */
> struct drm_vram_mm *vram_mm;
>
> + /** @shmem_shrinker: SHMEM GEM memory shrinker */
> + struct drm_gem_shmem_shrinker *shmem_shrinker;
> +
> /**
> * @switch_power_state:
> *
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index 9a8983ee8abe..62c640678a91 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -15,6 +16,7 @@
> struct dma_buf_attachment;
> struct drm_mode_create_dumb;
> struct drm_printer;
> +struct drm_device;
> struct sg_table;
>
> /**
> @@ -39,12 +41,21 @@ struct drm_gem_shmem_object {
> */
> unsigned int pages_use_count;
>
> + /**
> +* @pages_pin_count:
> +*
> +* Reference count on the pinned pages table.
> +* The pages can be evicted by memory shrinker
> +* when the count reaches zero.
> +*/
> + unsigned int pages_pin_count;
> +
> /**
> * @madv: State for madvise
> *
> * 0 is active/inuse.
> + * 1 is not-needed/can-be-purged
> * A negative value is the object is purged.
> -* Positive values are driver specific and not used by the helpers.
> */
> int madv;
>
> @@ -91,6 +102,39 @@ struct drm_gem_shmem_object {
> * @map_wc: map object write-combined (instead of using shmem
> defaults).
> */
> bool map_wc;
> +
> + /**
> +* @eviction_enabled:
> +*
> +* The shmem pages can be evicted only if @eviction_enabled is set to
> true.
> +* Used internally by memory shrinker.
> +*/
> + bool eviction_enabled;
> +
> + /**
> +* @purge_enabled:
> +*
> +* The shmem pages can be purged only if @purge_enabled is set to
> true.
> +* Used internally by memory shrinker.
> +*/
> + bool purge_enabled;
> +
> + /**
> +* @evicted: True if shmem pages are evicted by the memory shrinker.
> +* Used internally by memory shrinker.
> +*/
> + bool evicted;
> +
> + /**
> +* @evict:
> +*
> +* Invoked by shmem shrinker before evicting shmem GEM from memory.
> +* GEM's DMA reservation is kept locked by the shrinker. This is
> +* optional callback that should be specified by drivers.
> +*
> +* Returns 0 on success, or -errno on error.
> +*/
> + int (*evict)(struct drm_gem_shmem_object *shmem);
> };
>
> #define to_drm_gem_shmem_obj(obj) \
> @@ -110,14 +154,21 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object
> *shmem, struct vm_area_struct
>
> int drm_gem_shmem_madvise(struct drm_gem_shmem_object *shmem, int madv);
>
> +int drm_gem_shmem_set_purgeable(struct drm_gem_shmem_object *shmem);
> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem);
> +
> static inline bool drm_gem_shmem_is_purgeable(struct drm_gem_shmem_object
> *shmem)
> {
> - return (shmem->madv > 0) &&
> - !shmem->vmap_use_count && shmem->sgt &&
> - !shmem->base.dma_buf && !shmem->base.import_attach;
> + return (shmem->madv > 0) && shmem->evict &&
> + shmem->purge_enabled && shmem->pages_use_count &&
> + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> + !shmem->base.import_attach && (shmem->sgt || shmem->evicted);
> }
>
> -void drm_gem_shmem_purge(struct drm_gem_shmem_object *shmem);
> +int drm_gem_shmem_swap_in(struct drm_gem_shmem_object *shmem);
> +
> +int drm_gem_shmem_evict(struct drm_gem_shmem_object *shmem);
> +int drm_gem_shmem_purge(struct drm_gem_shmem_object *shmem);
>
> struct sg_table *drm_gem_shmem_get_sg_table(struct drm_gem_shmem_object
> *shmem);
> struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
> *shmem);
> @@ -260,6 +311,32 @@ static inline int drm_gem_shmem_object_mmap(struct
> drm_gem_object *obj, struct v
> return drm_gem_shmem_mmap(shmem, vma);
> }
>
> +/**
> + * struct drm_gem_shmem_shrinker - Generic memory shrinker for shmem GEMs
> + */
> +struct drm_gem_shmem_shrinker {
> + /** @base: Shrinker for purging shmem GEM objects */
> + struct shrinker base;
> +
> + /** @lock: Protects @lru_* */
> + struct mutex lock;
> +
> + /** @lru_pinned: List of pinned shmem GEM objects */
> + struct list_head lru_pinned;
> +
> + /** @lru_evictable: List of shmem GEM objects to be evicted */
> + struct list_head lru_evictable;
> +
> + /** @lru_evicted: List of evicted shmem GEM objects */
> + struct list_head lru_evicted;
> +
> + /** @dev: DRM device that uses this shrinker */
> + struct drm_device *dev;
> +};
> +
> +int drm_gem_shmem_shrinker_register(struct drm_device *dev);
> +void drm_gem_shmem_shrinker_unregister(struct drm_device *dev);
> +
> /*
> * Driver ops
> */
> --
> 2.35.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Sun, 5 Jun 2022 at 20:32, Rob Clark wrote:
>
> On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
> >
> > On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> > wrote:
> > >
> > > Introduce a common DRM SHMEM shrinker framework that allows to reduce
> > > code duplication among DRM drivers by replacing theirs custom shrinker
> > > implementations with the generic shrinker.
> > >
> > > In order to start using DRM SHMEM shrinker drivers should:
> > >
> > > 1. Implement new evict() shmem object callback.
> > > 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> > > 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
> > >activate shrinking of shmem GEMs.
> > >
> > > This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> > > Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
> > >
> > > Signed-off-by: Daniel Almeida
> > > Signed-off-by: Dmitry Osipenko
> >
> > So I guess I get a price for being blind since forever, because this
> > thing existed since at least 2013. I just stumbled over
> > llist_lru.[hc], a purpose built list helper for shrinkers. I think we
> > should try to adopt that so that our gpu shrinkers look more like
> > shrinkers for everything else.
>
> followup from a bit of irc discussion w/ danvet about list_lru:
>
> * It seems to be missing a way to bail out of iteration before
> nr_to_scan is hit.. which is going to be inconvenient if you
> want to allow active bos on the LRU but bail scanning once
> you encounter the first one.
>
> * Not sure if the numa node awareness is super useful for GEM
> bos
>
> First issue is perhaps not too hard to fix. But maybe a better
> idea is a drm_gem_lru helper type thing which is more tailored
> to GEM buffers?
Yeah I guess reusing list_lru isn't that good idea. So just
open-coding it for now, and then drm_gem_bo_lru or so if we need to
share it separately from shmem helpers with other drivers. Maybe will
be needed for ttm or so.
-Daniel
>
> BR,
> -R
>
> > Apologies for this, since I fear this might cause a bit of churn.
> > Hopefully it's all contained to the list manipulation code in shmem
> > helpers, I don't think this should leak any further.
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
> > > .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 9 +-
> > > drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +
> > > include/drm/drm_device.h | 4 +
> > > include/drm/drm_gem_shmem_helper.h| 87 ++-
> > > 5 files changed, 594 insertions(+), 49 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > index 555fe212bd98..4cd0b5913492 100644
> > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > @@ -126,6 +126,42 @@ struct drm_gem_shmem_object
> > > *drm_gem_shmem_create(struct drm_device *dev, size_t
> > > }
> > > EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
> > >
> > > +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object
> > > *shmem)
> > > +{
> > > + return (shmem->madv >= 0) && shmem->evict &&
> > > + shmem->eviction_enabled && shmem->pages_use_count &&
> > > + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> > > + !shmem->base.import_attach && shmem->sgt &&
> > > !shmem->evicted;
> > > +}
> > > +
> > > +static void
> > > +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> > > +{
> > > + struct drm_gem_object *obj = &shmem->base;
> > > + struct drm_gem_shmem_shrinker *gem_shrinker =
> > > obj->dev->shmem_shrinker;
> > > +
> > > + dma_resv_assert_held(shmem->base.resv);
> > > +
> > > + if (!gem_shrinker || obj->import_attach)
> > > + return;
> > > +
> > > + mutex_lock(&gem_shrinker->lock);
> > > +
> > > + if (drm_gem_shmem_is_evictable(shmem) ||
> > > + drm_gem_shmem_is_purgeable(shmem))
> > > + list_move_tail(&shmem->madv
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Sun, Jun 19, 2022 at 10:53:03AM -0700, Rob Clark wrote:
> On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
> wrote:
> > + mutex_unlock(&gem_shrinker->lock);
>
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing. Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.
Yeah agreed, seems like I was wrong here :-) Atomic counter or something
would also be in link the the lru_list stuff.
It would be to record this in the kerneldoc for the shrinker structure
though, to make sure this is all understood.
> > + /* prevent racing with the dma-buf importing/exporting */
> > + if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> > + *lock_contention |= true;
> > + goto resv_unlock;
> > + }
>
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported). So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.
Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable memory
way too often. We need to engineer this out somehow.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
