From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757992AbcIHIcH (ORCPT ); Thu, 8 Sep 2016 04:32:07 -0400 Received: from mga02.intel.com ([134.134.136.20]:6265 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757394AbcIHI3t (ORCPT ); Thu, 8 Sep 2016 04:29:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,298,1470726000"; d="asc'?scan'208";a="1036954077" From: Felipe Balbi To: Arnd Bergmann Cc: Peter Chen , 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: <6739240.VDAnDBppH0@wuerfel> References: <3189648.KnWLgq0lTY@wuerfel> <8737lakedd.fsf@linux.intel.com> <6739240.VDAnDBppH0@wuerfel> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Thu, 08 Sep 2016 11:29:04 +0300 Message-ID: <87y432iylr.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, Arnd Bergmann writes: >> > @@ -178,7 +179,7 @@ static void dwc3_frame_length_adjustment(struct dw= c3 *dwc) >> > static void dwc3_free_one_event_buffer(struct dwc3 *dwc, >> > struct dwc3_event_buffer *evt) >> > { >> > - dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma); >> > + dma_free_coherent(dwc->sysdev, evt->length, evt->buf, evt->dma); >>=20 >> how about "dma_dev" instead? Is this used for anything other than DMA? > > The two other things we have discussed in this thread are: > > - connecting of_node pointers to usb_device structures for children > of sysdev->of_node. Note that this can happen even for PCI devices > in case you have a USB ethernet device hardwired to a PCI-USB bridge > and put the mac address in DT. > > - finding the PHY device for a HCD > > There might be others. Basically sysdev here is what the USB core code > can use for looking up any kind of properties provided by the firmware. fair enough >> > @@ -846,6 +847,13 @@ static int dwc3_probe(struct platform_device *pde= v) >> > dwc =3D PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); >> > dwc->mem =3D mem; >> > dwc->dev =3D dev; >> > +#ifdef CONFIG_PCI >> > + /* TODO: or some other way of detecting this? */ >> > + if (dwc->dev->parent && dwc->dev->parent->bus =3D=3D &pci_bus_type) >> > + dwc->sysdev =3D dwc->dev->parent; >> > + else >> > +#endif >> > + dwc->sysdev =3D dwc->dev; >>=20 >> Well, we can remove this ifdef and *always* use the parent. We will just >> require that dwc3 users provide a glue layer. In that case, your check >> becomes: >>=20 >> if (dwc->dev->parent) >> dwc->sysdev =3D dwc->dev->parent; >> else >> dev_info(dwc->dev, "Please provide a glue layer!\n"); > > If we do that, we have to put child devices of the dwc3 devices into > the platform glue, and it also breaks those dwc3 devices that don't > have a parent driver. Well, this is easy to fix: if (dwc->dev->parent) { dwc->sysdev =3D dwc->dev->parent; } else { dev_info(dwc->dev, "Please provide a glue layer!\n"); dwc->sysdev =3D dwc->dev; } >> > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c >> > index 89a2f712fdfe..4d7439cb8cd8 100644 >> > --- a/drivers/usb/dwc3/dwc3-st.c >> > +++ b/drivers/usb/dwc3/dwc3-st.c >> > @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *p= dev) >> > if (IS_ERR(regmap)) >> > return PTR_ERR(regmap); >> >=20=20 >> > - dma_set_coherent_mask(dev, dev->coherent_dma_mask); >>=20 >> so is this. >>=20 >> All in all, I like where you're going with this, we just need a matching >> acpi_dma_configure() and problems will be sorted out. > > With this patch, I don't think we even need that any more, as the device > that we use the dma-mapping API is the one that already gets configured > correctly by the platform code for all cases: PCI, OF, ACPI and combinati= ons > of those. sounds good to me =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX0SFQAAoJEMy+uJnhGpkGCCkQAK+uIXJSICb91sARCnadBPt9 IZf2g4bPQkiEaE1aNJa/J9N95vUOn2evMwf7tRvckwwdEhiQkRjlZrMUDws17e+1 NDyt0/aD3DUjUooCbr9ewn9Oi8pmGnKkoae9RGtPoiH6o3JXGg+AAfTdZzx35qWZ xcvYbnPq12y1FGo7SEwoJ3Ly+8Vl9VQFdr41Ok9mXvzWYxSbNWX2M0OsDgsabsAv 2xKzZYjKs9BZA3CqfxZDPyckLI0CDkLFwp0IT99Ux84tZ/20++JaxTxjhdgOnMIY 16NGmfrlR3GOsuXTuD3vBLX9dUNx2UHfx+VYUD9dJhe3y+uAgUzqE05iY5aUMJQN IVT9uxXpobh+WRGQ9NNeBHaLz932OufxWf6ORKRLJKV4OWQIleNQ0BQe4n4HsBvP LinankPBBut5jjsKTR6mVDgsU+PmbVtsOCoDrnhDK61srO5cYrAnxlfrRiYFEEcy BcSpFQ96HkmEwGi2koPgOJyHNrMrdIXQDS/onQ+Z0H1fDKE1oM1+nuo3VPUXMKqY jeRKb9Nz3cWhYN5NOwk9g8aAwmpF9ooDBH7cvBb+5Vcl1BsDe9RzgEJQihyuYNiJ 7AJJsXPAnC3h1Yo3OYrib1yqnq9ppM7QOcEFhijwyIPabHlKmXrjq8M3+hU4/zjM H/wkpCM7KEVcYR9OcdZN =1O3t -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Thu, 08 Sep 2016 11:29:04 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <6739240.VDAnDBppH0@wuerfel> References: <3189648.KnWLgq0lTY@wuerfel> <8737lakedd.fsf@linux.intel.com> <6739240.VDAnDBppH0@wuerfel> Message-ID: <87y432iylr.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd Bergmann writes: >> > @@ -178,7 +179,7 @@ static void dwc3_frame_length_adjustment(struct dwc3 *dwc) >> > static void dwc3_free_one_event_buffer(struct dwc3 *dwc, >> > struct dwc3_event_buffer *evt) >> > { >> > - dma_free_coherent(dwc->dev, evt->length, evt->buf, evt->dma); >> > + dma_free_coherent(dwc->sysdev, evt->length, evt->buf, evt->dma); >> >> how about "dma_dev" instead? Is this used for anything other than DMA? > > The two other things we have discussed in this thread are: > > - connecting of_node pointers to usb_device structures for children > of sysdev->of_node. Note that this can happen even for PCI devices > in case you have a USB ethernet device hardwired to a PCI-USB bridge > and put the mac address in DT. > > - finding the PHY device for a HCD > > There might be others. Basically sysdev here is what the USB core code > can use for looking up any kind of properties provided by the firmware. fair enough >> > @@ -846,6 +847,13 @@ static int dwc3_probe(struct platform_device *pdev) >> > dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); >> > dwc->mem = mem; >> > dwc->dev = dev; >> > +#ifdef CONFIG_PCI >> > + /* TODO: or some other way of detecting this? */ >> > + if (dwc->dev->parent && dwc->dev->parent->bus == &pci_bus_type) >> > + dwc->sysdev = dwc->dev->parent; >> > + else >> > +#endif >> > + dwc->sysdev = dwc->dev; >> >> Well, we can remove this ifdef and *always* use the parent. We will just >> require that dwc3 users provide a glue layer. In that case, your check >> becomes: >> >> if (dwc->dev->parent) >> dwc->sysdev = dwc->dev->parent; >> else >> dev_info(dwc->dev, "Please provide a glue layer!\n"); > > If we do that, we have to put child devices of the dwc3 devices into > the platform glue, and it also breaks those dwc3 devices that don't > have a parent driver. Well, this is easy to fix: if (dwc->dev->parent) { dwc->sysdev = dwc->dev->parent; } else { dev_info(dwc->dev, "Please provide a glue layer!\n"); dwc->sysdev = dwc->dev; } >> > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c >> > index 89a2f712fdfe..4d7439cb8cd8 100644 >> > --- a/drivers/usb/dwc3/dwc3-st.c >> > +++ b/drivers/usb/dwc3/dwc3-st.c >> > @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev) >> > if (IS_ERR(regmap)) >> > return PTR_ERR(regmap); >> > >> > - dma_set_coherent_mask(dev, dev->coherent_dma_mask); >> >> so is this. >> >> All in all, I like where you're going with this, we just need a matching >> acpi_dma_configure() and problems will be sorted out. > > With this patch, I don't think we even need that any more, as the device > that we use the dma-mapping API is the one that already gets configured > correctly by the platform code for all cases: PCI, OF, ACPI and combinations > of those. sounds good to me -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: