[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

[Daniel Vetter]

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