On 20.04.2017 13:02, Arnd Bergmann wrote:
On Thu, Apr 20, 2017 at 11:44 AM, Mikko Perttunen <cyndis@xxxxxxxx> wrote:
On 20.04.2017 11:25, Arnd Bergmann wrote:
On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@xxxxxxxx> wrote:
On 19.04.2017 21:24, Arnd Bergmann wrote:
I don't think this can be a per-platform policy.
Yeah, now that we are using the ARM SMMU on T186 onwards it's more difficult
than when we were using the Tegra SMMU, so we'll probably have to change
that.
The goal of the current code is to allocate memory from the CMA, so one
option would be to change it to use dma_alloc_from_contiguous. That way we
wouldn't get the double IOMMU mapping, which would be nice.
Right, also we shouldn't define what a particular API does based on
which platform you run on.
Indeed.
The goal of the current code is to allocate memory from the CMA, so one
option would be to change it to use dma_alloc_from_contiguous. That way
we wouldn't get the double IOMMU mapping, which would be nice.
dma_alloc_from_contiguous() is intentionally not exported to drivers,
and it would result in a page that is not mapped into your kernel
address space.
Ah, sorry, didn't notice that while looking.
This is probably not the only driver that has this issue, so maybe a
better approach would be to fill the API gap and introduce an IOMMU
API function that takes a domain/iova/length tuple as its argument
and allocates coherent or WC memory that it maps into that address?
There is definitely space for some API improvement in the whole IOMMU
domain memory allocation space. I would prefer keeping the IOMMU mapping
and memory allocation separate, though, since otherwise we couldn't map
the same physical memory into multiple domains (or have some memory that
is temporarily not mapped into any.)
The issue seems to be non-trivial, so I'm fine with your RFC patch - it
solves the issue and the double domain mapping thing is not a problem
currently as we don't yet support IOMMU on T186. By the time we do
support it I hope we'll have the new API or whatever replacement in place.
Arnd
Thanks,
Mikko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
