On Mon, May 6, 2013 at 9:56 PM, Dave Airlie airlied@gmail.com wrote:
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote:
However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have it enabled, which is less than desireable.
Signed-off-by: Dave Airlie airlied@redhat.com
Fyi for everyone else who was not on irc when Dave&I discussed this: This really shouldn't be required and I think the real issue is that udl creates a dma_buf attachement (which is needed for device dma only), but only really wants to do cpu access through vmap/kmap. So not attached the device should be good enough. Cc'ing a few more lists for better fyi ;-)
Though I've looked at this a bit more, and since I want to be able to expose shared objects as proper GEM objects from the import side I really need that list of pages.
Hm, what does "proper GEM object" mean in the context of udl?
One that appears the same as a GEM object created by userspace. i.e. mmap works.
Oh, we have an mmap interface in the dma_buf thing for that, and iirc Rob Clark even bothered to implement the gem->dma_buf mmap forwarding somewhere. And iirc android's ion-on-dma_buf stuff is even using the mmap interface stuff.
Now for prime "let's just ship this, dammit" prevailed for now. But I still think that hiding the backing storage a bit better (with the eventual goal of supporting eviction with Maarten's fence/ww_mutex madness) feels like a worthy long-term goal.
Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch