On Mon, May 6, 2013 at 9:56 PM, Dave Airlie <airlied at gmail.com> wrote: > On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter <daniel at 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 at 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
