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

Thomas Zimmermann tzimmermann at suse.de
Wed Feb 24 06:02:23 UTC 2021


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 at lists.freedesktop.org
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210224/12885c80/attachment.sig>


More information about the dri-devel mailing list