All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: dri-devel@lists.freedesktop.org,
	iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues
Date: Fri, 8 May 2020 09:12:13 +0200	[thread overview]
Message-ID: <b887c355-14db-ad37-0e93-733ff2249967@samsung.com> (raw)
In-Reply-To: <20200505110950.GA19067@lst.de>

Hi Christoph,

On 05.05.2020 13:09, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote:
>> On 05.05.2020 12:15, Christoph Hellwig wrote:
>>>> -		for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>>>> +		for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
>>> Would it make sense to also add a for_each_sgtable_page helper that
>>> hides the use of orig_nents?  To be used like:
>>>
>>> 		for_each_sgtable_page(st, &sg_iter, 0) {
>> We would need two helpers:
>>
>> for_each_sgtable_cpu_page() and for_each_sgtable_dma_page().
>>
>> I considered them, but then I found that there are already
>> for_each_sg_page(), for_each_sg_dma_page() and various special iterators
>> like sg_page_iter, sg_dma_page_iter and sg_mapping_iter. Too bad that
>> they are almost not used, at least in the DRM subsystem. I wonder if it
>> make sense to apply them or simply provide the two above mentioned
>> wrappers?
> None of the helpers helps with passing the right parameters from the
> sg_table.  So in doube we'd need wrappers for all of the above, or
> none..

I've played a bit with the code and the existing scatterlist iterators - 
for_each_sg_page() and for_each_sg_dma_page(). I've found them quite handy!

The biggest advantage of them is that they always iterate over 
scatterlist in PAGE_SIZE units, what should make the code much easier to 
understand. Here is example of their application to the function that 
started this thread:

int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
                                      dma_addr_t *addrs, int max_entries)
{
         struct sg_dma_page_iter dma_iter;
         struct sg_page_iter page_iter;

         if (addrs)
                 for_each_sgtable_dma_page(sgt, &dma_iter, 0)
                         *addrs++ = sg_page_iter_dma_address(&dma_iter);
         if (pages)
                 for_each_sgtable_page(sgt, &page_iter, 0)
                         *pages++ = sg_page_iter_page(&page_iter);
         return 0;
}

After applying those iterators where possible (they can be used only for 
reading the scatterlist), we would just need to add 2 trivial wrappers 
to use them with sg_table objects:

#define for_each_sgtable_page(sgt, piter, pgoffset)    \
        for_each_sg_page(sgt->sgl, piter, sgt->orig_nents, pgoffset)

#define for_each_sgtable_dma_page(sgt, dma_iter, pgoffset)     \
        for_each_sg_dma_page(sgt->sgl, dma_iter, sgt->nents, pgoffset)

Then we would just need one more helper to construct scatterlist, as the 
above two are read-only don't allow to modify scatterlist:

#define for_each_sgtable_sg(sgt, sg, i)                \
        for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)

With the above 3 helpers we can probably get rid of all instances of 
sg_table->{nents,orig_nents} from the DRM code. I will prepare patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


WARNING: multiple messages have this Message-ID
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, iommu@lists.linux-foundation.org,
	Maxime Ripard <mripard@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues
Date: Fri, 8 May 2020 09:12:13 +0200	[thread overview]
Message-ID: <b887c355-14db-ad37-0e93-733ff2249967@samsung.com> (raw)
In-Reply-To: <20200505110950.GA19067@lst.de>

Hi Christoph,

On 05.05.2020 13:09, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote:
>> On 05.05.2020 12:15, Christoph Hellwig wrote:
>>>> -		for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>>>> +		for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
>>> Would it make sense to also add a for_each_sgtable_page helper that
>>> hides the use of orig_nents?  To be used like:
>>>
>>> 		for_each_sgtable_page(st, &sg_iter, 0) {
>> We would need two helpers:
>>
>> for_each_sgtable_cpu_page() and for_each_sgtable_dma_page().
>>
>> I considered them, but then I found that there are already
>> for_each_sg_page(), for_each_sg_dma_page() and various special iterators
>> like sg_page_iter, sg_dma_page_iter and sg_mapping_iter. Too bad that
>> they are almost not used, at least in the DRM subsystem. I wonder if it
>> make sense to apply them or simply provide the two above mentioned
>> wrappers?
> None of the helpers helps with passing the right parameters from the
> sg_table.  So in doube we'd need wrappers for all of the above, or
> none..

I've played a bit with the code and the existing scatterlist iterators - 
for_each_sg_page() and for_each_sg_dma_page(). I've found them quite handy!

The biggest advantage of them is that they always iterate over 
scatterlist in PAGE_SIZE units, what should make the code much easier to 
understand. Here is example of their application to the function that 
started this thread:

int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
                                      dma_addr_t *addrs, int max_entries)
{
         struct sg_dma_page_iter dma_iter;
         struct sg_page_iter page_iter;

         if (addrs)
                 for_each_sgtable_dma_page(sgt, &dma_iter, 0)
                         *addrs++ = sg_page_iter_dma_address(&dma_iter);
         if (pages)
                 for_each_sgtable_page(sgt, &page_iter, 0)
                         *pages++ = sg_page_iter_page(&page_iter);
         return 0;
}

After applying those iterators where possible (they can be used only for 
reading the scatterlist), we would just need to add 2 trivial wrappers 
to use them with sg_table objects:

#define for_each_sgtable_page(sgt, piter, pgoffset)    \
        for_each_sg_page(sgt->sgl, piter, sgt->orig_nents, pgoffset)

#define for_each_sgtable_dma_page(sgt, dma_iter, pgoffset)     \
        for_each_sg_dma_page(sgt->sgl, dma_iter, sgt->nents, pgoffset)

Then we would just need one more helper to construct scatterlist, as the 
above two are read-only don't allow to modify scatterlist:

#define for_each_sgtable_sg(sgt, sg, i)                \
        for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)

With the above 3 helpers we can probably get rid of all instances of 
sg_table->{nents,orig_nents} from the DRM code. I will prepare patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

WARNING: multiple messages have this Message-ID
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, iommu@lists.linux-foundation.org,
	Maxime Ripard <mripard@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues
Date: Fri, 8 May 2020 09:12:13 +0200	[thread overview]
Message-ID: <b887c355-14db-ad37-0e93-733ff2249967@samsung.com> (raw)
In-Reply-To: <20200505110950.GA19067@lst.de>

Hi Christoph,

On 05.05.2020 13:09, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote:
>> On 05.05.2020 12:15, Christoph Hellwig wrote:
>>>> -		for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>>>> +		for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
>>> Would it make sense to also add a for_each_sgtable_page helper that
>>> hides the use of orig_nents?  To be used like:
>>>
>>> 		for_each_sgtable_page(st, &sg_iter, 0) {
>> We would need two helpers:
>>
>> for_each_sgtable_cpu_page() and for_each_sgtable_dma_page().
>>
>> I considered them, but then I found that there are already
>> for_each_sg_page(), for_each_sg_dma_page() and various special iterators
>> like sg_page_iter, sg_dma_page_iter and sg_mapping_iter. Too bad that
>> they are almost not used, at least in the DRM subsystem. I wonder if it
>> make sense to apply them or simply provide the two above mentioned
>> wrappers?
> None of the helpers helps with passing the right parameters from the
> sg_table.  So in doube we'd need wrappers for all of the above, or
> none..

I've played a bit with the code and the existing scatterlist iterators - 
for_each_sg_page() and for_each_sg_dma_page(). I've found them quite handy!

The biggest advantage of them is that they always iterate over 
scatterlist in PAGE_SIZE units, what should make the code much easier to 
understand. Here is example of their application to the function that 
started this thread:

int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
                                      dma_addr_t *addrs, int max_entries)
{
         struct sg_dma_page_iter dma_iter;
         struct sg_page_iter page_iter;

         if (addrs)
                 for_each_sgtable_dma_page(sgt, &dma_iter, 0)
                         *addrs++ = sg_page_iter_dma_address(&dma_iter);
         if (pages)
                 for_each_sgtable_page(sgt, &page_iter, 0)
                         *pages++ = sg_page_iter_page(&page_iter);
         return 0;
}

