On Sat, Jul 12, 2014 at 08:57:31AM -0400, Rob Clark wrote: > On Sat, Jul 12, 2014 at 8:22 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: [...] > > The way that Thierry's binding does that is the obvious solution to this, > > and it mirrors what we do in practically every other subsystem. I definitely > > want the SMMU to change before anybody starts using it in a real system, > > which we fortunately do not have yet. > > hmm, well if some of the things I need for (like this or batching > mappings) are too weird and gpu specific, I'm willing to duplicate the > IOMMU driver in drm/msm. It really isn't so much code, and that gives > me a lot more more flexibility to do crazy things... at some point I'm > probably going to want to do context switches by banging the IOMMU > registers directly from the gpu. If the IOMMU API doesn't provide for what you need, then perhaps it's time to enhance it? We do that all the time in other parts of the kernel, why should IOMMU be special? It seems to me like context switching for per-process address space isolation is one of the important features of an IOMMU. If the current API doesn't let you do that then we should think of ways how it can be improved. And if it doesn't do it fast enough, then we should equally find ways to speed it up. This is part of why I think it would be good to have explicit objects associated with IOMMU contexts. That would give us a good place to add caching for this kind of situation. Currently we're required to handle most of this in drivers (map from struct device to context, ...). Thierry
Attachment:
pgpGvmp76LSGf.pgp
Description: PGP signature
