* [PATCHv3 1/3] drm/vgem: Add a dummy platform device
2017-05-02 17:02 [PATCHv3 0/3] dma_buf import support for vgem Laura Abbott
@ 2017-05-02 17:02 ` Laura Abbott
2017-05-02 17:02 ` Laura Abbott
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: Laura Abbott, dri-devel, linux-kernel, Sumit Semwal, intel-gfx,
Joonas Lahtinen
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: No changes
---
drivers/gpu/drm/vgem/vgem_drv.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a..727eed2 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -335,11 +335,20 @@ static int __init vgem_init(void)
int ret;
vgem_device = drm_dev_alloc(&vgem_driver, NULL);
- if (IS_ERR(vgem_device)) {
- ret = PTR_ERR(vgem_device);
+ if (IS_ERR(vgem_device))
+ return PTR_ERR(vgem_device);
+
+ vgem_device->platformdev = platform_device_register_simple("vgem",
+ -1, NULL, 0);
+
+ if (!vgem_device->platformdev) {
+ ret = -ENODEV;
goto out;
}
+ dma_coerce_mask_and_coherent(&vgem_device->platformdev->dev,
+ DMA_BIT_MASK(64));
+
ret = drm_dev_register(vgem_device, 0);
if (ret)
goto out_unref;
@@ -347,13 +356,15 @@ static int __init vgem_init(void)
return 0;
out_unref:
- drm_dev_unref(vgem_device);
+ platform_device_unregister(vgem_device->platformdev);
out:
+ drm_dev_unref(vgem_device);
return ret;
}
static void __exit vgem_exit(void)
{
+ platform_device_unregister(vgem_device->platformdev);
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
}
--
2.7.4
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCHv3 1/3] drm/vgem: Add a dummy platform device
@ 2017-05-02 17:02 ` Laura Abbott
0 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: intel-gfx, Joonas Lahtinen, linux-kernel, dri-devel
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: No changes
---
drivers/gpu/drm/vgem/vgem_drv.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a..727eed2 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -335,11 +335,20 @@ static int __init vgem_init(void)
int ret;
vgem_device = drm_dev_alloc(&vgem_driver, NULL);
- if (IS_ERR(vgem_device)) {
- ret = PTR_ERR(vgem_device);
+ if (IS_ERR(vgem_device))
+ return PTR_ERR(vgem_device);
+
+ vgem_device->platformdev = platform_device_register_simple("vgem",
+ -1, NULL, 0);
+
+ if (!vgem_device->platformdev) {
+ ret = -ENODEV;
goto out;
}
+ dma_coerce_mask_and_coherent(&vgem_device->platformdev->dev,
+ DMA_BIT_MASK(64));
+
ret = drm_dev_register(vgem_device, 0);
if (ret)
goto out_unref;
@@ -347,13 +356,15 @@ static int __init vgem_init(void)
return 0;
out_unref:
- drm_dev_unref(vgem_device);
+ platform_device_unregister(vgem_device->platformdev);
out:
+ drm_dev_unref(vgem_device);
return ret;
}
static void __exit vgem_exit(void)
{
+ platform_device_unregister(vgem_device->platformdev);
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
}
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-02 17:02 [PATCHv3 0/3] dma_buf import support for vgem Laura Abbott
@ 2017-05-02 17:02 ` Laura Abbott
2017-05-02 17:02 ` Laura Abbott
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: Laura Abbott, dri-devel, linux-kernel, Sumit Semwal, intel-gfx,
Joonas Lahtinen
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
added for new function. Brought back drm_device->platformdev as it had been
removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
I'm not entirely thrilled about this since the platformdev removal was good
cleanup and this feels like a small step backwards. I don't know of a better
approach though.
---
drivers/gpu/drm/drm_prime.c | 49 +++++++++++++++++++++++++++++++++++----------
include/drm/drmP.h | 2 ++
include/drm/drm_prime.h | 4 ++++
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..a557a4b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
-/**
- * drm_gem_prime_import - helper library implementation of the import callback
- * @dev: drm_device to import into
- * @dma_buf: dma-buf object to import
- *
- * This is the implementation of the gem_prime_import functions for GEM drivers
- * using the PRIME helpers.
- */
-struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf)
+static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf,
+ struct device *attach_dev)
{
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
- attach = dma_buf_attach(dma_buf, dev->dev);
+ attach = dma_buf_attach(dma_buf, attach_dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
@@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
return ERR_PTR(ret);
}
+
+/**
+ * drm_gem_prime_import - helper library implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers.
+ */
+struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ return __drm_gem_prime_import(dev, dma_buf, dev->dev);
+}
EXPORT_SYMBOL(drm_gem_prime_import);
/**
+ * drm_gem_prime_import_platform - alternate implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is identical to drm_gem_prime_import except the device used for dma_buf
+ * attachment is an internal platform device instead of the standard device
+ * structure. The use of this function should be limited to drivers that do not
+ * set up an underlying device structure.
+ */
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ if (WARN_ON_ONCE(!dev->platformdev))
+ return NULL;
+
+ return __drm_gem_prime_import(dev, dma_buf, &dev->platformdev->dev);
+}
+EXPORT_SYMBOL(drm_gem_prime_import_platform);
+
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e1daa4f..086daee 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -439,6 +439,8 @@ struct drm_device {
struct pci_controller *hose;
#endif
+ /**< Platform device for drivers that do not use the standard device */
+ struct platform_device *platformdev;
struct virtio_device *virtdev;
struct drm_sg_mem *sg; /**< Scatter gather memory */
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 0b2a235..9fe39f8 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -65,6 +65,10 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
int *prime_fd);
struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+ struct dma_buf *dma_buf);
+
int drm_gem_prime_fd_to_handle(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd, uint32_t *handle);
struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
--
2.7.4
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-02 17:02 ` Laura Abbott
0 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: intel-gfx, Joonas Lahtinen, linux-kernel, dri-devel
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
added for new function. Brought back drm_device->platformdev as it had been
removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
I'm not entirely thrilled about this since the platformdev removal was good
cleanup and this feels like a small step backwards. I don't know of a better
approach though.
---
drivers/gpu/drm/drm_prime.c | 49 +++++++++++++++++++++++++++++++++++----------
include/drm/drmP.h | 2 ++
include/drm/drm_prime.h | 4 ++++
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..a557a4b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
-/**
- * drm_gem_prime_import - helper library implementation of the import callback
- * @dev: drm_device to import into
- * @dma_buf: dma-buf object to import
- *
- * This is the implementation of the gem_prime_import functions for GEM drivers
- * using the PRIME helpers.
- */
-struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf)
+static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf,
+ struct device *attach_dev)
{
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
- attach = dma_buf_attach(dma_buf, dev->dev);
+ attach = dma_buf_attach(dma_buf, attach_dev);
if (IS_ERR(attach))
return ERR_CAST(attach);
@@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
return ERR_PTR(ret);
}
+
+/**
+ * drm_gem_prime_import - helper library implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers.
+ */
+struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ return __drm_gem_prime_import(dev, dma_buf, dev->dev);
+}
EXPORT_SYMBOL(drm_gem_prime_import);
/**
+ * drm_gem_prime_import_platform - alternate implementation of the import callback
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is identical to drm_gem_prime_import except the device used for dma_buf
+ * attachment is an internal platform device instead of the standard device
+ * structure. The use of this function should be limited to drivers that do not
+ * set up an underlying device structure.
+ */
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ if (WARN_ON_ONCE(!dev->platformdev))
+ return NULL;
+
+ return __drm_gem_prime_import(dev, dma_buf, &dev->platformdev->dev);
+}
+EXPORT_SYMBOL(drm_gem_prime_import_platform);
+
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e1daa4f..086daee 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -439,6 +439,8 @@ struct drm_device {
struct pci_controller *hose;
#endif
+ /**< Platform device for drivers that do not use the standard device */
+ struct platform_device *platformdev;
struct virtio_device *virtdev;
struct drm_sg_mem *sg; /**< Scatter gather memory */
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 0b2a235..9fe39f8 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -65,6 +65,10 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
int *prime_fd);
struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
+
+struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
+ struct dma_buf *dma_buf);
+
int drm_gem_prime_fd_to_handle(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd, uint32_t *handle);
struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-02 17:02 ` Laura Abbott
@ 2017-05-02 20:22 ` Chris Wilson
-1 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2017-05-02 20:22 UTC (permalink / raw)
To: Laura Abbott
Cc: Daniel Vetter, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to attach using a platform device associated
> with drm_device.
>
> Cc: intel-gfx@lists.freedesktop.org
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
> added for new function. Brought back drm_device->platformdev as it had been
> removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
> I'm not entirely thrilled about this since the platformdev removal was good
> cleanup and this feels like a small step backwards. I don't know of a better
> approach though.
> ---
> drivers/gpu/drm/drm_prime.c | 49 +++++++++++++++++++++++++++++++++++----------
> include/drm/drmP.h | 2 ++
> include/drm/drm_prime.h | 4 ++++
> 3 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 9fb65b7..a557a4b 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
>
> -/**
> - * drm_gem_prime_import - helper library implementation of the import callback
> - * @dev: drm_device to import into
> - * @dma_buf: dma-buf object to import
> - *
> - * This is the implementation of the gem_prime_import functions for GEM drivers
> - * using the PRIME helpers.
> - */
> -struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> - struct dma_buf *dma_buf)
> +static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf,
> + struct device *attach_dev)
> {
> struct dma_buf_attachment *attach;
> struct sg_table *sgt;
> @@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> if (!dev->driver->gem_prime_import_sg_table)
> return ERR_PTR(-EINVAL);
>
> - attach = dma_buf_attach(dma_buf, dev->dev);
> + attach = dma_buf_attach(dma_buf, attach_dev);
> if (IS_ERR(attach))
> return ERR_CAST(attach);
>
> @@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
>
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_prime_import - helper library implementation of the import callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is the implementation of the gem_prime_import functions for GEM drivers
> + * using the PRIME helpers.
> + */
> +struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf)
> +{
> + return __drm_gem_prime_import(dev, dma_buf, dev->dev);
> +}
> EXPORT_SYMBOL(drm_gem_prime_import);
>
> /**
> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> + * attachment is an internal platform device instead of the standard device
> + * structure. The use of this function should be limited to drivers that do not
> + * set up an underlying device structure.
> + */
> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
Simpler soluation will be for the caller to provide the platformdev?
That works nicely for the vgem case, I think.
> + struct dma_buf *dma_buf)
> +{
> + if (WARN_ON_ONCE(!dev->platformdev))
> + return NULL;
> +
> + return __drm_gem_prime_import(dev, dma_buf, &dev->platformdev->dev);
> +}
> +EXPORT_SYMBOL(drm_gem_prime_import_platform);
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-02 20:22 ` Chris Wilson
0 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2017-05-02 20:22 UTC (permalink / raw)
To: Laura Abbott
Cc: Daniel Vetter, intel-gfx, Joonas Lahtinen, linux-kernel, dri-devel
On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> The existing drm_gem_prime_import function uses the underlying
> struct device of a drm_device for attaching to a dma_buf. Some drivers
> (notably vgem) may not have an underlying device structure. Offer
> an alternate function to attach using a platform device associated
> with drm_device.
>
> Cc: intel-gfx@lists.freedesktop.org
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
> added for new function. Brought back drm_device->platformdev as it had been
> removed in 76adb460fd93 ("drm: Remove the struct drm_device platformdev field").
> I'm not entirely thrilled about this since the platformdev removal was good
> cleanup and this feels like a small step backwards. I don't know of a better
> approach though.
> ---
> drivers/gpu/drm/drm_prime.c | 49 +++++++++++++++++++++++++++++++++++----------
> include/drm/drmP.h | 2 ++
> include/drm/drm_prime.h | 4 ++++
> 3 files changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 9fb65b7..a557a4b 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -594,16 +594,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
>
> -/**
> - * drm_gem_prime_import - helper library implementation of the import callback
> - * @dev: drm_device to import into
> - * @dma_buf: dma-buf object to import
> - *
> - * This is the implementation of the gem_prime_import functions for GEM drivers
> - * using the PRIME helpers.
> - */
> -struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> - struct dma_buf *dma_buf)
> +static struct drm_gem_object *__drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf,
> + struct device *attach_dev)
> {
> struct dma_buf_attachment *attach;
> struct sg_table *sgt;
> @@ -625,7 +618,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> if (!dev->driver->gem_prime_import_sg_table)
> return ERR_PTR(-EINVAL);
>
> - attach = dma_buf_attach(dma_buf, dev->dev);
> + attach = dma_buf_attach(dma_buf, attach_dev);
> if (IS_ERR(attach))
> return ERR_CAST(attach);
>
> @@ -655,9 +648,43 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
>
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_prime_import - helper library implementation of the import callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is the implementation of the gem_prime_import functions for GEM drivers
> + * using the PRIME helpers.
> + */
> +struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf)
> +{
> + return __drm_gem_prime_import(dev, dma_buf, dev->dev);
> +}
> EXPORT_SYMBOL(drm_gem_prime_import);
>
> /**
> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> + * @dev: drm_device to import into
> + * @dma_buf: dma-buf object to import
> + *
> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> + * attachment is an internal platform device instead of the standard device
> + * structure. The use of this function should be limited to drivers that do not
> + * set up an underlying device structure.
> + */
> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
Simpler soluation will be for the caller to provide the platformdev?
That works nicely for the vgem case, I think.
> + struct dma_buf *dma_buf)
> +{
> + if (WARN_ON_ONCE(!dev->platformdev))
> + return NULL;
> +
> + return __drm_gem_prime_import(dev, dma_buf, &dev->platformdev->dev);
> +}
> +EXPORT_SYMBOL(drm_gem_prime_import_platform);
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-02 20:22 ` Chris Wilson
@ 2017-05-03 7:39 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2017-05-03 7:39 UTC (permalink / raw)
To: Chris Wilson, Laura Abbott, Daniel Vetter, Sean Paul, dri-devel,
linux-kernel, Sumit Semwal, intel-gfx, Joonas Lahtinen
On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > /**
> > + * drm_gem_prime_import_platform - alternate implementation of the import callback
> > + * @dev: drm_device to import into
> > + * @dma_buf: dma-buf object to import
> > + *
> > + * This is identical to drm_gem_prime_import except the device used for dma_buf
> > + * attachment is an internal platform device instead of the standard device
> > + * structure. The use of this function should be limited to drivers that do not
> > + * set up an underlying device structure.
> > + */
> > +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
>
> Simpler soluation will be for the caller to provide the platformdev?
>
> That works nicely for the vgem case, I think.
Yeah looking at this again, do we really need this patch? Couldn't we
instead change patch 1 to first allocate the fake platform device, then
pass that to drm_dev_alloc (instead of NULL like we do now)?
That way no resurrection of drm_device.platform_dev is needed (and I'd
really like this zombie to stay dead on 2nd thought).
Sry about this yet-another-round review :-/
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-03 7:39 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2017-05-03 7:39 UTC (permalink / raw)
To: Chris Wilson, Laura Abbott, Daniel Vetter, Sean Paul, dri-devel,
linux-kernel, Sumit Semwal, intel-gfx, Joonas Lahtinen
On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > /**
> > + * drm_gem_prime_import_platform - alternate implementation of the import callback
> > + * @dev: drm_device to import into
> > + * @dma_buf: dma-buf object to import
> > + *
> > + * This is identical to drm_gem_prime_import except the device used for dma_buf
> > + * attachment is an internal platform device instead of the standard device
> > + * structure. The use of this function should be limited to drivers that do not
> > + * set up an underlying device structure.
> > + */
> > +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
>
> Simpler soluation will be for the caller to provide the platformdev?
>
> That works nicely for the vgem case, I think.
Yeah looking at this again, do we really need this patch? Couldn't we
instead change patch 1 to first allocate the fake platform device, then
pass that to drm_dev_alloc (instead of NULL like we do now)?
That way no resurrection of drm_device.platform_dev is needed (and I'd
really like this zombie to stay dead on 2nd thought).
Sry about this yet-another-round review :-/
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-03 7:39 ` Daniel Vetter
@ 2017-05-03 14:40 ` Laura Abbott
-1 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-03 14:40 UTC (permalink / raw)
To: Chris Wilson, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
>> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
>>> /**
>>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
>>> + * @dev: drm_device to import into
>>> + * @dma_buf: dma-buf object to import
>>> + *
>>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
>>> + * attachment is an internal platform device instead of the standard device
>>> + * structure. The use of this function should be limited to drivers that do not
>>> + * set up an underlying device structure.
>>> + */
>>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
>>
>> Simpler soluation will be for the caller to provide the platformdev?
>>
>> That works nicely for the vgem case, I think.
>
> Yeah looking at this again, do we really need this patch? Couldn't we
> instead change patch 1 to first allocate the fake platform device, then
> pass that to drm_dev_alloc (instead of NULL like we do now)?
>
That was what I proposed in the first version and it was rejected.
It's useful to have at least one driver with a NULL device for testing
edge cases.
> That way no resurrection of drm_device.platform_dev is needed (and I'd
> really like this zombie to stay dead on 2nd thought).
>
I had a hunch this would be unpopular but I figured it was worth a
shot. I think an even cleaner solution is to allow passing of any
struct device. I'll see about reworking this.
> Sry about this yet-another-round review :-/
> -Daniel
>
Thanks for your patience.
Laura
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-03 14:40 ` Laura Abbott
0 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-03 14:40 UTC (permalink / raw)
To: Chris Wilson, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
>> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
>>> /**
>>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
>>> + * @dev: drm_device to import into
>>> + * @dma_buf: dma-buf object to import
>>> + *
>>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
>>> + * attachment is an internal platform device instead of the standard device
>>> + * structure. The use of this function should be limited to drivers that do not
>>> + * set up an underlying device structure.
>>> + */
>>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
>>
>> Simpler soluation will be for the caller to provide the platformdev?
>>
>> That works nicely for the vgem case, I think.
>
> Yeah looking at this again, do we really need this patch? Couldn't we
> instead change patch 1 to first allocate the fake platform device, then
> pass that to drm_dev_alloc (instead of NULL like we do now)?
>
That was what I proposed in the first version and it was rejected.
It's useful to have at least one driver with a NULL device for testing
edge cases.
> That way no resurrection of drm_device.platform_dev is needed (and I'd
> really like this zombie to stay dead on 2nd thought).
>
I had a hunch this would be unpopular but I figured it was worth a
shot. I think an even cleaner solution is to allow passing of any
struct device. I'll see about reworking this.
> Sry about this yet-another-round review :-/
> -Daniel
>
Thanks for your patience.
Laura
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-03 14:40 ` Laura Abbott
@ 2017-05-03 15:07 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2017-05-03 15:07 UTC (permalink / raw)
To: Laura Abbott
Cc: Chris Wilson, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> >>> /**
> >>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> >>> + * @dev: drm_device to import into
> >>> + * @dma_buf: dma-buf object to import
> >>> + *
> >>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> >>> + * attachment is an internal platform device instead of the standard device
> >>> + * structure. The use of this function should be limited to drivers that do not
> >>> + * set up an underlying device structure.
> >>> + */
> >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
> >>
> >> Simpler soluation will be for the caller to provide the platformdev?
> >>
> >> That works nicely for the vgem case, I think.
> >
> > Yeah looking at this again, do we really need this patch? Couldn't we
> > instead change patch 1 to first allocate the fake platform device, then
> > pass that to drm_dev_alloc (instead of NULL like we do now)?
> >
>
> That was what I proposed in the first version and it was rejected.
> It's useful to have at least one driver with a NULL device for testing
> edge cases.
Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
no other driver than vgem using this. And now that we have vgem dma-buf
(or will, soonish) I'd expect that the same will hold for vkms, if it ever
happens.
-Daniel
> > That way no resurrection of drm_device.platform_dev is needed (and I'd
> > really like this zombie to stay dead on 2nd thought).
> >
>
> I had a hunch this would be unpopular but I figured it was worth a
> shot. I think an even cleaner solution is to allow passing of any
> struct device. I'll see about reworking this.
>
> > Sry about this yet-another-round review :-/
> > -Daniel
> >
>
> Thanks for your patience.
>
> Laura
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-03 15:07 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2017-05-03 15:07 UTC (permalink / raw)
To: Laura Abbott; +Cc: intel-gfx, Joonas Lahtinen, linux-kernel, dri-devel
On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> >>> /**
> >>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> >>> + * @dev: drm_device to import into
> >>> + * @dma_buf: dma-buf object to import
> >>> + *
> >>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> >>> + * attachment is an internal platform device instead of the standard device
> >>> + * structure. The use of this function should be limited to drivers that do not
> >>> + * set up an underlying device structure.
> >>> + */
> >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
> >>
> >> Simpler soluation will be for the caller to provide the platformdev?
> >>
> >> That works nicely for the vgem case, I think.
> >
> > Yeah looking at this again, do we really need this patch? Couldn't we
> > instead change patch 1 to first allocate the fake platform device, then
> > pass that to drm_dev_alloc (instead of NULL like we do now)?
> >
>
> That was what I proposed in the first version and it was rejected.
> It's useful to have at least one driver with a NULL device for testing
> edge cases.
Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
no other driver than vgem using this. And now that we have vgem dma-buf
(or will, soonish) I'd expect that the same will hold for vkms, if it ever
happens.
-Daniel
> > That way no resurrection of drm_device.platform_dev is needed (and I'd
> > really like this zombie to stay dead on 2nd thought).
> >
>
> I had a hunch this would be unpopular but I figured it was worth a
> shot. I think an even cleaner solution is to allow passing of any
> struct device. I'll see about reworking this.
>
> > Sry about this yet-another-round review :-/
> > -Daniel
> >
>
> Thanks for your patience.
>
> Laura
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
2017-05-03 15:07 ` Daniel Vetter
@ 2017-05-03 15:24 ` Chris Wilson
-1 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2017-05-03 15:24 UTC (permalink / raw)
To: Laura Abbott, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > >>> /**
> > >>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> > >>> + * @dev: drm_device to import into
> > >>> + * @dma_buf: dma-buf object to import
> > >>> + *
> > >>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> > >>> + * attachment is an internal platform device instead of the standard device
> > >>> + * structure. The use of this function should be limited to drivers that do not
> > >>> + * set up an underlying device structure.
> > >>> + */
> > >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
> > >>
> > >> Simpler soluation will be for the caller to provide the platformdev?
> > >>
> > >> That works nicely for the vgem case, I think.
> > >
> > > Yeah looking at this again, do we really need this patch? Couldn't we
> > > instead change patch 1 to first allocate the fake platform device, then
> > > pass that to drm_dev_alloc (instead of NULL like we do now)?
> > >
> >
> > That was what I proposed in the first version and it was rejected.
> > It's useful to have at least one driver with a NULL device for testing
> > edge cases.
>
> Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
> no other driver than vgem using this. And now that we have vgem dma-buf
> (or will, soonish) I'd expect that the same will hold for vkms, if it ever
> happens.
This series creates vgem->platformdev which we can just pass to
drm_gem_prime_import_platform() (or equivalent drm_gem_prime function that
takes an explicit dev). It was a bit of a surprise that import_platform
didn't take the platformdev after going to the trouble of creating
vgem->platformdev.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform
@ 2017-05-03 15:24 ` Chris Wilson
0 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2017-05-03 15:24 UTC (permalink / raw)
To: Laura Abbott, Sean Paul, dri-devel, linux-kernel, Sumit Semwal,
intel-gfx, Joonas Lahtinen
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote:
> > >>> /**
> > >>> + * drm_gem_prime_import_platform - alternate implementation of the import callback
> > >>> + * @dev: drm_device to import into
> > >>> + * @dma_buf: dma-buf object to import
> > >>> + *
> > >>> + * This is identical to drm_gem_prime_import except the device used for dma_buf
> > >>> + * attachment is an internal platform device instead of the standard device
> > >>> + * structure. The use of this function should be limited to drivers that do not
> > >>> + * set up an underlying device structure.
> > >>> + */
> > >>> +struct drm_gem_object *drm_gem_prime_import_platform(struct drm_device *dev,
> > >>
> > >> Simpler soluation will be for the caller to provide the platformdev?
> > >>
> > >> That works nicely for the vgem case, I think.
> > >
> > > Yeah looking at this again, do we really need this patch? Couldn't we
> > > instead change patch 1 to first allocate the fake platform device, then
> > > pass that to drm_dev_alloc (instead of NULL like we do now)?
> > >
> >
> > That was what I proposed in the first version and it was rejected.
> > It's useful to have at least one driver with a NULL device for testing
> > edge cases.
>
> Oh drat :( I'd say dropping the coverage for NULL testing is ok, there's
> no other driver than vgem using this. And now that we have vgem dma-buf
> (or will, soonish) I'd expect that the same will hold for vkms, if it ever
> happens.
This series creates vgem->platformdev which we can just pass to
drm_gem_prime_import_platform() (or equivalent drm_gem_prime function that
takes an explicit dev). It was a bit of a surprise that import_platform
didn't take the platformdev after going to the trouble of creating
vgem->platformdev.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCHv3 3/3] drm/vgem: Enable dmabuf import interfaces
2017-05-02 17:02 [PATCHv3 0/3] dma_buf import support for vgem Laura Abbott
@ 2017-05-02 17:02 ` Laura Abbott
2017-05-02 17:02 ` Laura Abbott
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: Laura Abbott, dri-devel, linux-kernel, Sumit Semwal, intel-gfx,
Joonas Lahtinen
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Minor fixes suggested by Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 133 +++++++++++++++++++++++++++++++---------
drivers/gpu/drm/vgem/vgem_drv.h | 2 +
2 files changed, 106 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 727eed2..c254c80 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -34,6 +34,9 @@
#include <linux/ramfs.h>
#include <linux/shmem_fs.h>
#include <linux/dma-buf.h>
+
+#include <drm/drmP.h>
+
#include "vgem_drv.h"
#define DRIVER_NAME "vgem"
@@ -46,6 +49,11 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
{
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
+ drm_free_large(vgem_obj->pages);
+
+ if (obj->import_attach)
+ drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
}
@@ -56,26 +64,49 @@ static int vgem_gem_fault(struct vm_fault *vmf)
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
- struct page *page;
-
- page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
- (vaddr - vma->vm_start) >> PAGE_SHIFT);
- if (!IS_ERR(page)) {
- vmf->page = page;
- return 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- return VM_FAULT_OOM;
- case -EBUSY:
- return VM_FAULT_RETRY;
- case -EFAULT:
- case -EINVAL:
- return VM_FAULT_SIGBUS;
- default:
- WARN_ON_ONCE(PTR_ERR(page));
- return VM_FAULT_SIGBUS;
+ int ret;
+ loff_t num_pages;
+ pgoff_t page_offset;
+ page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+
+ num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+ if (page_offset > num_pages)
+ return VM_FAULT_SIGBUS;
+
+ if (obj->pages) {
+ get_page(obj->pages[page_offset]);
+ vmf->page = obj->pages[page_offset];
+ ret = 0;
+ } else {
+ struct page *page;
+
+ page = shmem_read_mapping_page(
+ file_inode(obj->base.filp)->i_mapping,
+ page_offset);
+ if (!IS_ERR(page)) {
+ vmf->page = page;
+ ret = 0;
+ } else switch (PTR_ERR(page)) {
+ case -ENOSPC:
+ case -ENOMEM:
+ ret = VM_FAULT_OOM;
+ break;
+ case -EBUSY:
+ ret = VM_FAULT_RETRY;
+ break;
+ case -EFAULT:
+ case -EINVAL:
+ ret = VM_FAULT_SIGBUS;
+ break;
+ default:
+ WARN_ON(PTR_ERR(page));
+ ret = VM_FAULT_SIGBUS;
+ break;
+ }
+
}
+ return ret;
}
static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -112,12 +143,8 @@ static void vgem_postclose(struct drm_device *dev, struct drm_file *file)
kfree(vfile);
}
-/* ioctls */
-
-static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
- struct drm_file *file,
- unsigned int *handle,
- unsigned long size)
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+ unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -127,8 +154,31 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
- if (ret)
- goto err_free;
+ if (ret) {
+ kfree(obj);
+ return ERR_PTR(ret);
+ }
+
+ return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+ drm_gem_object_release(&obj->base);
+ kfree(obj);
+}
+
+static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ unsigned int *handle,
+ unsigned long size)
+{
+ struct drm_vgem_gem_object *obj;
+ int ret;
+
+ obj = __vgem_gem_create(dev, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->base, handle);
drm_gem_object_unreference_unlocked(&obj->base);
@@ -137,9 +187,8 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
return &obj->base;
-err_free:
- kfree(obj);
err:
+ __vgem_gem_destroy(obj);
return ERR_PTR(ret);
}
@@ -256,6 +305,29 @@ static struct sg_table *vgem_prime_get_sg_table(struct drm_gem_object *obj)
return st;
}
+static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device *dev,
+ struct dma_buf_attachment *attach, struct sg_table *sg)
+{
+ struct drm_vgem_gem_object *obj;
+ int npages;
+
+ obj = __vgem_gem_create(dev, attach->dmabuf->size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ npages = PAGE_ALIGN(attach->dmabuf->size) / PAGE_SIZE;
+
+ obj->table = sg;
+ obj->pages = drm_malloc_ab(npages, sizeof(struct page *));
+ if (!obj->pages) {
+ __vgem_gem_destroy(obj);
+ return ERR_PTR(-ENOMEM);
+ }
+ drm_prime_sg_to_page_addr_arrays(obj->table, obj->pages, NULL,
+ npages);
+ return &obj->base;
+}
+
static void *vgem_prime_vmap(struct drm_gem_object *obj)
{
long n_pages = obj->size >> PAGE_SHIFT;
@@ -314,8 +386,11 @@ static struct drm_driver vgem_driver = {
.dumb_map_offset = vgem_gem_dumb_map,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_pin = vgem_prime_pin,
+ .gem_prime_import = drm_gem_prime_import_platform,
.gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import_sg_table = vgem_prime_import_sg_table,
.gem_prime_get_sg_table = vgem_prime_get_sg_table,
.gem_prime_vmap = vgem_prime_vmap,
.gem_prime_vunmap = vgem_prime_vunmap,
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index cb59c7a..1aae014 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -43,6 +43,8 @@ struct vgem_file {
#define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
struct drm_vgem_gem_object {
struct drm_gem_object base;
+ struct page **pages;
+ struct sg_table *table;
};
int vgem_fence_open(struct vgem_file *file);
--
2.7.4
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCHv3 3/3] drm/vgem: Enable dmabuf import interfaces
@ 2017-05-02 17:02 ` Laura Abbott
0 siblings, 0 replies; 18+ messages in thread
From: Laura Abbott @ 2017-05-02 17:02 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson, Sean Paul
Cc: intel-gfx, Joonas Lahtinen, linux-kernel, dri-devel
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Minor fixes suggested by Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 133 +++++++++++++++++++++++++++++++---------
drivers/gpu/drm/vgem/vgem_drv.h | 2 +
2 files changed, 106 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 727eed2..c254c80 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -34,6 +34,9 @@
#include <linux/ramfs.h>
#include <linux/shmem_fs.h>
#include <linux/dma-buf.h>
+
+#include <drm/drmP.h>
+
#include "vgem_drv.h"
#define DRIVER_NAME "vgem"
@@ -46,6 +49,11 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
{
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
+ drm_free_large(vgem_obj->pages);
+
+ if (obj->import_attach)
+ drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
}
@@ -56,26 +64,49 @@ static int vgem_gem_fault(struct vm_fault *vmf)
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
- struct page *page;
-
- page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
- (vaddr - vma->vm_start) >> PAGE_SHIFT);
- if (!IS_ERR(page)) {
- vmf->page = page;
- return 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- return VM_FAULT_OOM;
- case -EBUSY:
- return VM_FAULT_RETRY;
- case -EFAULT:
- case -EINVAL:
- return VM_FAULT_SIGBUS;
- default:
- WARN_ON_ONCE(PTR_ERR(page));
- return VM_FAULT_SIGBUS;
+ int ret;
+ loff_t num_pages;
+ pgoff_t page_offset;
+ page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+
+ num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+ if (page_offset > num_pages)
+ return VM_FAULT_SIGBUS;
+
+ if (obj->pages) {
+ get_page(obj->pages[page_offset]);
+ vmf->page = obj->pages[page_offset];
+ ret = 0;
+ } else {
+ struct page *page;
+
+ page = shmem_read_mapping_page(
+ file_inode(obj->base.filp)->i_mapping,
+ page_offset);
+ if (!IS_ERR(page)) {
+ vmf->page = page;
+ ret = 0;
+ } else switch (PTR_ERR(page)) {
+ case -ENOSPC:
+ case -ENOMEM:
+ ret = VM_FAULT_OOM;
+ break;
+ case -EBUSY:
+ ret = VM_FAULT_RETRY;
+ break;
+ case -EFAULT:
+ case -EINVAL:
+ ret = VM_FAULT_SIGBUS;
+ break;
+ default:
+ WARN_ON(PTR_ERR(page));
+ ret = VM_FAULT_SIGBUS;
+ break;
+ }
+
}
+ return ret;
}
static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -112,12 +143,8 @@ static void vgem_postclose(struct drm_device *dev, struct drm_file *file)
kfree(vfile);
}
-/* ioctls */
-
-static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
- struct drm_file *file,
- unsigned int *handle,
- unsigned long size)
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+ unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -127,8 +154,31 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
- if (ret)
- goto err_free;
+ if (ret) {
+ kfree(obj);
+ return ERR_PTR(ret);
+ }
+
+ return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+ drm_gem_object_release(&obj->base);
+ kfree(obj);
+}
+
+static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ unsigned int *handle,
+ unsigned long size)
+{
+ struct drm_vgem_gem_object *obj;
+ int ret;
+
+ obj = __vgem_gem_create(dev, size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->base, handle);
drm_gem_object_unreference_unlocked(&obj->base);
@@ -137,9 +187,8 @@ static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
return &obj->base;
-err_free:
- kfree(obj);
err:
+ __vgem_gem_destroy(obj);
return ERR_PTR(ret);
}
@@ -256,6 +305,29 @@ static struct sg_table *vgem_prime_get_sg_table(struct drm_gem_object *obj)
return st;
}
+static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device *dev,
+ struct dma_buf_attachment *attach, struct sg_table *sg)
+{
+ struct drm_vgem_gem_object *obj;
+ int npages;
+
+ obj = __vgem_gem_create(dev, attach->dmabuf->size);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ npages = PAGE_ALIGN(attach->dmabuf->size) / PAGE_SIZE;
+
+ obj->table = sg;
+ obj->pages = drm_malloc_ab(npages, sizeof(struct page *));
+ if (!obj->pages) {
+ __vgem_gem_destroy(obj);
+ return ERR_PTR(-ENOMEM);
+ }
+ drm_prime_sg_to_page_addr_arrays(obj->table, obj->pages, NULL,
+ npages);
+ return &obj->base;
+}
+
static void *vgem_prime_vmap(struct drm_gem_object *obj)
{
long n_pages = obj->size >> PAGE_SHIFT;
@@ -314,8 +386,11 @@ static struct drm_driver vgem_driver = {
.dumb_map_offset = vgem_gem_dumb_map,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_pin = vgem_prime_pin,
+ .gem_prime_import = drm_gem_prime_import_platform,
.gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import_sg_table = vgem_prime_import_sg_table,
.gem_prime_get_sg_table = vgem_prime_get_sg_table,
.gem_prime_vmap = vgem_prime_vmap,
.gem_prime_vunmap = vgem_prime_vunmap,
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index cb59c7a..1aae014 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -43,6 +43,8 @@ struct vgem_file {
#define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
struct drm_vgem_gem_object {
struct drm_gem_object base;
+ struct page **pages;
+ struct sg_table *table;
};
int vgem_fence_open(struct vgem_file *file);
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* ✓ Fi.CI.BAT: success for dma_buf import support for vgem
2017-05-02 17:02 [PATCHv3 0/3] dma_buf import support for vgem Laura Abbott
` (2 preceding siblings ...)
2017-05-02 17:02 ` Laura Abbott
@ 2017-05-02 17:20 ` Patchwork
3 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2017-05-02 17:20 UTC (permalink / raw)
To: Laura Abbott; +Cc: intel-gfx
== Series Details ==
Series: dma_buf import support for vgem
URL : https://patchwork.freedesktop.org/series/23824/
State : success
== Summary ==
Series 23824v1 dma_buf import support for vgem
https://patchwork.freedesktop.org/api/1.0/series/23824/revisions/1/mbox/
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass -> DMESG-WARN (fi-bsw-n3050) fdo#100651
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651
fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:434s
fi-bdw-gvtdvm total:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:428s
fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:564s
fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:507s
fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time:542s
fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s
fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s
fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:404s
fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:412s
fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:493s
fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:466s
fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:460s
fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:565s
fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:456s
fi-skl-6700hq total:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:572s
fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:461s
fi-skl-6770hq total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:494s
fi-skl-gvtdvm total:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:430s
fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s
fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:405s
fi-byt-j1900 failed to collect. IGT log at Patchwork_4600/fi-byt-j1900/igt.log
310077224306c08a82476bb616de679715e83485 drm-tip: 2017y-05m-02d-12h-04m-57s UTC integration manifest
1377772 drm/vgem: Enable dmabuf import interfaces
6f7618d drm/prime: Introduce drm_gem_prime_import_platform
c510f33 drm/vgem: Add a dummy platform device
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4600/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread