All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 9/9] drm/shmem-helpers: Simplify dma-buf importing
Date: Thu, 14 May 2020 17:26:45 +0200	[thread overview]
Message-ID: <a41fc6fc-05d9-dadd-07f4-1f34550da07b@suse.de> (raw)
In-Reply-To: <20200514125528.GA206103@phenom.ffwll.local>


[-- Attachment #1.1.1: Type: text/plain, Size: 7097 bytes --]

Hi

Am 14.05.20 um 14:55 schrieb Daniel Vetter:
> On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> - Ditch the ->pages array
>>> - Make it a private gem bo, which means no shmem object, which means
>>>   fireworks if anyone calls drm_gem_object_get_pages. But we've just
>>>   made sure that's all covered.
>>>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Noralf Trønnes <noralf@tronnes.org>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_gem_shmem_helper.c | 59 ++++++++++----------------
>>>  1 file changed, 23 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> index f7011338813e..8c7d4f422b7b 100644
>>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> @@ -35,22 +35,12 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
>>>  	.mmap = drm_gem_shmem_mmap,
>>>  };
>>>  
>>> -/**
>>> - * drm_gem_shmem_create - Allocate an object with the given size
>>> - * @dev: DRM device
>>> - * @size: Size of the object to allocate
>>> - *
>>> - * This function creates a shmem GEM object.
>>> - *
>>> - * Returns:
>>> - * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
>>> - * error code on failure.
>>> - */
>>> -struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t size)
>>> +static struct drm_gem_shmem_object *
>>> +__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private)
>>>  {
>>>  	struct drm_gem_shmem_object *shmem;
>>>  	struct drm_gem_object *obj;
>>> -	int ret;
>>> +	int ret = 0;
>>>  
>>>  	size = PAGE_ALIGN(size);
>>>  
>>> @@ -64,7 +54,10 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t
>>>  	if (!obj->funcs)
>>>  		obj->funcs = &drm_gem_shmem_funcs;
>>>  
>>> -	ret = drm_gem_object_init(dev, obj, size);
>>> +	if (private)
>>> +		drm_gem_private_object_init(dev, obj, size);
>>> +	else
>>> +		ret = drm_gem_object_init(dev, obj, size);
>>>  	if (ret)
>>>  		goto err_free;
>>>  
>>> @@ -96,6 +89,21 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t
>>>  
>>>  	return ERR_PTR(ret);
>>>  }
>>> +/**
>>> + * drm_gem_shmem_create - Allocate an object with the given size
>>> + * @dev: DRM device
>>> + * @size: Size of the object to allocate
>>> + *
>>> + * This function creates a shmem GEM object.
>>> + *
>>> + * Returns:
>>> + * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
>>> + * error code on failure.
>>> + */
>>> +struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t size)
>>> +{
>>> +	return __drm_gem_shmem_create(dev, size, false);
>>> +}
>>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>>>  
>>>  /**
>>> @@ -115,7 +123,6 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
>>>  	if (obj->import_attach) {
>>>  		shmem->pages_use_count--;
>>>  		drm_prime_gem_destroy(obj, shmem->sgt);
>>> -		kvfree(shmem->pages);
>>>  	} else {
>>>  		if (shmem->sgt) {
>>>  			dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
>>> @@ -371,7 +378,7 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
>>>  	struct drm_gem_shmem_object *shmem;
>>>  	int ret;
>>>  
>>> -	shmem = drm_gem_shmem_create(dev, size);
>>> +	shmem = __drm_gem_shmem_create(dev, size, true);
>>>  	if (IS_ERR(shmem))
>>>  		return shmem;
>>>  
>>> @@ -695,36 +702,16 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
>>>  				    struct sg_table *sgt)
>>>  {
>>>  	size_t size = PAGE_ALIGN(attach->dmabuf->size);
>>> -	size_t npages = size >> PAGE_SHIFT;
>>>  	struct drm_gem_shmem_object *shmem;
>>> -	int ret;
>>>  
>>>  	shmem = drm_gem_shmem_create(dev, size);
>>>  	if (IS_ERR(shmem))
>>>  		return ERR_CAST(shmem);
>>>  
>>> -	shmem->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
>>> -	if (!shmem->pages) {
>>> -		ret = -ENOMEM;
>>> -		goto err_free_gem;
>>> -	}
>>> -
>>> -	ret = drm_prime_sg_to_page_addr_arrays(sgt, shmem->pages, NULL, npages);
>>> -	if (ret < 0)
>>> -		goto err_free_array;
>>> -
>>>  	shmem->sgt = sgt;
>>> -	shmem->pages_use_count = 1; /* Permanently pinned from our point of view */
>>
>> This counter protected drm_gem_shmem_get_pages() from being executed on
>> imported buffers. I guess that previous patches sorted out all the
>> instances where this could occur. If so, the current patch looks
>> correct. I'm not sure, if the overall code is really better than what we
>> have ATM, but anyway
> 
> The goal was to clearly sort these cases out, iirc we had callers of
> get_pages doing the wrong thing, but I tried to review them all. Some got
> removed while this series was hanging around in my tree somewhere.
> 
> What I wanted to do in the end is replace all mutex_lock with
> dma_resv_lock, which now should be doable. Except I need to audit all the
> drivers, and some want _locked variant since they are already holding the
> lock. That's roughly the point where I gave up on this eandeavour, at
> least for now.
> 
> But if we'd get there then all the various helpers we have (cma, shmem,
> vram) would more or less properly use dma_resv_lock as their protectiong
> concept. That's kinda neat since with the dynamic dma-buf stuff
> dma_resv_lock really becomes _the_ buffer lock for drivers, so some
> motivation to move towards that.
> 
> Anyway if you don't feel like this is all that useful without the
> dma_resv_lock work on top, I guess I can merge up to the doc patch and
> leave the others out. Not sure myself, thoughts?

Don't get me wrong, it's useful. The dma-buf support is just always a
bit special and bolted-on in all memory managers.

Please go ahead and merge it if you like. The clean separation of
dma-buf calls is better than what I did in my shmem patches. I'll rebase
my stuff on top of whatever you end up merging.

Best regards
Thomas

> 
> Thanks for taking a look.
> -Daniel
> 
>>
>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>>>  
>>>  	DRM_DEBUG_PRIME("size = %zu\n", size);
>>>  
>>>  	return &shmem->base;
>>> -
>>> -err_free_array:
>>> -	kvfree(shmem->pages);
>>> -err_free_gem:
>>> -	drm_gem_object_put_unlocked(&shmem->base);
>>> -
>>> -	return ERR_PTR(ret);
>>>  }
>>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>>>
>>
>> -- 
>> 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
>>
> 
> 
> 
> 

-- 
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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
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: Thomas Zimmermann <tzimmermann@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 9/9] drm/shmem-helpers: Simplify dma-buf importing
Date: Thu, 14 May 2020 17:26:45 +0200	[thread overview]
Message-ID: <a41fc6fc-05d9-dadd-07f4-1f34550da07b@suse.de> (raw)
In-Reply-To: <20200514125528.GA206103@phenom.ffwll.local>


[-- Attachment #1.1.1: Type: text/plain, Size: 7097 bytes --]

Hi

Am 14.05.20 um 14:55 schrieb Daniel Vetter:
> On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> - Ditch the ->pages array
>>> - Make it a private gem bo, which means no shmem object, which means
>>>   fireworks if anyone calls drm_gem_object_get_pages. But we've just
>>>   made sure that's all covered.
>>>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Noralf Trønnes <noralf@tronnes.org>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_gem_shmem_helper.c | 59 ++++++++++----------------
>>>  1 file changed, 23 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> index f7011338813e..8c7d4f422b7b 100644
>>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>> @@ -35,22 +35,12 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
>>>  	.mmap = drm_gem_shmem_mmap,
>>>  };
>>>  
>>> -/**
>>> - * drm_gem_shmem_create - Allocate an object with the given size
>>> - * @dev: DRM device
>>> - * @size: Size of the object to allocate
>>> - *
>>> - * This function creates a shmem GEM object.
>>> - *
>>> - * Returns:
>>> - * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
>>> - * error code on failure.
>>> - */
>>> -struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t size)
>>> +static struct drm_gem_shmem_object *
>>> +__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private)
>>>  {
>>>  	struct drm_gem_shmem_object *shmem;
>>>  	struct drm_gem_object *obj;
>>> -	int ret;
>>> +	int ret = 0;
>>>  
>>>  	size = PAGE_ALIGN(size);
>>>  
>>> @@ -64,7 +54,10 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t
>>>  	if (!obj->funcs)
>>>  		obj->funcs = &drm_gem_shmem_funcs;
>>>  
>>> -	ret = drm_gem_object_init(dev, obj, size);
>>> +	if (private)
>>> +		drm_gem_private_object_init(dev, obj, size);
>>> +	else
>>> +		ret = drm_gem_object_init(dev, obj, size);
>>>  	if (ret)
>>>  		goto err_free;
>>>  
>>> @@ -96,6 +89,21 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t
>>>  
>>>  	return ERR_PTR(ret);
>>>  }
>>> +/**
>>> + * drm_gem_shmem_create - Allocate an object with the given size
>>> + * @dev: DRM device
>>> + * @size: Size of the object to allocate
>>> + *
>>> + * This function creates a shmem GEM object.
>>> + *
>>> + * Returns:
>>> + * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
>>> + * error code on failure.
>>> + */
>>> +struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t size)
>>> +{
>>> +	return __drm_gem_shmem_create(dev, size, false);
>>> +}
>>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>>>  
>>>  /**
>>> @@ -115,7 +123,6 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
>>>  	if (obj->import_attach) {
>>>  		shmem->pages_use_count--;
>>>  		drm_prime_gem_destroy(obj, shmem->sgt);
>>> -		kvfree(shmem->pages);
>>>  	} else {
>>>  		if (shmem->sgt) {
>>>  			dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
>>> @@ -371,7 +378,7 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
>>>  	struct drm_gem_shmem_object *shmem;
>>>  	int ret;
>>>  
>>> -	shmem = drm_gem_shmem_create(dev, size);
>>> +	shmem = __drm_gem_shmem_create(dev, size, true);
>>>  	if (IS_ERR(shmem))
>>>  		return shmem;
>>>  
>>> @@ -695,36 +702,16 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
>>>  				    struct sg_table *sgt)
>>>  {
>>>  	size_t size = PAGE_ALIGN(attach->dmabuf->size);
>>> -	size_t npages = size >> PAGE_SHIFT;
>>>  	struct drm_gem_shmem_object *shmem;
>>> -	int ret;
>>>  
>>>  	shmem = drm_gem_shmem_create(dev, size);
>>>  	if (IS_ERR(shmem))
>>>  		return ERR_CAST(shmem);
>>>  
>>> -	shmem->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
>>> -	if (!shmem->pages) {
>>> -		ret = -ENOMEM;
>>> -		goto err_free_gem;
>>> -	}
>>> -
>>> -	ret = drm_prime_sg_to_page_addr_arrays(sgt, shmem->pages, NULL, npages);
>>> -	if (ret < 0)
>>> -		goto err_free_array;
>>> -
>>>  	shmem->sgt = sgt;
>>> -	shmem->pages_use_count = 1; /* Permanently pinned from our point of view */
>>
>> This counter protected drm_gem_shmem_get_pages() from being executed on
>> imported buffers. I guess that previous patches sorted out all the
>> instances where this could occur. If so, the current patch looks
>> correct. I'm not sure, if the overall code is really better than what we
>> have ATM, but anyway
> 
> The goal was to clearly sort these cases out, iirc we had callers of
> get_pages doing the wrong thing, but I tried to review them all. Some got
> removed while this series was hanging around in my tree somewhere.
> 
> What I wanted to do in the end is replace all mutex_lock with
> dma_resv_lock, which now should be doable. Except I need to audit all the
> drivers, and some want _locked variant since they are already holding the
> lock. That's roughly the point where I gave up on this eandeavour, at
> least for now.
> 
> But if we'd get there then all the various helpers we have (cma, shmem,
> vram) would more or less properly use dma_resv_lock as their protectiong
> concept. That's kinda neat since with the dynamic dma-buf stuff
> dma_resv_lock really becomes _the_ buffer lock for drivers, so some
> motivation to move towards that.
> 
> Anyway if you don't feel like this is all that useful without the
> dma_resv_lock work on top, I guess I can merge up to the doc patch and
> leave the others out. Not sure myself, thoughts?

