All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: shashank.sharma@amd.com, airlied@linux.ie,
	nouveau@lists.freedesktop.org, Felix.Kuehling@amd.com,
	sroland@vmware.com, dri-devel@lists.freedesktop.org,
	nirmoy.das@amd.com, linux-graphics-maintainer@vmware.com,
	amd-gfx@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	alexander.deucher@amd.com, ray.huang@amd.com,
	emil.velikov@collabora.com, sam@ravnborg.org,
	christian.koenig@amd.com, bskeggs@redhat.com
Subject: Re: [Nouveau] [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
Date: Thu, 8 Apr 2021 13:42:31 +0200	[thread overview]
Message-ID: <YG7sJ9xf3he4OZui@phenom.ffwll.local> (raw)
In-Reply-To: <78bd7249-8bea-e61d-ab7f-7067d31aa854@suse.de>

On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 08.04.21 um 13:19 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> > > radeon and nouveau. This allows for using common DRM helpers for
> > > the mmap-related callbacks in struct file_operations and struct
> > > drm_driver. The drivers have their own vm_ops, which are now set
> > > automatically by the DRM core functions. The code in each driver's
> > > verify_access becomes part of the driver's new mmap implementation.
> > 
> > Is there anything left in there which isn't already handled by the gem
> > checks? Iirc there was some custom limit for ttm drivers once to allow
> > co-existing with ums drivers, but that's never really been a thing since
> > forever ...
> 
> Vmwgfx does its own thing. radeon and amdgpu have some checks (userptr). But
> it's all very small. The general tests will be in the GEM helpers.

Ah userptr makes tons of sense. I think that should be rejected when
creating the mmap offset, and then a WARN_ON to bail out.

But that means we'd need to lift the basic userptr scaffolding to
drm_gem_object. Which would make tons of sense imo (all the various
semi-broken copypasta versions aren't great), but that's definitely for
another time.
-Daniel

> 
> Best regards
> Thomas
> 
> > -Daniel
> > 
> > > 
> > > With the GEM drivers converted, vmwgfx is the only user of
> > > ttm_bo_mmap() and related infrastructure. So move everything into
> > > vmwgfx and delete the rsp code from TTM.
> > > 
> > > This touches several drivers. Preferably everything would be merged
> > > at once via drm-misc-next.
> > > 
> > > Thomas Zimmermann (8):
> > >    drm/ttm: Don't override vm_ops callbacks, if set
> > >    drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
> > >    drm/amdgpu: Implement mmap as GEM object function
> > >    drm/radeon: Implement mmap as GEM object function
> > >    drm/nouveau: Implement mmap as GEM object function
> > >    drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
> > >    drm/vmwgfx: Inline vmw_verify_access()
> > >    drm/ttm: Remove ttm_bo_mmap() and friends
> > > 
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |  4 +-
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c     | 64 +++++++++++++++++++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  | 19 ------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c     | 71 ---------------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h     |  1 -
> > >   drivers/gpu/drm/nouveau/nouveau_bo.c        | 10 ---
> > >   drivers/gpu/drm/nouveau/nouveau_drm.c       |  3 +-
> > >   drivers/gpu/drm/nouveau/nouveau_gem.c       | 36 +++++++++++
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.c       | 49 --------------
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.h       |  1 -
> > >   drivers/gpu/drm/radeon/radeon_drv.c         |  3 +-
> > >   drivers/gpu/drm/radeon/radeon_gem.c         | 52 +++++++++++++++
> > >   drivers/gpu/drm/radeon/radeon_ttm.c         | 65 -------------------
> > >   drivers/gpu/drm/radeon/radeon_ttm.h         |  1 -
> > >   drivers/gpu/drm/ttm/ttm_bo_vm.c             | 60 ++---------------
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c  |  9 ---
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c    | 51 ++++++++++++++-
> > >   include/drm/ttm/ttm_bo_api.h                | 13 ----
> > >   include/drm/ttm/ttm_device.h                | 15 -----
> > >   22 files changed, 212 insertions(+), 365 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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: shashank.sharma@amd.com, airlied@linux.ie,
	nouveau@lists.freedesktop.org, Felix.Kuehling@amd.com,
	sroland@vmware.com, dri-devel@lists.freedesktop.org,
	nirmoy.das@amd.com, linux-graphics-maintainer@vmware.com,
	amd-gfx@lists.freedesktop.org, alexander.deucher@amd.com,
	ray.huang@amd.com, emil.velikov@collabora.com, sam@ravnborg.org,
	christian.koenig@amd.com, bskeggs@redhat.com
Subject: Re: [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
Date: Thu, 8 Apr 2021 13:42:31 +0200	[thread overview]
Message-ID: <YG7sJ9xf3he4OZui@phenom.ffwll.local> (raw)
In-Reply-To: <78bd7249-8bea-e61d-ab7f-7067d31aa854@suse.de>

On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 08.04.21 um 13:19 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> > > radeon and nouveau. This allows for using common DRM helpers for
> > > the mmap-related callbacks in struct file_operations and struct
> > > drm_driver. The drivers have their own vm_ops, which are now set
> > > automatically by the DRM core functions. The code in each driver's
> > > verify_access becomes part of the driver's new mmap implementation.
> > 
> > Is there anything left in there which isn't already handled by the gem
> > checks? Iirc there was some custom limit for ttm drivers once to allow
> > co-existing with ums drivers, but that's never really been a thing since
> > forever ...
> 
> Vmwgfx does its own thing. radeon and amdgpu have some checks (userptr). But
> it's all very small. The general tests will be in the GEM helpers.

Ah userptr makes tons of sense. I think that should be rejected when
creating the mmap offset, and then a WARN_ON to bail out.

But that means we'd need to lift the basic userptr scaffolding to
drm_gem_object. Which would make tons of sense imo (all the various
semi-broken copypasta versions aren't great), but that's definitely for
another time.
-Daniel

> 
> Best regards
> Thomas
> 
> > -Daniel
> > 
> > > 
> > > With the GEM drivers converted, vmwgfx is the only user of
> > > ttm_bo_mmap() and related infrastructure. So move everything into
> > > vmwgfx and delete the rsp code from TTM.
> > > 
> > > This touches several drivers. Preferably everything would be merged
> > > at once via drm-misc-next.
> > > 
> > > Thomas Zimmermann (8):
> > >    drm/ttm: Don't override vm_ops callbacks, if set
> > >    drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
> > >    drm/amdgpu: Implement mmap as GEM object function
> > >    drm/radeon: Implement mmap as GEM object function
> > >    drm/nouveau: Implement mmap as GEM object function
> > >    drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
> > >    drm/vmwgfx: Inline vmw_verify_access()
> > >    drm/ttm: Remove ttm_bo_mmap() and friends
> > > 
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |  4 +-
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c     | 64 +++++++++++++++++++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  | 19 ------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c     | 71 ---------------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h     |  1 -
> > >   drivers/gpu/drm/nouveau/nouveau_bo.c        | 10 ---
> > >   drivers/gpu/drm/nouveau/nouveau_drm.c       |  3 +-
> > >   drivers/gpu/drm/nouveau/nouveau_gem.c       | 36 +++++++++++
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.c       | 49 --------------
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.h       |  1 -
> > >   drivers/gpu/drm/radeon/radeon_drv.c         |  3 +-
> > >   drivers/gpu/drm/radeon/radeon_gem.c         | 52 +++++++++++++++
> > >   drivers/gpu/drm/radeon/radeon_ttm.c         | 65 -------------------
> > >   drivers/gpu/drm/radeon/radeon_ttm.h         |  1 -
> > >   drivers/gpu/drm/ttm/ttm_bo_vm.c             | 60 ++---------------
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c  |  9 ---
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c    | 51 ++++++++++++++-
> > >   include/drm/ttm/ttm_bo_api.h                | 13 ----
> > >   include/drm/ttm/ttm_device.h                | 15 -----
> > >   22 files changed, 212 insertions(+), 365 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: shashank.sharma@amd.com, airlied@linux.ie,
	nouveau@lists.freedesktop.org, Felix.Kuehling@amd.com,
	sroland@vmware.com, dri-devel@lists.freedesktop.org,
	nirmoy.das@amd.com, linux-graphics-maintainer@vmware.com,
	amd-gfx@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	alexander.deucher@amd.com, ray.huang@amd.com,
	emil.velikov@collabora.com, sam@ravnborg.org,
	christian.koenig@amd.com, bskeggs@redhat.com
Subject: Re: [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
Date: Thu, 8 Apr 2021 13:42:31 +0200	[thread overview]
Message-ID: <YG7sJ9xf3he4OZui@phenom.ffwll.local> (raw)
In-Reply-To: <78bd7249-8bea-e61d-ab7f-7067d31aa854@suse.de>

On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 08.04.21 um 13:19 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> > > radeon and nouveau. This allows for using common DRM helpers for
> > > the mmap-related callbacks in struct file_operations and struct
> > > drm_driver. The drivers have their own vm_ops, which are now set
> > > automatically by the DRM core functions. The code in each driver's
> > > verify_access becomes part of the driver's new mmap implementation.
> > 
> > Is there anything left in there which isn't already handled by the gem
> > checks? Iirc there was some custom limit for ttm drivers once to allow
> > co-existing with ums drivers, but that's never really been a thing since
> > forever ...
> 
> Vmwgfx does its own thing. radeon and amdgpu have some checks (userptr). But
> it's all very small. The general tests will be in the GEM helpers.

Ah userptr makes tons of sense. I think that should be rejected when
creating the mmap offset, and then a WARN_ON to bail out.

But that means we'd need to lift the basic userptr scaffolding to
drm_gem_object. Which would make tons of sense imo (all the various
semi-broken copypasta versions aren't great), but that's definitely for
another time.
-Daniel

> 
> Best regards
> Thomas
> 
> > -Daniel
> > 
> > > 
> > > With the GEM drivers converted, vmwgfx is the only user of
> > > ttm_bo_mmap() and related infrastructure. So move everything into
> > > vmwgfx and delete the rsp code from TTM.
> > > 
> > > This touches several drivers. Preferably everything would be merged
> > > at once via drm-misc-next.
> > > 
> > > Thomas Zimmermann (8):
> > >    drm/ttm: Don't override vm_ops callbacks, if set
> > >    drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
> > >    drm/amdgpu: Implement mmap as GEM object function
> > >    drm/radeon: Implement mmap as GEM object function
> > >    drm/nouveau: Implement mmap as GEM object function
> > >    drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
> > >    drm/vmwgfx: Inline vmw_verify_access()
> > >    drm/ttm: Remove ttm_bo_mmap() and friends
> > > 
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |  4 +-
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c     | 64 +++++++++++++++++++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  | 19 ------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 -
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c     | 71 ---------------------
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h     |  1 -
> > >   drivers/gpu/drm/nouveau/nouveau_bo.c        | 10 ---
> > >   drivers/gpu/drm/nouveau/nouveau_drm.c       |  3 +-
> > >   drivers/gpu/drm/nouveau/nouveau_gem.c       | 36 +++++++++++
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.c       | 49 --------------
> > >   drivers/gpu/drm/nouveau/nouveau_ttm.h       |  1 -
> > >   drivers/gpu/drm/radeon/radeon_drv.c         |  3 +-
> > >   drivers/gpu/drm/radeon/radeon_gem.c         | 52 +++++++++++++++
> > >   drivers/gpu/drm/radeon/radeon_ttm.c         | 65 -------------------
> > >   drivers/gpu/drm/radeon/radeon_ttm.h         |  1 -
> > >   drivers/gpu/drm/ttm/ttm_bo_vm.c             | 60 ++---------------
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c  |  9 ---
> > >   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c    | 51 ++++++++++++++-
> > >   include/drm/ttm/ttm_bo_api.h                | 13 ----
> > >   include/drm/ttm/ttm_device.h                | 15 -----
> > >   22 files changed, 212 insertions(+), 365 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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2021-04-08 11:42 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06  9:08 [Nouveau] [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers Thomas Zimmermann
2021-04-06  9:08 ` Thomas Zimmermann
2021-04-06  9:08 ` Thomas Zimmermann
2021-04-06  9:08 ` [Nouveau] [PATCH 1/8] drm/ttm: Don't override vm_ops callbacks, if set Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:08 ` [Nouveau] [PATCH 2/8] drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap() Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:43   ` [Nouveau] " Christian König
2021-04-06  9:43     ` Christian König
2021-04-06  9:43     ` Christian König
2021-04-06 10:21     ` [Nouveau] " Thomas Zimmermann
2021-04-06 10:21       ` Thomas Zimmermann
2021-04-06 10:21       ` Thomas Zimmermann
2021-04-06  9:08 ` [Nouveau] [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:35   ` [Nouveau] " Christian König
2021-04-06  9:35     ` Christian König
2021-04-06  9:35     ` Christian König
2021-04-06 10:38     ` [Nouveau] " Thomas Zimmermann
2021-04-06 10:38       ` Thomas Zimmermann
2021-04-06 10:38       ` Thomas Zimmermann
2021-04-06 10:56       ` [Nouveau] " Christian König
2021-04-06 10:56         ` Christian König
2021-04-06 10:56         ` Christian König
2021-04-06 11:55         ` [Nouveau] " Thomas Zimmermann
2021-04-06 11:55           ` Thomas Zimmermann
2021-04-06 11:55           ` Thomas Zimmermann
2021-04-06 12:42           ` [Nouveau] " Christian König
2021-04-06 12:42             ` Christian König
2021-04-06 12:42             ` Christian König
2021-04-06 12:52             ` [Nouveau] " Thomas Zimmermann
2021-04-06 12:52               ` Thomas Zimmermann
2021-04-06 12:52               ` Thomas Zimmermann
2021-04-06 13:04               ` [Nouveau] " Christian König
2021-04-06 13:04                 ` Christian König
2021-04-06 13:04                 ` Christian König
2021-04-06 15:22                 ` [Nouveau] " Felix Kuehling
2021-04-06 15:22                   ` Felix Kuehling
2021-04-06 15:22                   ` Felix Kuehling
2021-04-06 15:27       ` [Nouveau] " Felix Kuehling
2021-04-06 15:27         ` Felix Kuehling
2021-04-06 15:27         ` Felix Kuehling
2021-04-07 11:25         ` [Nouveau] " Christian König
2021-04-07 11:25           ` Christian König
2021-04-07 11:25           ` Christian König
2021-04-07 19:34           ` [Nouveau] " Felix Kuehling
2021-04-07 19:34             ` Felix Kuehling
2021-04-07 19:34             ` Felix Kuehling
2021-04-07 19:49             ` [Nouveau] " Felix Kuehling
2021-04-07 19:49               ` Felix Kuehling
2021-04-07 19:49               ` Felix Kuehling
2021-04-08  4:45               ` [Nouveau] " Thomas Zimmermann
2021-04-08  4:45                 ` Thomas Zimmermann
2021-04-08  4:45                 ` Thomas Zimmermann
2021-04-14  7:44               ` [Nouveau] " Thomas Zimmermann
2021-04-14  7:44                 ` Thomas Zimmermann
2021-04-14  7:44                 ` Thomas Zimmermann
2021-04-14  8:37                 ` [Nouveau] " Felix Kuehling
2021-04-14  8:37                   ` Felix Kuehling
2021-04-14  8:37                   ` Felix Kuehling
2021-04-06  9:08 ` [Nouveau] [PATCH 4/8] drm/radeon: " Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:08   ` Thomas Zimmermann
2021-04-06  9:38   ` [Nouveau] " Christian König
2021-04-06  9:38     ` Christian König
2021-04-06  9:38     ` Christian König
2021-04-06 14:18   ` [Nouveau] " Alex Deucher
2021-04-06 14:18     ` Alex Deucher
2021-04-06 14:18     ` Alex Deucher
2021-04-06  9:09 ` [Nouveau] [PATCH 5/8] drm/nouveau: " Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:09 ` [Nouveau] [PATCH 6/8] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-07 16:52   ` [Nouveau] " Zack Rusin
2021-04-07 16:52     ` Zack Rusin
2021-04-07 16:52     ` Zack Rusin
2021-04-06  9:09 ` [Nouveau] [PATCH 7/8] drm/vmwgfx: Inline vmw_verify_access() Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-07 16:52   ` [Nouveau] " Zack Rusin
2021-04-07 16:52     ` Zack Rusin
2021-04-07 16:52     ` Zack Rusin
2021-04-06  9:09 ` [Nouveau] [PATCH 8/8] drm/ttm: Remove ttm_bo_mmap() and friends Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:09   ` Thomas Zimmermann
2021-04-06  9:40   ` [Nouveau] " Christian König
2021-04-06  9:40     ` Christian König
2021-04-06  9:40     ` Christian König
2021-04-08 11:19 ` [Nouveau] [PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers Daniel Vetter
2021-04-08 11:19   ` Daniel Vetter
2021-04-08 11:19   ` Daniel Vetter
2021-04-08 11:38   ` [Nouveau] " Thomas Zimmermann
2021-04-08 11:38     ` Thomas Zimmermann
2021-04-08 11:38     ` Thomas Zimmermann
2021-04-08 11:42     ` Daniel Vetter [this message]
2021-04-08 11:42       ` Daniel Vetter
2021-04-08 11:42       ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YG7sJ9xf3he4OZui@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Felix.Kuehling@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.com \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=nirmoy.das@amd.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ray.huang@amd.com \
    --cc=sam@ravnborg.org \
    --cc=shashank.sharma@amd.com \
    --cc=sroland@vmware.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.