From: Arnd Bergmann <arnd@arndb.de> To: Felipe Balbi <balbi@kernel.org> Cc: Peter Chen <hzpeterchen@gmail.com>, Leo Li <pku.leo@gmail.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Russell King - ARM Linux <linux@arm.linux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, Sekhar Nori <nsekhar@ti.com>, lkml <linux-kernel@vger.kernel.org>, Stuart Yoder <stuart.yoder@nxp.com>, Scott Wood <oss@buserror.net>, David Fisher <david.fisher1@synopsys.com>, "Thang Q. Nguyen" <tqnguyen@apm.com>, Alan Stern <stern@rowland.harvard.edu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Thu, 08 Sep 2016 13:39:58 +0200 [thread overview] Message-ID: <12394164.0mceYlJJBD@wuerfel> (raw) In-Reply-To: <871t0uiqn9.fsf@linux.intel.com> On Thursday, September 8, 2016 2:20:58 PM CEST Felipe Balbi wrote: > >> It's quite a hack, though. I still think that inheriting DMA (or > >> manually initializing a child with parent's DMA bits and pieces) is the > >> best way to go. So we're back to of_dma_configure() and > >> acpi_dma_configure(), right? > > > > That won't solve the problems with the DT properties or the > > dma configuration for PCI devices though. > > acpi_dma_configure() is supposed to pass along DMA bits from PCI to > child devices, no? I don't know, haven't looked at that code. > >> But this needs to be done before dwc3_probe() executes. For dwc3-pci > >> that's easy, but for DT devices, seems like it should be in of > >> core. Below is, clearly, not enough but should show the idea: > >> > >> diff --git a/drivers/of/device.c b/drivers/of/device.c > >> index fd5cfad7c403..a54610198946 100644 > >> --- a/drivers/of/device.c > >> +++ b/drivers/of/device.c > >> @@ -94,8 +94,12 @@ void of_dma_configure(struct device *dev, struct device_node *np) > >> * Set default coherent_dma_mask to 32 bit. Drivers are expected to > >> * setup the correct supported mask. > >> */ > >> - if (!dev->coherent_dma_mask) > >> - dev->coherent_dma_mask = DMA_BIT_MASK(32); > >> + if (!dev->coherent_dma_mask) { > >> + if (!dev->parent->coherent_dma_mask) > >> + dev->coherent_dma_mask = DMA_BIT_MASK(32); > >> + else > >> + dev->coherent_dma_mask = dev->parent->coherent_dma_mask; > >> + } > >> > > > > As the comment above that code says, the default 32-bit mask is intentional, > > and you need the driver to ask for the mask it wants using > > dma_set_mask_and_coherent(), while the platform code should be able to use > > dev->of_node to figure out whether that mask is supported. > > > > Just setting the initial mask to something else based on what the parent > > supports will not do the right thing elsewhere. > > oh man, it gets more and more complex. Seems like either path we take > will cause problems somewhere > > If we make dwc3.ko a library which glue calls directly then all these > problems are solved but we break all current DTs and fall into the trap > of having another MUSB. I don't see how we'd break the current DTs, I'm fairly sure we could turn dwc3 into a library without changing the DT representation. However the parts that I think would change are - The sysfs representation for dwc3-pci, as we would no longer have a parent-child relationship there. - The power management handling might need a rework, since you currently rely on the hierarchy between dwc3-pci, dwc3 and xhci for turning power on and off - turning dwc3 into a library probably implies also turning xhci into a library, in part for consistency. - if we don't do the whole usb_bus->sysdev thing, we need to not just do this for dwc3 but also chipidea and maybe a couple of others. There should not be any show-stoppers here, but it's a lot of work. > If we try to pass DMA bits from parent to child, then we have the fact > that DT ends up, in practice, always having a parent device. I don't understand what you mean here, but I agree that the various ways we discussed for copying the DMA flags from one 'struct device' to another all turned out to be flawed in at least one way. Do you see any problems with the patch I posted other than the ugliness of the dwc3 and xhci drivers finding out which pointer to use for usb_bus->sysdev? If we can solve this, we shouldn't need any new of_dma_configure/acpi_dma_configure calls and we won't have to turn the drivers into a library, so maybe let's try to come up with better ideas for that sub-problem. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Thu, 08 Sep 2016 13:39:58 +0200 [thread overview] Message-ID: <12394164.0mceYlJJBD@wuerfel> (raw) In-Reply-To: <871t0uiqn9.fsf@linux.intel.com> On Thursday, September 8, 2016 2:20:58 PM CEST Felipe Balbi wrote: > >> It's quite a hack, though. I still think that inheriting DMA (or > >> manually initializing a child with parent's DMA bits and pieces) is the > >> best way to go. So we're back to of_dma_configure() and > >> acpi_dma_configure(), right? > > > > That won't solve the problems with the DT properties or the > > dma configuration for PCI devices though. > > acpi_dma_configure() is supposed to pass along DMA bits from PCI to > child devices, no? I don't know, haven't looked at that code. > >> But this needs to be done before dwc3_probe() executes. For dwc3-pci > >> that's easy, but for DT devices, seems like it should be in of > >> core. Below is, clearly, not enough but should show the idea: > >> > >> diff --git a/drivers/of/device.c b/drivers/of/device.c > >> index fd5cfad7c403..a54610198946 100644 > >> --- a/drivers/of/device.c > >> +++ b/drivers/of/device.c > >> @@ -94,8 +94,12 @@ void of_dma_configure(struct device *dev, struct device_node *np) > >> * Set default coherent_dma_mask to 32 bit. Drivers are expected to > >> * setup the correct supported mask. > >> */ > >> - if (!dev->coherent_dma_mask) > >> - dev->coherent_dma_mask = DMA_BIT_MASK(32); > >> + if (!dev->coherent_dma_mask) { > >> + if (!dev->parent->coherent_dma_mask) > >> + dev->coherent_dma_mask = DMA_BIT_MASK(32); > >> + else > >> + dev->coherent_dma_mask = dev->parent->coherent_dma_mask; > >> + } > >> > > > > As the comment above that code says, the default 32-bit mask is intentional, > > and you need the driver to ask for the mask it wants using > > dma_set_mask_and_coherent(), while the platform code should be able to use > > dev->of_node to figure out whether that mask is supported. > > > > Just setting the initial mask to something else based on what the parent > > supports will not do the right thing elsewhere. > > oh man, it gets more and more complex. Seems like either path we take > will cause problems somewhere > > If we make dwc3.ko a library which glue calls directly then all these > problems are solved but we break all current DTs and fall into the trap > of having another MUSB. I don't see how we'd break the current DTs, I'm fairly sure we could turn dwc3 into a library without changing the DT representation. However the parts that I think would change are - The sysfs representation for dwc3-pci, as we would no longer have a parent-child relationship there. - The power management handling might need a rework, since you currently rely on the hierarchy between dwc3-pci, dwc3 and xhci for turning power on and off - turning dwc3 into a library probably implies also turning xhci into a library, in part for consistency. - if we don't do the whole usb_bus->sysdev thing, we need to not just do this for dwc3 but also chipidea and maybe a couple of others. There should not be any show-stoppers here, but it's a lot of work. > If we try to pass DMA bits from parent to child, then we have the fact > that DT ends up, in practice, always having a parent device. I don't understand what you mean here, but I agree that the various ways we discussed for copying the DMA flags from one 'struct device' to another all turned out to be flawed in at least one way. Do you see any problems with the patch I posted other than the ugliness of the dwc3 and xhci drivers finding out which pointer to use for usb_bus->sysdev? If we can solve this, we shouldn't need any new of_dma_configure/acpi_dma_configure calls and we won't have to turn the drivers into a library, so maybe let's try to come up with better ideas for that sub-problem. Arnd
next prev parent reply other threads:[~2016-09-08 11:40 UTC|newest] Thread overview: 182+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-25 19:21 [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Grygorii Strashko 2016-04-25 19:21 ` Grygorii Strashko 2016-04-26 6:17 ` Felipe Balbi 2016-04-26 6:17 ` Felipe Balbi 2016-04-26 8:14 ` Grygorii Strashko 2016-04-26 8:14 ` Grygorii Strashko 2016-04-27 5:41 ` Felipe Balbi 2016-04-27 5:41 ` Felipe Balbi 2016-04-27 11:55 ` Grygorii Strashko 2016-04-27 11:55 ` Grygorii Strashko 2016-04-27 13:59 ` Catalin Marinas 2016-04-27 13:59 ` Catalin Marinas 2016-04-27 14:11 ` Arnd Bergmann 2016-04-27 14:11 ` Arnd Bergmann 2016-04-27 15:50 ` Catalin Marinas 2016-04-27 15:50 ` Catalin Marinas 2016-04-27 16:04 ` Arnd Bergmann 2016-04-27 16:04 ` Arnd Bergmann 2016-04-27 16:53 ` Felipe Balbi 2016-04-27 16:53 ` Felipe Balbi 2016-04-27 17:42 ` Arnd Bergmann 2016-04-27 17:42 ` Arnd Bergmann 2016-04-27 17:59 ` Alan Stern 2016-04-27 17:59 ` Alan Stern 2016-04-27 18:08 ` Arnd Bergmann 2016-04-27 18:08 ` Arnd Bergmann 2016-04-27 20:05 ` Felipe Balbi 2016-04-27 20:05 ` Felipe Balbi 2016-04-27 21:05 ` Arnd Bergmann 2016-04-27 21:05 ` Arnd Bergmann 2016-04-28 6:37 ` Felipe Balbi 2016-04-28 6:37 ` Felipe Balbi 2016-04-28 14:16 ` Russell King - ARM Linux 2016-04-28 14:16 ` Russell King - ARM Linux 2016-04-28 14:23 ` Arnd Bergmann 2016-04-28 14:23 ` Arnd Bergmann 2016-04-28 14:27 ` Felipe Balbi 2016-04-28 14:27 ` Felipe Balbi 2016-09-01 22:14 ` Leo Li 2016-09-01 22:14 ` Leo Li 2016-09-02 10:43 ` Arnd Bergmann 2016-09-02 10:43 ` Arnd Bergmann 2016-09-02 10:47 ` Russell King - ARM Linux 2016-09-02 10:47 ` Russell King - ARM Linux 2016-09-02 11:08 ` Felipe Balbi 2016-09-02 11:08 ` Felipe Balbi 2016-09-02 14:11 ` Felipe Balbi 2016-09-02 14:11 ` Felipe Balbi 2016-09-02 14:21 ` Alan Stern 2016-09-02 14:21 ` Alan Stern 2016-09-02 15:51 ` Arnd Bergmann 2016-09-02 15:51 ` Arnd Bergmann 2016-09-07 7:17 ` Roger Quadros 2016-09-07 7:17 ` Roger Quadros 2016-09-07 8:29 ` Arnd Bergmann 2016-09-07 8:29 ` Arnd Bergmann 2016-09-07 13:04 ` Roger Quadros 2016-09-07 13:04 ` Roger Quadros 2016-09-07 14:38 ` Arnd Bergmann 2016-09-07 14:38 ` Arnd Bergmann 2016-09-02 16:23 ` Grygorii Strashko 2016-09-02 16:23 ` Grygorii Strashko 2016-09-02 10:53 ` Felipe Balbi 2016-09-02 10:53 ` Felipe Balbi 2016-09-02 11:55 ` Robin Murphy 2016-09-02 11:55 ` Robin Murphy 2016-09-02 12:56 ` Felipe Balbi 2016-09-02 12:56 ` Felipe Balbi 2016-09-02 13:10 ` Arnd Bergmann 2016-09-02 13:10 ` Arnd Bergmann 2016-09-02 22:16 ` Leo Li 2016-09-02 22:16 ` Leo Li 2016-09-05 15:39 ` Arnd Bergmann 2016-09-05 15:39 ` Arnd Bergmann 2016-09-06 6:35 ` Peter Chen 2016-09-06 6:35 ` Peter Chen 2016-09-06 6:40 ` Felipe Balbi 2016-09-06 6:40 ` Felipe Balbi 2016-09-06 10:46 ` Arnd Bergmann 2016-09-06 10:46 ` Arnd Bergmann 2016-09-06 10:50 ` Felipe Balbi 2016-09-06 10:50 ` Felipe Balbi 2016-09-06 13:27 ` Arnd Bergmann 2016-09-06 13:27 ` Arnd Bergmann 2016-09-07 6:51 ` Felipe Balbi 2016-09-07 6:51 ` Felipe Balbi 2016-09-07 7:44 ` Peter Chen 2016-09-07 7:44 ` Peter Chen 2016-09-07 8:52 ` Arnd Bergmann 2016-09-07 8:52 ` Arnd Bergmann 2016-09-07 9:29 ` Peter Chen 2016-09-07 9:29 ` Peter Chen 2016-09-07 9:35 ` Russell King - ARM Linux 2016-09-07 9:35 ` Russell King - ARM Linux 2016-09-07 10:18 ` Felipe Balbi 2016-09-07 10:18 ` Felipe Balbi 2016-09-06 10:38 ` Arnd Bergmann 2016-09-06 10:38 ` Arnd Bergmann 2016-09-07 6:33 ` Peter Chen 2016-09-07 6:33 ` Peter Chen 2016-09-07 8:48 ` Arnd Bergmann 2016-09-07 8:48 ` Arnd Bergmann 2016-09-07 9:55 ` Peter Chen 2016-09-07 9:55 ` Peter Chen 2016-09-07 10:33 ` Robin Murphy 2016-09-07 10:33 ` Robin Murphy 2016-09-07 10:47 ` Felipe Balbi 2016-09-07 10:47 ` Felipe Balbi 2016-09-14 16:31 ` Lorenzo Pieralisi 2016-09-14 16:31 ` Lorenzo Pieralisi 2016-09-14 21:50 ` Arnd Bergmann 2016-09-14 21:50 ` Arnd Bergmann 2016-09-07 10:24 ` Felipe Balbi 2016-09-07 10:24 ` Felipe Balbi 2016-09-07 15:24 ` Arnd Bergmann 2016-09-07 15:24 ` Arnd Bergmann 2016-09-07 16:08 ` Alan Stern 2016-09-07 16:08 ` Alan Stern 2016-09-07 19:45 ` Arnd Bergmann 2016-09-07 19:45 ` Arnd Bergmann 2016-09-08 1:15 ` Peter Chen 2016-09-08 1:15 ` Peter Chen 2016-09-08 8:02 ` Arnd Bergmann 2016-09-08 8:02 ` Arnd Bergmann 2016-09-08 8:03 ` Felipe Balbi 2016-09-08 8:03 ` Felipe Balbi 2016-09-08 8:26 ` Arnd Bergmann 2016-09-08 8:26 ` Arnd Bergmann 2016-09-08 8:29 ` Felipe Balbi 2016-09-08 8:29 ` Felipe Balbi 2016-09-08 8:45 ` Arnd Bergmann 2016-09-08 8:45 ` Arnd Bergmann 2016-09-08 9:43 ` Felipe Balbi 2016-09-08 9:43 ` Felipe Balbi 2016-09-08 10:17 ` Arnd Bergmann 2016-09-08 10:17 ` Arnd Bergmann 2016-09-08 11:00 ` Felipe Balbi 2016-09-08 11:00 ` Felipe Balbi 2016-09-08 11:11 ` Arnd Bergmann 2016-09-08 11:11 ` Arnd Bergmann 2016-09-08 11:20 ` Felipe Balbi 2016-09-08 11:20 ` Felipe Balbi 2016-09-08 11:39 ` Arnd Bergmann [this message] 2016-09-08 11:39 ` Arnd Bergmann 2016-09-08 11:52 ` Felipe Balbi 2016-09-08 11:52 ` Felipe Balbi 2016-09-08 12:46 ` Arnd Bergmann 2016-09-08 12:46 ` Arnd Bergmann 2016-09-08 12:02 ` Grygorii Strashko 2016-09-08 12:02 ` Grygorii Strashko 2016-09-08 12:14 ` Arnd Bergmann 2016-09-08 12:14 ` Arnd Bergmann 2016-09-08 12:28 ` Peter Chen 2016-09-08 12:28 ` Peter Chen 2016-09-08 12:52 ` Arnd Bergmann 2016-09-08 12:52 ` Arnd Bergmann 2016-09-09 1:37 ` Peter Chen 2016-09-09 1:37 ` Peter Chen 2016-09-08 12:59 ` Grygorii Strashko 2016-09-08 12:59 ` Grygorii Strashko 2016-09-09 1:52 ` Peter Chen 2016-09-09 1:52 ` Peter Chen 2016-09-21 11:06 ` Sriram Dash 2016-09-21 11:06 ` Sriram Dash 2016-09-21 11:31 ` Arnd Bergmann 2016-09-21 11:31 ` Arnd Bergmann 2016-09-21 11:43 ` Sriram Dash 2016-09-21 11:43 ` Sriram Dash 2016-09-21 12:48 ` Arnd Bergmann 2016-09-21 12:48 ` Arnd Bergmann 2016-09-22 5:02 ` Sriram Dash 2016-09-22 5:02 ` Sriram Dash 2016-10-07 22:46 ` Leo Li 2016-10-07 22:46 ` Leo Li 2016-09-21 17:14 ` [PATCH] usb: xhci: Fix the patch inherit dma configuration from kbuild test robot 2016-09-21 17:14 ` kbuild test robot 2016-04-27 20:57 ` [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Felipe Balbi 2016-04-27 20:57 ` Felipe Balbi 2016-04-27 14:14 ` Grygorii Strashko 2016-04-27 14:14 ` Grygorii Strashko 2016-05-05 17:07 ` Brian Norris 2016-05-05 17:07 ` Brian Norris
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=12394164.0mceYlJJBD@wuerfel \ --to=arnd@arndb.de \ --cc=balbi@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=david.fisher1@synopsys.com \ --cc=gregkh@linuxfoundation.org \ --cc=grygorii.strashko@ti.com \ --cc=hzpeterchen@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=nsekhar@ti.com \ --cc=oss@buserror.net \ --cc=pku.leo@gmail.com \ --cc=stern@rowland.harvard.edu \ --cc=stuart.yoder@nxp.com \ --cc=tqnguyen@apm.com \ --cc=yoshihiro.shimoda.uh@renesas.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.