After applying those iterators where possible (they can be used only for 
reading the scatterlist), we would just need to add 2 trivial wrappers 
to use them with sg_table objects:

#define for_each_sgtable_page(sgt, piter, pgoffset)    \
        for_each_sg_page(sgt->sgl, piter, sgt->orig_nents, pgoffset)

#define for_each_sgtable_dma_page(sgt, dma_iter, pgoffset)     \
        for_each_sg_dma_page(sgt->sgl, dma_iter, sgt->nents, pgoffset)

Then we would just need one more helper to construct scatterlist, as the 
above two are read-only don't allow to modify scatterlist:

#define for_each_sgtable_sg(sgt, sg, i)                \
        for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)

With the above 3 helpers we can probably get rid of all instances of 
sg_table->{nents,orig_nents} from the DRM code. I will prepare patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
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: Marek Szyprowski <m.szyprowski@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, iommu@lists.linux-foundation.org,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues
Date: Fri, 8 May 2020 09:12:13 +0200	[thread overview]
Message-ID: <b887c355-14db-ad37-0e93-733ff2249967@samsung.com> (raw)
In-Reply-To: <20200505110950.GA19067@lst.de>

Hi Christoph,

On 05.05.2020 13:09, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote:
>> On 05.05.2020 12:15, Christoph Hellwig wrote:
>>>> -		for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>>>> +		for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
>>> Would it make sense to also add a for_each_sgtable_page helper that
>>> hides the use of orig_nents?  To be used like:
>>>
>>> 		for_each_sgtable_page(st, &sg_iter, 0) {
>> We would need two helpers:
>>
>> for_each_sgtable_cpu_page() and for_each_sgtable_dma_page().
>>
>> I considered them, but then I found that there are already
>> for_each_sg_page(), for_each_sg_dma_page() and various special iterators
>> like sg_page_iter, sg_dma_page_iter and sg_mapping_iter. Too bad that
>> they are almost not used, at least in the DRM subsystem. I wonder if it
>> make sense to apply them or simply provide the two above mentioned
>> wrappers?
> None of the helpers helps with passing the right parameters from the
> sg_table.  So in doube we'd need wrappers for all of the above, or
> none..

I've played a bit with the code and the existing scatterlist iterators - 
for_each_sg_page() and for_each_sg_dma_page(). I've found them quite handy!

The biggest advantage of them is that they always iterate over 
scatterlist in PAGE_SIZE units, what should make the code much easier to 
understand. Here is example of their application to the function that 
started this thread:

int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
                                      dma_addr_t *addrs, int max_entries)
{
         struct sg_dma_page_iter dma_iter;
         struct sg_page_iter page_iter;

         if (addrs)
                 for_each_sgtable_dma_page(sgt, &dma_iter, 0)
                         *addrs++ = sg_page_iter_dma_address(&dma_iter);
         if (pages)
                 for_each_sgtable_page(sgt, &page_iter, 0)
                         *pages++ = sg_page_iter_page(&page_iter);
         return 0;
}

After applying those iterators where possible (they can be used only for 
reading the scatterlist), we would just need to add 2 trivial wrappers 
to use them with sg_table objects:

#define for_each_sgtable_page(sgt, piter, pgoffset)    \
        for_each_sg_page(sgt->sgl, piter, sgt->orig_nents, pgoffset)

#define for_each_sgtable_dma_page(sgt, dma_iter, pgoffset)     \
        for_each_sg_dma_page(sgt->sgl, dma_iter, sgt->nents, pgoffset)

Then we would just need one more helper to construct scatterlist, as the 
above two are read-only don't allow to modify scatterlist:

#define for_each_sgtable_sg(sgt, sg, i)                \
        for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)

With the above 3 helpers we can probably get rid of all instances of 
sg_table->{nents,orig_nents} from the DRM code. I will prepare patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

  reply	other threads:[~2020-05-08  7:12 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 [this message]
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           ` [Linux-graphics-maintainer] " Roland Scheidegger
2020-05-12  0:19             ` 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=b887c355-14db-ad37-0e93-733ff2249967@samsung.com \
    --to=m.szyprowski@samsung.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-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robin.murphy@arm.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.