From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB154C433DB for ; Thu, 25 Feb 2021 08:23:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7487264F0F for ; Thu, 25 Feb 2021 08:23:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235785AbhBYIXu (ORCPT ); Thu, 25 Feb 2021 03:23:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:37582 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235669AbhBYIXs (ORCPT ); Thu, 25 Feb 2021 03:23:48 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5E1D9ACE5; Thu, 25 Feb 2021 08:23:05 +0000 (UTC) Date: Thu, 25 Feb 2021 09:23:05 +0100 Message-ID: From: Takashi Iwai To: Thomas Zimmermann Cc: Alan Stern , airlied@linux.ie, gregkh@linuxfoundation.org, stable@vger.kernel.org, christian.koenig@amd.com, hdegoede@redhat.com, dri-devel@lists.freedesktop.org, sean@poorly.run, Christoph Hellwig Subject: Re: [PATCH v4] drm: Use USB controller's DMA mask when importing dmabufs In-Reply-To: References: <20210224092304.29932-1-tzimmermann@suse.de> <20210224152153.GA1307460@rowland.harvard.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, 25 Feb 2021 08:57:14 +0100, Thomas Zimmermann wrote: > > Hi > > Am 24.02.21 um 16:21 schrieb Alan Stern: > > On Wed, Feb 24, 2021 at 10:23:04AM +0100, Thomas Zimmermann wrote: > >> USB devices cannot perform DMA and hence have no dma_mask set in their > >> device structure. Therefore importing dmabuf into a USB-based driver > >> fails, which breaks joining and mirroring of display in X11. > >> > >> For USB devices, pick the associated USB controller as attachment device. > >> This allows the DRM import helpers to perform the DMA setup. If the DMA > >> controller does not support DMA transfers, we're out of luck and cannot > >> import. Our current USB-based DRM drivers don't use DMA, so the actual > >> DMA device is not important. > >> > >> Drivers should use DRM_GEM_SHMEM_DROVER_OPS_USB to initialize their > >> instance of struct drm_driver. > >> > >> Tested by joining/mirroring displays of udl and radeon un der Gnome/X11. > >> > >> v4: > >> * implement workaround with USB helper functions (Greg) > >> * use struct usb_device->bus->sysdev as DMA device (Takashi) > >> v3: > >> * drop gem_create_object > >> * use DMA mask of USB controller, if any (Daniel, Christian, Noralf) > >> v2: > >> * move fix to importer side (Christian, Daniel) > >> * update SHMEM and CMA helpers for new PRIME callbacks > >> > >> Signed-off-by: Thomas Zimmermann > >> Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices") > >> Cc: Christoph Hellwig > >> Cc: Greg Kroah-Hartman > >> Cc: # v5.10+ > >> --- > > > >> +struct drm_gem_object *drm_gem_prime_import_usb(struct drm_device *dev, > >> + struct dma_buf *dma_buf) > >> +{ > >> + struct usb_device *udev; > >> + struct device *dmadev; > >> + struct drm_gem_object *obj; > >> + > >> + if (!dev_is_usb(dev->dev)) > >> + return ERR_PTR(-ENODEV); > >> + udev = interface_to_usbdev(to_usb_interface(dev->dev)); > >> + > >> + dmadev = usb_get_dma_device(udev); > > > > You can do it this way if you want, but I think usb_get_dma_device would > > be easier to use if its argument was a pointer to struct usb_interface > > or (even better) a pointer to a usb_interface's embedded struct device. > > Then you wouldn't need to compute udev, and the same would be true for > > other callers. > > It seemed natural to me to use usb_device, because it contains the bus > pointer. But maybe a little wrapper for usb_interface in the header > file makes things easier to read. I'll wait a bit for other reviews to > come in. I agree with Thomas, as most of users referring to the sysdev do access in a pattern like udev->bus->sysdev, AFAIK. thanks, Takashi