From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755333AbcIFGmD (ORCPT ); Tue, 6 Sep 2016 02:42:03 -0400 Received: from mga04.intel.com ([192.55.52.120]:61321 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752218AbcIFGl7 (ORCPT ); Tue, 6 Sep 2016 02:41:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,290,1470726000"; d="asc'?scan'208";a="757527311" From: Felipe Balbi To: Peter Chen , Arnd Bergmann Cc: Leo Li , Grygorii Strashko , Russell King - ARM Linux , Catalin Marinas , Yoshihiro Shimoda , "linux-usb\@vger.kernel.org" , Sekhar Nori , lkml , Stuart Yoder , Scott Wood , David Fisher , "Thang Q. Nguyen" , Alan Stern , Greg Kroah-Hartman , "linux-arm-kernel\@lists.infradead.org" Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20160906063529.GA22312@b29397-desktop> References: <6414695.LEIYfGPUEg@wuerfel> <4865343.bOXkeC8XtQ@wuerfel> <20160906063529.GA22312@b29397-desktop> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Tue, 06 Sep 2016 09:40:19 +0300 Message-ID: <87bn01o7jg.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Peter Chen writes: > On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote: >> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote: >> >=20 >> > Can we use the firmware or bootloader information to provide the >> > default dma-mapping attributes for devices that doesn't have an >> > of_node pointer or ACPI data? This will at least restore what we had >> > previously provided . I'm concerned that changing all the drivers >> > that are creating child device will be a big effort. Like I mentioned >> > in another thread, there are many instances of platform_device_add() >> > under the drivers/ directory. >>=20 >> Fortunately, there are not too many drivers that call platform_device_add >> *and* try to set up a dma mask for the child device: >>=20 >> git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|r= egister\)' >>=20 >> drivers/base/platform.c >> drivers/bcma/main.c >> drivers/eisa/virtual_root.c >> drivers/mfd/mfd-core.c >> drivers/mfd/omap-usb-host.c >> drivers/misc/mic/card/mic_x100.c >> drivers/platform/goldfish/pdev_bus.c >> drivers/ssb/main.c >> drivers/usb/chipidea/core.c >> drivers/usb/dwc3/dwc3-exynos.c >> drivers/usb/dwc3/host.c >> drivers/usb/gadget/udc/bdc/bdc_pci.c >> drivers/usb/host/bcma-hcd.c >> drivers/usb/host/fsl-mph-dr-of.c >> drivers/usb/host/ssb-hcd.c >> drivers/usb/misc/ftdi-elan.c >> drivers/usb/musb/blackfin.c >> drivers/usb/musb/musb_dsps.c >> drivers/usb/musb/omap2430.c >> drivers/usb/musb/ux500.c >>=20 >> Most of these are probably never used with any nonstandard >> DMA settings (IOMMU, cache coherency, offset, ...). >>=20 >> One thing we could possibly do is to go through these and >> replace the hardcoded dma mask setup with of_dma_configure() >> in all cases in which we actually use DT for probing, which >> should cover the interesting cases. >>=20 > > One case I am going to work is to let USB chipidea driver support iommu, > the chipidea core device is no of_node, and created by > platform_add_device on the runtime. Using of_dma_configure with parent > of_node is a solution from my point, like [1]. > > https://lkml.org/lkml/2016/2/22/7 this only solves the problem for DT devices. Legacy devices and PCI-based systems will still suffer from the same problem. At least for dwc3, I will only be taking patches that solve the problem for all users, not a subset of them. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXzmTTAAoJEMy+uJnhGpkGqJwP/i/5R0JcYa1iZLOxWpIjOm0E /NuDo/y/M5i6K0H6YeCk05MSEM/hsFdoZ0r9wke0gqeeuBvRTe8XKYIagG+Ro4n4 jhHPiqfPlroZ1RZuJ0CgsN+HwrJVpmf+bzsxZpRZR0+Wsjz3UmNUREjlFBDLeEjI mBNRjenQh1O5nYgM9qHiWFu07O1pxkf+uYHG0OJmFXRJsgsa7vzkKb3k2ixrKl4T 6LFqxkth9ECQ2CqJKF5oUgUD/nzeOcuqGWsWCItDIUhQYraII1+N2Qw5E/73aTWf 0uhUqcU9QBwUr4wxQxMWNeyHc2SIFtJCvQxm/St/YOp1FerbRD59S2NoF0gzZ7xb yh3RyC3Kidrladg1w0MSje+vuLmbMGk3OdZdn7aSui2O7Fr7JbRVZ1gObVl/cC2f ZvxgA0TkDR9MPHg31S7yRBiijKrJQXwdFoRqb7b5q4WLjoGDMHvi8YbFt6t3grEz 7KR9PZM2wLDxLzIAF0sFRlO6LGTPFt6TF2MvFiAsoMg+DCUgq0VGWDkLudfTprW2 +kp9ExWEalHBEubFjHNPAG61ForX31xFbvh+V5dlU27xXL5m8THAwEThqorGGBUa X2bia8piN17bmzzF/Qvz31VQYyAQygJDx2E0KSXns1FaV8H6Z7yZTiwCdkeZbvDS NNY7HvU6KPI24ubvRq9U =Tn/5 -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Tue, 06 Sep 2016 09:40:19 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20160906063529.GA22312@b29397-desktop> References: <6414695.LEIYfGPUEg@wuerfel> <4865343.bOXkeC8XtQ@wuerfel> <20160906063529.GA22312@b29397-desktop> Message-ID: <87bn01o7jg.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Peter Chen writes: > On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote: >> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote: >> > >> > Can we use the firmware or bootloader information to provide the >> > default dma-mapping attributes for devices that doesn't have an >> > of_node pointer or ACPI data? This will at least restore what we had >> > previously provided . I'm concerned that changing all the drivers >> > that are creating child device will be a big effort. Like I mentioned >> > in another thread, there are many instances of platform_device_add() >> > under the drivers/ directory. >> >> Fortunately, there are not too many drivers that call platform_device_add >> *and* try to set up a dma mask for the child device: >> >> git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|register\)' >> >> drivers/base/platform.c >> drivers/bcma/main.c >> drivers/eisa/virtual_root.c >> drivers/mfd/mfd-core.c >> drivers/mfd/omap-usb-host.c >> drivers/misc/mic/card/mic_x100.c >> drivers/platform/goldfish/pdev_bus.c >> drivers/ssb/main.c >> drivers/usb/chipidea/core.c >> drivers/usb/dwc3/dwc3-exynos.c >> drivers/usb/dwc3/host.c >> drivers/usb/gadget/udc/bdc/bdc_pci.c >> drivers/usb/host/bcma-hcd.c >> drivers/usb/host/fsl-mph-dr-of.c >> drivers/usb/host/ssb-hcd.c >> drivers/usb/misc/ftdi-elan.c >> drivers/usb/musb/blackfin.c >> drivers/usb/musb/musb_dsps.c >> drivers/usb/musb/omap2430.c >> drivers/usb/musb/ux500.c >> >> Most of these are probably never used with any nonstandard >> DMA settings (IOMMU, cache coherency, offset, ...). >> >> One thing we could possibly do is to go through these and >> replace the hardcoded dma mask setup with of_dma_configure() >> in all cases in which we actually use DT for probing, which >> should cover the interesting cases. >> > > One case I am going to work is to let USB chipidea driver support iommu, > the chipidea core device is no of_node, and created by > platform_add_device on the runtime. Using of_dma_configure with parent > of_node is a solution from my point, like [1]. > > https://lkml.org/lkml/2016/2/22/7 this only solves the problem for DT devices. Legacy devices and PCI-based systems will still suffer from the same problem. At least for dwc3, I will only be taking patches that solve the problem for all users, not a subset of them. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: