All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Scheidegger <sroland@vmware.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	<dri-devel@lists.freedesktop.org>,
	<iommu@lists.linux-foundation.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Airlie <airlied@linux.ie>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Linux-graphics-maintainer] [PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues
Date: Tue, 12 May 2020 02:19:25 +0200	[thread overview]
Message-ID: <8adef36a-1f35-e8df-3b7b-2f994a204be1@vmware.com> (raw)
In-Reply-To: <20200505084614.30424-15-m.szyprowski@samsung.com>

I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger <sroland@vmware.com>

Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the original number of the entries passed to dma_map_sg. The
> sg_table->nents in turn holds the result of the dma_map_sg call as stated
> in include/linux/scatterlist.h. A common mistake was to ignore a result
> of the dma_map_sg function and don't use the sg_table->orig_nents at all.
> 
> To avoid such issues, lets use common dma-mapping wrappers operating
> directly on the struct sg_table objects and adjust references to the
> nents and orig_nents respectively.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> For more information, see '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 ++++-------------
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index bf0bc46..e50ae8b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -362,8 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
>  
> -	dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
> -		DMA_BIDIRECTIONAL);
> +	dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  	vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>  }
>  
> @@ -383,16 +382,8 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  static int vmw_ttm_map_for_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
> -	int ret;
> -
> -	ret = dma_map_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
> -			 DMA_BIDIRECTIONAL);
> -	if (unlikely(ret == 0))
> -		return -ENOMEM;
>  
> -	vmw_tt->sgt.nents = ret;
> -
> -	return 0;
> +	return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  }
>  
>  /**
> @@ -449,10 +440,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
>  		if (unlikely(ret != 0))
>  			goto out_sg_alloc_fail;
>  
> -		if (vsgt->num_pages > vmw_tt->sgt.nents) {
> +		if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
>  			uint64_t over_alloc =
>  				sgl_size * (vsgt->num_pages -
> -					    vmw_tt->sgt.nents);
> +					    vmw_tt->sgt.orig_nents);
>  
>  			ttm_mem_global_free(glob, over_alloc);
>  			vmw_tt->sg_alloc_size -= over_alloc;
> 


WARNING: multiple messages have this Message-ID
From: Roland Scheidegger <sroland@vmware.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	<dri-devel@lists.freedesktop.org>,
	<iommu@lists.linux-foundation.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Airlie <airlied@linux.ie>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Linux-graphics-maintainer] [PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues
Date: Tue, 12 May 2020 02:19:25 +0200	[thread overview]
Message-ID: <8adef36a-1f35-e8df-3b7b-2f994a204be1@vmware.com> (raw)
In-Reply-To: <20200505084614.30424-15-m.szyprowski@samsung.com>

I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger <sroland@vmware.com>

Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the original number of the entries passed to dma_map_sg. The
> sg_table->nents in turn holds the result of the dma_map_sg call as stated
> in include/linux/scatterlist.h. A common mistake was to ignore a result
> of the dma_map_sg function and don't use the sg_table->orig_nents at all.
> 
> To avoid such issues, lets use common dma-mapping wrappers operating
> directly on the struct sg_table objects and adjust references to the
> nents and orig_nents respectively.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> For more information, see '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 ++++-------------
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index bf0bc46..e50ae8b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -362,8 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
>  
> -	dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
> -		DMA_BIDIRECTIONAL);
> +	dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  	vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>  }
>  
> @@ -383,16 +382,8 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  static int vmw_ttm_map_for_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
> -	int ret;
> -
> -	ret = dma_map_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
> -			 DMA_BIDIRECTIONAL);
> -	if (unlikely(ret == 0))
> -		return -ENOMEM;
>  
> -	vmw_tt->sgt.nents = ret;
> -
> -	return 0;
> +	return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  }
>  
>  /**
> @@ -449,10 +440,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
>  		if (unlikely(ret != 0))
>  			goto out_sg_alloc_fail;
>  
> -		if (vsgt->num_pages > vmw_tt->sgt.nents) {
> +		if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
>  			uint64_t over_alloc =
>  				sgl_size * (vsgt->num_pages -
> -					    vmw_tt->sgt.nents);
> +					    vmw_tt->sgt.orig_nents);
>  
>  			ttm_mem_global_free(glob, over_alloc);
>  			vmw_tt->sg_alloc_size -= over_alloc;
> 

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID
From: Roland Scheidegger <sroland@vmware.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	<dri-devel@lists.freedesktop.org>,
	<iommu@lists.linux-foundation.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Airlie <airlied@linux.ie>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Linux-graphics-maintainer] [PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues
Date: Tue, 12 May 2020 02:19:25 +0200	[thread overview]
Message-ID: <8adef36a-1f35-e8df-3b7b-2f994a204be1@vmware.com> (raw)
In-Reply-To: <20200505084614.30424-15-m.szyprowski@samsung.com>

I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger <sroland@vmware.com>

Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the original number of the entries passed to dma_map_sg. The
> sg_table->nents in turn holds the result of the dma_map_sg call as stated
> in include/linux/scatterlist.h. A common mistake was to ignore a result
> of the dma_map_sg function and don't use the sg_table->orig_nents at all.
> 
> To avoid such issues, lets use common dma-mapping wrappers operating
> directly on the struct sg_table objects and adjust references to the
> nents and orig_nents respectively.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> For more information, see '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 ++++-------------
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index bf0bc46..e50ae8b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -362,8 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
>  
> -	dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
> -		DMA_BIDIRECTIONAL);
> +	dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  	vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>  }
>  
> @@ -383,16 +382,8 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  static int vmw_ttm_map_for_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
> -	int ret;
> -
> -	ret = dma_map_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
> -			 DMA_BIDIRECTIONAL);
> -	if (unlikely(ret == 0))
> -		return -ENOMEM;
>  
> -	vmw_tt->sgt.nents = ret;
> -
> -	return 0;
> +	return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  }
>  
>  /**
> @@ -449,10 +440,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
>  		if (unlikely(ret != 0))
>  			goto out_sg_alloc_fail;
>  
> -		if (vsgt->num_pages > vmw_tt->sgt.nents) {
> +		if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
>  			uint64_t over_alloc =
>  				sgl_size * (vsgt->num_pages -
> -					    vmw_tt->sgt.nents);
> +					    vmw_tt->sgt.orig_nents);
>  
>  			ttm_mem_global_free(glob, over_alloc);
>  			vmw_tt->sg_alloc_size -= over_alloc;
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID
From: Roland Scheidegger <sroland@vmware.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
	<dri-devel@lists.freedesktop.org>,
	<iommu@lists.linux-foundation.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Airlie <airlied@linux.ie>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Linux-graphics-maintainer] [PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues
Date: Tue, 12 May 2020 02:19:25 +0200	[thread overview]
Message-ID: <8adef36a-1f35-e8df-3b7b-2f994a204be1@vmware.com> (raw)
In-Reply-To: <20200505084614.30424-15-m.szyprowski@samsung.com>

I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger <sroland@vmware.com>

Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called with the original number of the entries passed to dma_map_sg. The
> sg_table->nents in turn holds the result of the dma_map_sg call as stated
> in include/linux/scatterlist.h. A common mistake was to ignore a result
> of the dma_map_sg function and don't use the sg_table->orig_nents at all.
> 
> To avoid such issues, lets use common dma-mapping wrappers operating
> directly on the struct sg_table objects and adjust references to the
> nents and orig_nents respectively.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> For more information, see '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 ++++-------------
>  1 file changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index bf0bc46..e50ae8b 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -362,8 +362,7 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
>  
> -	dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
> -		DMA_BIDIRECTIONAL);
> +	dma_unmap_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  	vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>  }
>  
> @@ -383,16 +382,8 @@ static void vmw_ttm_unmap_from_dma(struct vmw_ttm_tt *vmw_tt)
>  static int vmw_ttm_map_for_dma(struct vmw_ttm_tt *vmw_tt)
>  {
>  	struct device *dev = vmw_tt->dev_priv->dev->dev;
> -	int ret;
> -
> -	ret = dma_map_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.orig_nents,
> -			 DMA_BIDIRECTIONAL);
> -	if (unlikely(ret == 0))
> -		return -ENOMEM;
>  
> -	vmw_tt->sgt.nents = ret;
> -
> -	return 0;
> +	return dma_map_sgtable(dev, vmw_tt->sgt, DMA_BIDIRECTIONAL);
>  }
>  
>  /**
> @@ -449,10 +440,10 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
>  		if (unlikely(ret != 0))
>  			goto out_sg_alloc_fail;
>  
> -		if (vsgt->num_pages > vmw_tt->sgt.nents) {
> +		if (vsgt->num_pages > vmw_tt->sgt.orig_nents) {
>  			uint64_t over_alloc =
>  				sgl_size * (vsgt->num_pages -
> -					    vmw_tt->sgt.nents);
> +					    vmw_tt->sgt.orig_nents);
>  
>  			ttm_mem_global_free(glob, over_alloc);
>  			vmw_tt->sg_alloc_size -= over_alloc;
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-05-12  0:20 UTC|newest]

Thread overview: 157+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200505084308eucas1p1aa040c3ae325a6c7d92f956b1f5aad0d@eucas1p1.samsung.com>
2020-05-05  8:43 ` [PATCH v3 00/25] DRM: fix struct sg_table nents vs. orig_nents misuse Marek Szyprowski
2020-05-05  8:43   ` Marek Szyprowski
2020-05-05  8:43   ` Marek Szyprowski
2020-05-05  8:43   ` Marek Szyprowski
     [not found]   ` <CGME20200505084624eucas1p2a9a5c4d2aece2c1555a5480c19c2e050@eucas1p2.samsung.com>
2020-05-05  8:45     ` [PATCH v3 01/25] dma-mapping: add generic helpers for mapping sgtable objects Marek Szyprowski
2020-05-05  8:45       ` Marek Szyprowski
2020-05-05  8:45       ` Marek Szyprowski
2020-05-05  8:45       ` Marek Szyprowski
     [not found]       ` <CGME20200505084625eucas1p1a3c25fd171f360e0aab2f76700699454@eucas1p1.samsung.com>
2020-05-05  8:45         ` [PATCH v3 02/25] drm: core: fix common struct sg_table related issues Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05 10:15           ` Christoph Hellwig
2020-05-05 10:15             ` Christoph Hellwig
2020-05-05 10:15             ` Christoph Hellwig
2020-05-05 10:51             ` Marek Szyprowski
2020-05-05 10:51               ` Marek Szyprowski
2020-05-05 10:51               ` Marek Szyprowski
2020-05-05 10:51               ` Marek Szyprowski
2020-05-05 11:09               ` Christoph Hellwig
2020-05-05 11:09                 ` Christoph Hellwig
2020-05-05 11:09                 ` Christoph Hellwig
2020-05-08  7:12                 ` Marek Szyprowski
2020-05-08  7:12                   ` Marek Szyprowski
2020-05-08  7:12                   ` Marek Szyprowski
2020-05-08  7:12                   ` Marek Szyprowski
2020-05-08  7:16                   ` Christoph Hellwig
2020-05-08  7:16                     ` Christoph Hellwig
2020-05-08  7:16                     ` Christoph Hellwig
2020-05-12  9:05                     ` Marek Szyprowski
2020-05-12  9:05                       ` Marek Szyprowski
2020-05-12  9:05                       ` Marek Szyprowski
2020-05-12  9:05                       ` Marek Szyprowski
     [not found]       ` <CGME20200505084625eucas1p2b8ca16ff91ba9d6655f525ef85915d00@eucas1p2.samsung.com>
2020-05-05  8:45         ` [PATCH v3 03/25] drm: amdgpu: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084626eucas1p20753456727333c09718253ca5c32d98c@eucas1p2.samsung.com>
2020-05-05  8:45         ` [PATCH v3 04/25] drm: armada: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084626eucas1p20abe79e406f60ae92fec252072befc5a@eucas1p2.samsung.com>
2020-05-05  8:45         ` [PATCH v3 05/25] drm: etnaviv: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084627eucas1p119c77fbf28532627f27382efc51b0aaa@eucas1p1.samsung.com>
2020-05-05  8:45         ` [PATCH v3 06/25] drm: exynos: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084627eucas1p199eed52198b4409da1fa8e2256f5bb62@eucas1p1.samsung.com>
2020-05-05  8:45         ` [PATCH v3 07/25] drm: i915: " Marek Szyprowski
2020-05-05  8:45           ` [Intel-gfx] " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084628eucas1p2c87aae2f471b716675559debbf680c46@eucas1p2.samsung.com>
2020-05-05  8:45         ` [PATCH v3 08/25] drm: lima: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084629eucas1p12e882329da88edd155ba9f9f952889a0@eucas1p1.samsung.com>
2020-05-05  8:45         ` [PATCH v3 09/25] drm: msm: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
     [not found]       ` <CGME20200505084629eucas1p23d2d6a53451e67e2b0a3544eb696008b@eucas1p2.samsung.com>
2020-05-05  8:45         ` [PATCH v3 10/25] drm: panfrost: " Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-05  8:45           ` Marek Szyprowski
2020-05-11 15:51           ` Steven Price
2020-05-11 15:51             ` Steven Price
2020-05-11 15:51             ` Steven Price
2020-05-11 15:51             ` Steven Price
     [not found]       ` <CGME20200505084630eucas1p1c74cd5d287e1080b85d98edde405a577@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 11/25] drm: radeon: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084630eucas1p2199401486591b681b84a4b24496295fb@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 12/25] drm: rockchip: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084631eucas1p11121f9373a1d282f0262d1faa33f35fb@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 13/25] drm: tegra: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084632eucas1p2e37c536205c057984c5f0355f6ffe1c2@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 14/25] drm: virtio: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084632eucas1p231212e9cea88e755da8eaf1fb012d2c6@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 15/25] drm: vmwgfx: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-12  0:19           ` Roland Scheidegger [this message]
2020-05-12  0:19             ` [Linux-graphics-maintainer] " Roland Scheidegger
2020-05-12  0:19             ` Roland Scheidegger
2020-05-12  0:19             ` Roland Scheidegger
     [not found]       ` <CGME20200505084633eucas1p26a6a3f44c64955aadec834bed027e522@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 16/25] xen: gntdev: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084633eucas1p19798e1fb42c9430a93d668bc585e58da@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 17/25] drm: host1x: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084634eucas1p1e0ea160dd77afbf6d2f7e6154ded40d0@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 18/25] drm: rcar-du: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  9:24           ` Geert Uytterhoeven
2020-05-05  9:24             ` Geert Uytterhoeven
2020-05-05  9:24             ` Geert Uytterhoeven
2020-05-05  9:24             ` Geert Uytterhoeven
     [not found]       ` <CGME20200505084634eucas1p105456f28d9a7935190478546e566975f@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 19/25] dmabuf: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084635eucas1p14800a1e2598364d168adecd57b94225c@eucas1p1.samsung.com>
2020-05-05  8:46         ` [PATCH v3 20/25] staging: ion: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084636eucas1p23a33d0b83ca284692713745d004f93ea@eucas1p2.samsung.com>
     [not found]         ` <20200505084614.30424-1-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2020-05-05  8:46           ` [PATCH v3 21/25] staging: tegra-vde: " Marek Szyprowski
2020-05-05  8:46             ` Marek Szyprowski
2020-05-05  8:46             ` Marek Szyprowski
2020-05-05  8:46             ` Marek Szyprowski
2020-05-05  8:46             ` Marek Szyprowski
2020-05-05  8:46             ` Marek Szyprowski
     [not found]       ` <CGME20200505084637eucas1p20390fa3c010bde00e438cce1b48d209c@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 22/25] misc: fastrpc: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084637eucas1p2c6d4b880698e8db97a8a9468692befe1@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 23/25] rapidio: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084638eucas1p24f356b441a3589e9528d239c0b9ac666@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 24/25] samples: vfio-mdev/mbochs: " Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
     [not found]       ` <CGME20200505084638eucas1p2d4add214063543248d81c0977e3f1823@eucas1p2.samsung.com>
2020-05-05  8:46         ` [PATCH v3 25/25] media: pci: fix common ALSA DMA-mapping related codes Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05  8:46           ` Marek Szyprowski
2020-05-05 10:22       ` [PATCH v3 01/25] dma-mapping: add generic helpers for mapping sgtable objects Christoph Hellwig
2020-05-05 10:22         ` Christoph Hellwig
2020-05-05 10:22         ` Christoph Hellwig
2020-05-05 10:44         ` Marek Szyprowski
2020-05-05 10:44           ` Marek Szyprowski
2020-05-05 10:44           ` Marek Szyprowski
2020-05-05 10:44           ` Marek Szyprowski
2020-05-07  8:47       ` Hans Verkuil
2020-05-07  8:47         ` Hans Verkuil
2020-05-07  8:47         ` Hans Verkuil
2020-05-07  8:47         ` Hans Verkuil

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=8adef36a-1f35-e8df-3b7b-2f994a204be1@vmware.com \
    --to=sroland@vmware.com \
    --cc=airlied@linux.ie \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.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.