[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
>>> 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. > Yeah thats the opposite, I want to implement my GEM mmap ioctls using dma-buf mmaps :) Dave.
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter 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 >> > >> > Fyi for everyone else who was not on irc when Dave 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. Dave.
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: > On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter 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 >>> > >>> > Fyi for everyone else who was not on irc when Dave 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
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 4:44 PM, Daniel Vetter wrote: > On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: >> On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter 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 > > Fyi for everyone else who was not on irc when Dave 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. 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 > 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 > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
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 > > > > Fyi for everyone else who was not on irc when Dave 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? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
>> >> 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 > > Fyi for everyone else who was not on irc when Dave 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.
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
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 airl...@redhat.com Fyi for everyone else who was not on irc when DaveI 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? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter dan...@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 airl...@redhat.com Fyi for everyone else who was not on irc when DaveI 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. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie airl...@gmail.com wrote: On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter dan...@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 airl...@redhat.com Fyi for everyone else who was not on irc when DaveI 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
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. Yeah thats the opposite, I want to implement my GEM mmap ioctls using dma-buf mmaps :) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] 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
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..6770e1b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -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
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Wed, May 1, 2013 at 6:30 AM, Dave Airlie wrote:
> 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
Fyi for everyone else who was not on irc when Dave 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
> ---
> drivers/gpu/drm/udl/udl_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 0ce2d71..6770e1b 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -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
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] 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 airl...@redhat.com
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..6770e1b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Wed, May 1, 2013 at 6:30 AM, Dave Airlie airl...@gmail.com wrote:
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 airl...@redhat.com
Fyi for everyone else who was not on irc when DaveI 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
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..6770e1b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
