[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150204001439.GB8656@n2100.arm.linux.org.uk>
Date: Wed, 4 Feb 2015 00:14:39 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Arnd Bergmann <arnd@...db.de>
Cc: linaro-mm-sig@...ts.linaro.org, Daniel Vetter <daniel@...ll.ch>,
linaro-kernel@...ts.linaro.org,
Robin Murphy <robin.murphy@....com>,
LKML <linux-kernel@...r.kernel.org>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Rob Clark <robdclark@...il.com>,
Tomasz Stanislawski <stanislawski.tomasz@...glemail.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing
attacher constraints with dma-parms
On Tue, Feb 03, 2015 at 10:42:26PM +0100, Arnd Bergmann wrote:
> Right, if you have a private iommu, there is no problem. The tricky part
> is using a single driver for the system-level translation and the gpu
> private mappings when there is only one type of iommu in the system.
You've got a problem anyway with this approach. If you look at my
figure 2 and apply it to this scenario, you have two MMUs stacked
on top of each other. That's something that (afaik) we don't support,
but it's entirely possible that will come along with ARM64.
It may not be nice to have to treat GPUs specially, but I think we
really do need to, and forget the idea that the GPU's IOMMU (as
opposed to a system MMU) should appear in a generic form in DT.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists