Re: [PATCH v3] drm: Use USB controller's DMA mask when importing dmabufs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 23.02.21 um 16:45 schrieb Alan Stern:
On Tue, Feb 23, 2021 at 12:19:56PM +0100, Greg KH wrote:
On Tue, Feb 23, 2021 at 11:58:42AM +0100, Thomas Zimmermann wrote:

--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -29,6 +29,7 @@
  #include <linux/export.h>
  #include <linux/dma-buf.h>
  #include <linux/rbtree.h>
+#include <linux/usb.h>

  #include <drm/drm.h>
  #include <drm/drm_drv.h>
@@ -1055,3 +1056,38 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
  	dma_buf_put(dma_buf);
  }
  EXPORT_SYMBOL(drm_prime_gem_destroy);
+
+/**
+ * drm_gem_prime_import_usb - helper library implementation of the import callback for USB devices
+ * @dev: drm_device to import into
+ * @dma_buf: dma-buf object to import
+ *
+ * This is an implementation of drm_gem_prime_import() for USB-based devices.
+ * USB devices cannot perform DMA directly. This function selects the USB host
+ * controller as DMA device instead. Drivers can use this as their
+ * &drm_driver.gem_prime_import implementation.
+ *
+ * See also drm_gem_prime_import().
+ */
+#ifdef CONFIG_USB
+struct drm_gem_object *drm_gem_prime_import_usb(struct drm_device *dev,
+						struct dma_buf *dma_buf)
+{
+	struct usb_device *udev;
+	struct device *usbhost;
+
+	if (dev->dev->bus != &usb_bus_type)
+		return ERR_PTR(-ENODEV);
+
+	udev = interface_to_usbdev(to_usb_interface(dev->dev));
+	if (!udev->bus)
+		return ERR_PTR(-ENODEV);
+
+	usbhost = udev->bus->controller;
+	if (!usbhost || !usbhost->dma_mask)
+		return ERR_PTR(-ENODEV);

Thomas, I doubt that you have to go through all of this.  The
usb-storage driver, for instance, just uses the equivalent of
dev->dev->dma_mask.  Even though USB devices don't do DMA themselves,
the DMA mask value is inherited from the parent host controller's device
struct.

Have you tried doing this?

But it's the field that is now NULL, isn't it? :S How does usb-storage get away with this?

Best regards
Thomas


If individual USB drivers need access to this type of thing, shouldn't
that be done in the USB core itself?

{hint, yes}

There shouldn't be anything "special" about a DRM driver that needs this
vs. any other driver that might want to know about DMA things related to
a specific USB device.  Why isn't this an issue with the existing
storage or v4l USB devices?

If Thomas finds that the approach I outlined above works, then the rest
of this email thread becomes moot.  :-)

Alan Stern
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux