[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2cfadc7-2e0b-b63d-d094-d5339b0c85fe@gmail.com>
Date: Thu, 20 Dec 2018 17:49:39 +0200
From: Oleksandr Andrushchenko <andr2000@...il.com>
To: Christoph Hellwig <hch@...radead.org>,
Noralf Trønnes <noralf@...nnes.org>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, daniel.vetter@...el.com,
jgross@...e.com, boris.ostrovsky@...cle.com,
Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent
On 12/20/18 5:36 PM, Christoph Hellwig wrote:
> On Tue, Dec 18, 2018 at 08:20:22PM +0100, Noralf Trønnes wrote:
>>> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>>> + DMA_BIDIRECTIONAL)) {
>>
>> Are you using the DMA streaming API as a way to flush the caches?
> This looks rather broken. Please send the whole patch series to
> the iommu list for proper review.
This is the only patch [1], no series. And at the moment I think
there is nothing to review as I am not sure how to deal with those
shmem pages: this patch is rather to start a discussion on how shmem
pages can be flushed on ARM (the only workaround I have so far is
in this patch which uses DMA API). This is where I am looking for
some advice, so I can implement the patch the right way.
>> Does this mean that GFP_USER isn't making the buffer coherent?
> How could GFP_USER make memory coherent in any way?
I am no way an expert here, but other DRM drivers allocate buffers
from shmem and then use DMA API [2], for example [3]
[1] https://patchwork.kernel.org/patch/10700089/
[2] https://elixir.bootlin.com/linux/v4.20-rc7/ident/drm_gem_get_pages
[3]
https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/gpu/drm/omapdrm/omap_gem.c#L248
Powered by blists - more mailing lists