| Message ID | 20220519095508.115203-5-christian.koenig@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/11] drm/radeon: switch over to ttm_bo_init_reserved | expand |
>-----Original Message----- >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of >Christian König >Sent: Thursday, May 19, 2022 5:55 AM >To: intel-gfx@lists.freedesktop.org >Cc: matthew.william.auld@gmail.com; Christian König ><christian.koenig@amd.com>; dri-devel@lists.freedesktop.org >Subject: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX > >It's the only driver using this. > >Signed-off-by: Christian König <christian.koenig@amd.com> >--- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >index 85a66014c2b6..c4f376d5e1d0 100644 >--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >@@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, > return -ENOMEM; > } > >+ if (!bo_free) >+ bo_free = vmw_bo_default_destroy; >+ vmw_bo_init has a WARN_ON if this is NULL. Also, all of the callers use vmw_bo_bo_free() or vmw_gem_destroy(). Both of those unmap, release and then free the object. It doesn't look like vmw_bo_default_destroy does this work. Is this the right "default" path? Or should the WARN_ON be used to check for this? M > ret = vmw_bo_init(vmw, *p_bo, size, > placement, interruptible, pin, > bo_free); >-- >2.25.1
Am 19.05.22 um 15:36 schrieb Ruhl, Michael J: >> -----Original Message----- >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of >> Christian König >> Sent: Thursday, May 19, 2022 5:55 AM >> To: intel-gfx@lists.freedesktop.org >> Cc: matthew.william.auld@gmail.com; Christian König >> <christian.koenig@amd.com>; dri-devel@lists.freedesktop.org >> Subject: [PATCH 04/11] drm/ttm: move default BO destructor into VMWGFX >> >> It's the only driver using this. >> >> Signed-off-by: Christian König <christian.koenig@amd.com> >> --- >> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >> index 85a66014c2b6..c4f376d5e1d0 100644 >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c >> @@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, >> return -ENOMEM; >> } >> >> + if (!bo_free) >> + bo_free = vmw_bo_default_destroy; >> + > vmw_bo_init has a WARN_ON if this is NULL. > > Also, all of the callers use vmw_bo_bo_free() or vmw_gem_destroy(). > > Both of those unmap, release and then free the object. > > It doesn't look like vmw_bo_default_destroy does this work. > > Is this the right "default" path? Or should the WARN_ON be used to check > for this? This patch here was just a rebase fallout I've overlooked. Zak already reviewed it and I pushed a modified version of it upstream (that's where the WARN_ON comes from). Thanks, Christian. > > M > >> ret = vmw_bo_init(vmw, *p_bo, size, >> placement, interruptible, pin, >> bo_free); >> -- >> 2.25.1
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index 85a66014c2b6..c4f376d5e1d0 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -462,6 +462,9 @@ int vmw_bo_create(struct vmw_private *vmw, return -ENOMEM; } + if (!bo_free) + bo_free = vmw_bo_default_destroy; + ret = vmw_bo_init(vmw, *p_bo, size, placement, interruptible, pin, bo_free);
It's the only driver using this. Signed-off-by: Christian König <christian.koenig@amd.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++ 1 file changed, 3 insertions(+)