From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754083AbcIBOLm (ORCPT ); Fri, 2 Sep 2016 10:11:42 -0400 Received: from mga03.intel.com ([134.134.136.65]:27438 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752847AbcIBOLk (ORCPT ); Fri, 2 Sep 2016 10:11:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,271,1470726000"; d="scan'208";a="756540290" From: Felipe Balbi To: Russell King - ARM Linux , Arnd Bergmann Cc: Leo Li , Grygorii Strashko , Catalin Marinas , Yoshihiro Shimoda , "linux-usb\@vger.kernel.org" , Sekhar Nori , lkml , David Fisher , "Thang Q. Nguyen" , Alan Stern , Greg Kroah-Hartman , "linux-arm-kernel\@lists.infradead.org" , Stuart Yoder , Scott Wood Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <87a8fq8spu.fsf@linux.intel.com> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> <20160902104707.GC1041@n2100.armlinux.org.uk> <87a8fq8spu.fsf@linux.intel.com> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.1 (x86_64-pc-linux-gnu) Date: Fri, 02 Sep 2016 17:11:11 +0300 Message-ID: <87bn0675og.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Felipe Balbi writes: > Hi, > > Russell King - ARM Linux writes: >> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote: >>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: >>> > >>> > Hi Felipe and Arnd, >>> > >>> > It has been a while since the last response to this discussion, but we >>> > haven't reached an agreement yet! Can we get to a conclusion on if it >>> > is valid to create child platform device for abstraction purpose? If >>> > yes, can this child device do DMA by itself? >>> >>> I'd say it's no problem for a driver to create child devices in order >>> to represent different aspects of a device, but you should not rely on >>> those devices working when used with the dma-mapping interfaces. >> >> That's absolutely right. Consider the USB model - only the USB host >> controller can perform DMA, not the USB devices themselves. All DMA >> mappings need to be mapped using the USB host controller device struct >> not the USB device struct. >> >> The same _should_ be true everywhere else: the struct device representing >> the device performing DMA must be the one used to map the transfer. > > How do we fix dwc3 in dual-role, then? > > Peripheral-side dwc3 is easy, we just require a glue-layer to be present > and use dwc3.ko's parent device (which will be the PCI device or OF > device). But for host side dwc3, the problem is slightly more complex > because we're using xhci-plat.ko by just instantiating a xhci-platform > device so xhci-plat can probe. > > xhci core has no means to know if its own device or the parent of its > parent should be used for DMA. Any ideas? another thing to consider is that dwc3 only works on omap because DT defaults to 32-bit DMA mask for anything described in DT that doesn't provide dma-ranges. Isn't that somewhat odd as well? Based on your reply, Russell, dwc3-omap should be the DMA device, but dwc3 works just as well because of the whole 32-bit default. -- balbi From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Fri, 02 Sep 2016 17:11:11 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <87a8fq8spu.fsf@linux.intel.com> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> <20160902104707.GC1041@n2100.armlinux.org.uk> <87a8fq8spu.fsf@linux.intel.com> Message-ID: <87bn0675og.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Felipe Balbi writes: > Hi, > > Russell King - ARM Linux writes: >> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote: >>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: >>> > >>> > Hi Felipe and Arnd, >>> > >>> > It has been a while since the last response to this discussion, but we >>> > haven't reached an agreement yet! Can we get to a conclusion on if it >>> > is valid to create child platform device for abstraction purpose? If >>> > yes, can this child device do DMA by itself? >>> >>> I'd say it's no problem for a driver to create child devices in order >>> to represent different aspects of a device, but you should not rely on >>> those devices working when used with the dma-mapping interfaces. >> >> That's absolutely right. Consider the USB model - only the USB host >> controller can perform DMA, not the USB devices themselves. All DMA >> mappings need to be mapped using the USB host controller device struct >> not the USB device struct. >> >> The same _should_ be true everywhere else: the struct device representing >> the device performing DMA must be the one used to map the transfer. > > How do we fix dwc3 in dual-role, then? > > Peripheral-side dwc3 is easy, we just require a glue-layer to be present > and use dwc3.ko's parent device (which will be the PCI device or OF > device). But for host side dwc3, the problem is slightly more complex > because we're using xhci-plat.ko by just instantiating a xhci-platform > device so xhci-plat can probe. > > xhci core has no means to know if its own device or the parent of its > parent should be used for DMA. Any ideas? another thing to consider is that dwc3 only works on omap because DT defaults to 32-bit DMA mask for anything described in DT that doesn't provide dma-ranges. Isn't that somewhat odd as well? Based on your reply, Russell, dwc3-omap should be the DMA device, but dwc3 works just as well because of the whole 32-bit default. -- balbi