[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d5f35da4a6b58639519f0764c7edbfe4dd1ba02.camel@vmware.com>
Date: Mon, 8 Apr 2019 18:47:52 +0000
From: Thomas Hellstrom <thellstrom@...are.com>
To: "hch@....de" <hch@....de>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Deepak Singh Rawat <drawat@...are.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: revert dma direct internals abuse
Christoph,
On Mon, 2019-04-08 at 12:55 +0200, Christoph Hellwig wrote:
> Hi Linus,
>
> unfortunately it took less than a merge window for the:
>
> /*
> * All the dma_direct_* declarations are here just for the indirect
> call bypass,
> * and must not be used directly drivers!
> */
>
> warning in dma-mapping.h to be ignored. This series reverts the
> offender
> to keep our API clean.
>
> Thomas: please talk me first about your needs and I'll be happy to
> figure out
> a proper API for what you want to do.
We HAVE discussed our needs, although admittedly some of my emails
ended up unanswered.
We've as you're well aware of had a discussion with the other
subsystems doing user-space DMA-buffers wanting this functionality from
the dma api (AMD graphics and RDMA people IIRC). that is a bool that
tells us whether streaming dma mappings are coherent, and I described
in detail why we couldn't use the dma_sync_* API and
dma_alloc_coherent().
The other option we have is to just fail miserably without messages if
streaming DMA is not coherent, which I think the other drivers might
do... That's all I'm trying to avoid here. I'd much prefer to have the
dma API export this bool.
/Thomas
Powered by blists - more mailing lists