On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
As I've already pointed out, there's a major problem if you have already had a less restrictive attachment which has an active mapping, and a new more restrictive attachment comes along later.
It seems from Rob's descriptions that we also need another flag in the importer to indicate whether it wants to have a valid struct page in the scatter list, or whether it (correctly) uses the DMA accessors on the scatter list - so that exporters can reject importers which are buggy.
to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation)..
I still hold that if the dma api steals the iommu your gpu needs for context switching then that's a bug in the platform setup code. dma api really doesn't have any concept of switchable hw contexts. So trying to work around this brokeness by mandating it as a valid dma-buf use-case is totally backwards.
sure, my only point is that if I'm the odd man out, I can live with a hack (ie. requiring drm/msm to be aware enough of the platform to know if there is >1 level of address translation and frob'ing my 'struct device' accordingly)... no point in a generic solution for one user. I like to be practical.
BR, -R
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch