On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches
We've broken that assumption in i915 years ago. Not struct page backedFor GPU drivers on x86 with no dma coherency problems, sure. But not
gpu memory is very real.
Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.
all the world is x86. We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.
tends to be too expensive, so there's pci-e support and chipset support to
forgo it. Plus drivers flushing caches themselves.
The dma_get_sgtable thing is indeed fun, right solution would probably be
to push the dma-buf export down into the dma layer. The comment for
arm_dma_get_sgtable is also not a realy concern, because dma-buf also
abstracts away the flushing (or well is supposed to), so there really
shouldn't be anyone calling the streaming apis on the returned sg table.
That's why dma-buf gives you an sg table that's mapped already.
So we should just implement a copy of sg table for dma-buf, since I stillIf that's not acceptable then I guess we could go over the entire treeIt isn't silly. We will have to do some surgery like that anyway
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
because the current APIs don't work. So relax, sit back and come up
with an API that solves the existing issues and serves us well in
think it does exactly what we need for gpus?
Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into dma-buf", but that doesn't render the interface a bad idea.