drm/udl: avoid swiotlb for imported vmap buffers.

PATCH In review Dave Airlie 3 participants 8 messages May 1, 2013 – May 6, 2013

Subsystems (4)

DRM drivers Media (V4L/DVB) DRM misc DRM driver for USB displaylink video adapters

lore

Share & tools

lore

Dave Airlie

author maintainer

2013-05-01 04:34 UTC #0 lore raw

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

Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer.

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 <[email protected]>

---
 drivers/gpu/drm/udl/udl_main.c | 1 +
 1 file changed, 1 insertion(+)

drivers/gpu/drm/udl/udl_main.c +1 -0

index 0ce2d71..6770e1b 100644
@@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long flags)
 	udl->ddev = dev;
 	dev->dev_private = udl;
 
+	dma_set_mask(dev->dev, DMA_BIT_MASK(64));
 	if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) {
 		DRM_ERROR("firmware not recognized. Assume incompatible device\n");
 		goto err;

Signature · 1 line

1.8.2

Daniel Vetter

2013-05-01 08:53 UTC #1 lore raw

Quoted 9 lines · Dave Airlie

Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer.
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 <[email protected]>

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 ;-)
-Daniel

Quoted 19 lines

---
 drivers/gpu/drm/udl/udl_main.c | 1 +
 1 file changed, 1 insertion(+)

drivers/gpu/drm/udl/udl_main.c +1 -1

index 0ce2d71..6770e1b 100644
@@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long flags)
        udl->ddev = dev;
        dev->dev_private = udl;
 
+       dma_set_mask(dev->dev, DMA_BIT_MASK(64));
        if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) {
                DRM_ERROR("firmware not recognized. Assume incompatible device\n");
                goto err;
--

1.8.2

Quoted 4 lines

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Dave Airlie

author maintainer

2013-05-06 00:35 UTC #2 lore raw

Quoted 5 lines

Quoted 5 lines
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.

Quoted 8 lines

Quoted 1 line
Signed-off-by Dave Airlie <[email protected]>
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.

So it looks like this won't really fly.

Dave.

Daniel Vetter

2013-05-06 15:56 UTC #3 lore raw

Quoted 14 lines · Dave Airlie

Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 1 line
Signed-off-by Dave Airlie <[email protected]>
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 ;-)

Quoted 3 lines

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? -Daniel

Signature · 3 lines

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Dave Airlie

author maintainer

2013-05-06 19:56 UTC #4 lore raw

Quoted 15 lines · Daniel Vetter

Quoted 14 lines · Dave Airlie
Quoted 13 lines
Quoted 6 lines
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 <[email protected]>
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 ;-)

Quoted 5 lines

Quoted 3 lines
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.

Dave.

Daniel Vetter

2013-05-06 20:44 UTC #5 lore raw

Quoted 16 lines · Dave Airlie

Quoted 15 lines · Daniel Vetter
Quoted 14 lines · Dave Airlie
Quoted 13 lines
Quoted 6 lines
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 <[email protected]>
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 ;-)

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
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

Rob Clark

2013-05-06 22:13 UTC #6 lore raw

Quoted 21 lines · Daniel Vetter

Quoted 20 lines · Dave Airlie
Quoted 19 lines · Daniel Vetter
Quoted 17 lines · Dave Airlie
Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 1 line
Signed-off-by Dave Airlie <[email protected]>
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.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
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.

fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap for the dmabuf object by fwd'ing it to my normal gem mmap code. Might be the opposite of what you are looking for here. Although I suppose the reverse could work to, I hadn't really thought about it yet.

BR,
-R

Quoted 14 lines

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
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Dave Airlie

author maintainer

2013-05-06 22:45 UTC #7 lore raw

Quoted 7 lines

Quoted 6 lines
Quoted 1 line
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.

Quoted 5 lines

fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap for the dmabuf object by fwd'ing it to my normal gem mmap code. Might be the opposite of what you are looking for here. Although I suppose the reverse could work to, I hadn't really thought about it yet.

Yeah thats the opposite, I want to implement my GEM mmap ioctls using dma-buf mmaps :)

Dave.