On 14/08/2018 14:04, Robin Murphy wrote:
John raised the issue[1] that we have some unnecessary refcount contention
in the DMA ops path which shows scalability problems now that we have more
real high-performance hardware using iommu-dma. The x86 IOMMU drivers are
sidestepping this by stashing
On Fri, Aug 17, 2018 at 12:30:31PM +0100, Robin Murphy wrote:
> On 17/08/18 08:24, Christoph Hellwig wrote:
> > I plan to make the arm iommu dma ops generic and move them to
> > drivers/iommu for the 4.20 merge window.
>
> You mean 32-bit arm?
Sorry, I meant the arm64 wrappers for dma-iommu of
On 17/08/18 08:24, Christoph Hellwig wrote:
I plan to make the arm iommu dma ops generic and move them to
drivers/iommu for the 4.20 merge window.
You mean 32-bit arm? The only place that code should move to is
/dev/null ;) - the plan has always been to convert it to use groups and
default
On Fri, Aug 17, 2018 at 12:24:15AM -0700, Christoph Hellwig wrote:
> I plan to make the arm iommu dma ops generic and move them to
> drivers/iommu for the 4.20 merge window. Because of that it would
> be great to create a stable branch or even pull this in through
> the dma-mapping tree entirely.
I plan to make the arm iommu dma ops generic and move them to
drivers/iommu for the 4.20 merge window. Because of that it would
be great to create a stable branch or even pull this in through
the dma-mapping tree entirely.
___
iommu mailing list
On 14/08/2018 14:04, Robin Murphy wrote:
John raised the issue[1] that we have some unnecessary refcount contention
in the DMA ops path which shows scalability problems now that we have more
real high-performance hardware using iommu-dma. The x86 IOMMU drivers are
sidestepping this by stashing