Don't get me wrong, it's useful. The dma-buf support is just always a
bit special and bolted-on in all memory managers.

Please go ahead and merge it if you like. The clean separation of
dma-buf calls is better than what I did in my shmem patches. I'll rebase
my stuff on top of whatever you end up merging.

Best regards
Thomas

> 
> Thanks for taking a look.
> -Daniel
> 
>>
>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>>>  
>>>  	DRM_DEBUG_PRIME("size = %zu\n", size);
>>>  
>>>  	return &shmem->base;
>>> -
>>> -err_free_array:
>>> -	kvfree(shmem->pages);
>>> -err_free_gem:
>>> -	drm_gem_object_put_unlocked(&shmem->base);
>>> -
>>> -	return ERR_PTR(ret);
>>>  }
>>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>>>
>>
>> -- 
>> 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
>>
> 
> 
> 
> 

-- 
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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-05-14 15:26 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  9:35 [PATCH 0/9] shmem helper untangling Daniel Vetter
2020-05-11  9:35 ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 1/9] drm/msm: Don't call dma_buf_vunmap without _vmap Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35   ` Daniel Vetter
2020-05-11 15:24   ` Rob Clark
2020-05-11 15:24     ` [Intel-gfx] " Rob Clark
2020-05-11 15:24     ` Rob Clark
2020-05-11 15:28     ` Daniel Vetter
2020-05-11 15:28       ` [Intel-gfx] " Daniel Vetter
2020-05-11 15:28       ` Daniel Vetter
2020-05-11 20:36       ` Rob Clark
2020-05-11 20:36         ` [Intel-gfx] " Rob Clark
2020-05-11 20:36         ` Rob Clark
2020-05-14 20:11   ` [PATCH] " Daniel Vetter
2020-05-14 20:11     ` Daniel Vetter
2020-05-28  8:29     ` Daniel Vetter
2020-05-28  8:29       ` Daniel Vetter
2020-05-31 16:02     ` Rob Clark
2020-05-31 16:02       ` Rob Clark
2020-06-03 12:46       ` Daniel Vetter
2020-06-03 12:46         ` Daniel Vetter
2020-05-11  9:35 ` [PATCH 2/9] drm/gem: WARN if drm_gem_get_pages is called on a private obj Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:45   ` Thomas Zimmermann
2020-05-14  7:45     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 3/9] drm/doc: Some polish for shmem helpers Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11 11:12   ` Thomas Zimmermann
2020-05-11 11:12     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 20:05     ` Daniel Vetter
2020-05-14 20:05       ` [Intel-gfx] " Daniel Vetter
2020-05-15  6:26       ` Thomas Zimmermann
2020-05-15  6:26         ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 4/9] drm/virtio: Call the right " Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35   ` Daniel Vetter
2020-05-14  7:46   ` Thomas Zimmermann
2020-05-14  7:46     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14  7:46     ` Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 5/9] drm/udl: Don't call get/put_pages on imported dma-buf Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-11 11:23   ` Thomas Zimmermann
2020-05-11 11:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11 11:37     ` Daniel Vetter
2020-05-11 11:37       ` [Intel-gfx] " Daniel Vetter
2020-05-11 12:04       ` Thomas Zimmermann
2020-05-11 12:04         ` [Intel-gfx] " Thomas Zimmermann
2020-05-14  7:25   ` Thomas Zimmermann
2020-05-14  7:25     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:47     ` Daniel Vetter
2020-05-14 12:47       ` [Intel-gfx] " Daniel Vetter
2020-06-03 12:57       ` Daniel Vetter
2020-06-03 12:57         ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 6/9] drm/shmem-helpers: Don't call get/put_pages on imported dma-buf in vmap Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:16   ` Thomas Zimmermann
2020-05-14  7:16     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:49     ` Daniel Vetter
2020-05-14 12:49       ` [Intel-gfx] " Daniel Vetter
2020-05-14 20:22     ` [PATCH] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:23   ` Thomas Zimmermann
2020-05-14  7:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:47     ` Daniel Vetter
2020-05-14 12:47       ` [Intel-gfx] " Daniel Vetter
2020-05-27 18:32   ` Thomas Zimmermann
2020-05-27 18:32     ` [Intel-gfx] " Thomas Zimmermann
2020-05-27 19:34     ` Daniel Vetter
2020-05-27 19:34       ` [Intel-gfx] " Daniel Vetter
2020-05-28 12:53       ` Thomas Zimmermann
2020-05-28 12:53         ` [Intel-gfx] " Thomas Zimmermann
2020-05-11  9:35 ` [PATCH 8/9] drm/shmem-helpers: Ensure get_pages is not called on " Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:30   ` Thomas Zimmermann
2020-05-14  7:30     ` [Intel-gfx] " Thomas Zimmermann
2020-06-03 13:12     ` Daniel Vetter
2020-06-03 13:12       ` [Intel-gfx] " Daniel Vetter
2020-06-08 14:40       ` Thomas Zimmermann
2020-06-08 14:40         ` [Intel-gfx] " Thomas Zimmermann
2020-06-08 15:04         ` Daniel Vetter
2020-06-08 15:04           ` [Intel-gfx] " Daniel Vetter
2020-05-11  9:35 ` [PATCH 9/9] drm/shmem-helpers: Simplify dma-buf importing Daniel Vetter
2020-05-11  9:35   ` [Intel-gfx] " Daniel Vetter
2020-05-14  7:44   ` Thomas Zimmermann
2020-05-14  7:44     ` [Intel-gfx] " Thomas Zimmermann
2020-05-14 12:55     ` Daniel Vetter
2020-05-14 12:55       ` [Intel-gfx] " Daniel Vetter
2020-05-14 15:26       ` Thomas Zimmermann [this message]
2020-05-14 15:26         ` Thomas Zimmermann
2020-05-20 18:02   ` [PATCH] " Daniel Vetter
2020-05-29 13:34     ` Boris Brezillon
2020-05-29 13:35       ` Boris Brezillon
2020-05-29 13:49     ` Boris Brezillon
2020-05-29 14:05     ` Daniel Vetter
2020-05-29 14:36       ` Boris Brezillon
2020-06-15  8:23   ` [PATCH 9/9] " Thomas Zimmermann
2020-06-15  8:23     ` [Intel-gfx] " Thomas Zimmermann
2020-05-11 11:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for shmem helper untangling Patchwork
2020-05-11 11:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-05-11 14:30 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-05-29 13:52 ` [PATCH 0/9] " Boris Brezillon
2020-05-29 13:52   ` [Intel-gfx] " Boris Brezillon

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=a41fc6fc-05d9-dadd-07f4-1f34550da07b@suse.de \
    --to=tzimmermann@suse.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    /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.