Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > The logic to allow only one DMA driver in MUSB is currently > flawed, because it also allows picking no DMA driver at all > and also not selecting PIO mode. > > Using a choice statement makes this foolproof for now and > also simplifies the Makefile. > > Unfortunately, we will have to revisit this when we start > supporting multiple ARM platforms in a single kernel binary, > because at that point we will actually need to select > multiple DMA drivers and pick the right one at run-time. > > Signed-off-by: Arnd Bergmann > Cc: Felipe Balbi applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Mon, Oct 03, 2011 at 11:40:26AM +0200, Arnd Bergmann wrote: > On Monday 03 October 2011 01:10:51 Felipe Balbi wrote: > > Anyway, I'll take your patches in, but their too late for this merge > > window I already sent my last pull to Greg. > > No problem. I need the full set of arm-randconfig patches upstream in order > to make randconfig work in general, and that's not happening for 3.2 > anyway. Right now, I'm just trying to as many patches as possible into > maintainer trees. > > Is your tree part of linux-next, or will it only show up after the merge > window once Greg has pulled your first set for 3.3? My tree isn't in linux-next yet so my patches go to Greg and from there to -next. -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Monday 03 October 2011 01:10:51 Felipe Balbi wrote: > Anyway, I'll take your patches in, but their too late for this merge > window I already sent my last pull to Greg. No problem. I need the full set of arm-randconfig patches upstream in order to make randconfig work in general, and that's not happening for 3.2 anyway. Right now, I'm just trying to as many patches as possible into maintainer trees. Is your tree part of linux-next, or will it only show up after the merge window once Greg has pulled your first set for 3.3? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Sun, Oct 02, 2011 at 09:44:26PM +0200, Arnd Bergmann wrote: > > that's how MUSB works now and that's what I have been discussing with > > Alan Stern for the past month or so, wrt to *HCI. There are even patches > > floating on linux-usb right now trying to hash out the problems. > > Ah, glad to see that is happening. I can probably get rid of a bunch > of randconfig patches I have for those then. glad to hear you're sorting out randconfig :-) > > Maybe you should have consulted the maintainers of those drivers before > > making such statements. > > > > MUSB is not the best example because of its history. I understand the > > DMA part is still really messy, but we have been working very hard to > > hash the problems and still allow new glue layers to be merged. > > Sorry if I have made my statement sound like an accusation, it wasn't > meant as one, merely as a sigh at having identified yet another area > that needs to be changed in order to have cross-platform ARM kernels > working in every case. no big deal ;-) > > How about taking a sneak pick at what the code does right now ? As of > > today, I can even even have all UDC controller drivers into one kernel > > and I generally compile x86 with all controllers available. There's some > > very small work that has to be done on each of the UDC drivers to remove > > any references to and headers but that work > > in in progress. > > I didn't really see any problems with UDC at all. What I saw were a lot > of build problems with the musb host side, and I rewrote this patch half > a dozen times before I ended up with a version that consistently built > without making the code look worse. I understand. > I also agree that the musb implementation is less of a problem than > ohci/ehci in its current form, as it already is layered in the right > way. I did not attempt to turn the Kconfig 'choice' statement there > into a flat list though, so I wouldn't know what problems to expect. Actually, MUSB still has lots of goofage from the original mentor release but that's another story. Anyway, I'll take your patches in, but their too late for this merge window :-( I already sent my last pull to Greg. -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sunday 02 October 2011 21:56:09 Felipe Balbi wrote: > > > Unfortunately, even with the dma parts out of the way there is > > a lot that needs to be done to make musb, ehci or ohci > > really cross-platform. Right now, you can only have one > > platform driver glue for each of those drivers, and they > > that's not true for musb. I can already compile am35x and omap2430 > together. TUSB is a different story though. With a small effort, we > could also allow DaVinci and the like to compile cleanly and work. Ok, good. > > should eventually be converted to a large library module for > > the core, with independent platform driver front-end, similar > > that's how MUSB works now and that's what I have been discussing with > Alan Stern for the past month or so, wrt to *HCI. There are even patches > floating on linux-usb right now trying to hash out the problems. Ah, glad to see that is happening. I can probably get rid of a bunch of randconfig patches I have for those then. > Maybe you should have consulted the maintainers of those drivers before > making such statements. > > MUSB is not the best example because of its history. I understand the > DMA part is still really messy, but we have been working very hard to > hash the problems and still allow new glue layers to be merged. Sorry if I have made my statement sound like an accusation, it wasn't meant as one, merely as a sigh at having identified yet another area that needs to be changed in order to have cross-platform ARM kernels working in every case. > How about taking a sneak pick at what the code does right now ? As of > today, I can even even have all UDC controller drivers into one kernel > and I generally compile x86 with all controllers available. There's some > very small work that has to be done on each of the UDC drivers to remove > any references to and headers but that work > in in progress. I didn't really see any problems with UDC at all. What I saw were a lot of build problems with the musb host side, and I rewrote this patch half a dozen times before I ended up with a version that consistently built without making the code look worse. I also agree that the musb implementation is less of a problem than ohci/ehci in its current form, as it already is layered in the right way. I did not attempt to turn the Kconfig 'choice' statement there into a flat list though, so I wouldn't know what problems to expect. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Sun, Oct 02, 2011 at 08:00:31PM +0200, Arnd Bergmann wrote: > On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote: > > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > > > The logic to allow only one DMA driver in MUSB is currently > > > flawed, because it also allows picking no DMA driver at all > > > and also not selecting PIO mode. > > > > > > Using a choice statement makes this foolproof for now and > > > also simplifies the Makefile. > > > > > > Unfortunately, we will have to revisit this when we start > > > supporting multiple ARM platforms in a single kernel binary, > > > because at that point we will actually need to select > > > multiple DMA drivers and pick the right one at run-time. > > > > I thought there was some work going on to convert this to use the > > dmaengine stuff? > > That would certainly be the best solution here, I wasn't aware > that it has already been discussed. > > Unfortunately, even with the dma parts out of the way there is > a lot that needs to be done to make musb, ehci or ohci > really cross-platform. Right now, you can only have one > platform driver glue for each of those drivers, and they that's not true for musb. I can already compile am35x and omap2430 together. TUSB is a different story though. With a small effort, we could also allow DaVinci and the like to compile cleanly and work. > should eventually be converted to a large library module for > the core, with independent platform driver front-end, similar that's how MUSB works now and that's what I have been discussing with Alan Stern for the past month or so, wrt to *HCI. There are even patches floating on linux-usb right now trying to hash out the problems. Maybe you should have consulted the maintainers of those drivers before making such statements. MUSB is not the best example because of its history. I understand the DMA part is still really messy, but we have been working very hard to hash the problems and still allow new glue layers to be merged. How about taking a sneak pick at what the code does right now ? As of today, I can even even have *all* UDC controller drivers into one kernel and I generally compile x86 with all controllers available. There's some very small work that has to be done on each of the UDC drivers to remove any references to and headers but that work in in progress. Also, when sending USB patches, be sure to Cc linux-usb@vger where most of the discussion is happening. -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote: > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > > The logic to allow only one DMA driver in MUSB is currently > > flawed, because it also allows picking no DMA driver at all > > and also not selecting PIO mode. > > > > Using a choice statement makes this foolproof for now and > > also simplifies the Makefile. > > > > Unfortunately, we will have to revisit this when we start > > supporting multiple ARM platforms in a single kernel binary, > > because at that point we will actually need to select > > multiple DMA drivers and pick the right one at run-time. > > I thought there was some work going on to convert this to use the > dmaengine stuff? That would certainly be the best solution here, I wasn't aware that it has already been discussed. Unfortunately, even with the dma parts out of the way there is a lot that needs to be done to make musb, ehci or ohci really cross-platform. Right now, you can only have one platform driver glue for each of those drivers, and they should eventually be converted to a large library module for the core, with independent platform driver front-end, similar to the recent conversion of the sdhci driver by Shawn Guo, and the way that a lot of the other common drivers work. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > The logic to allow only one DMA driver in MUSB is currently > flawed, because it also allows picking no DMA driver at all > and also not selecting PIO mode. > > Using a choice statement makes this foolproof for now and > also simplifies the Makefile. > > Unfortunately, we will have to revisit this when we start > supporting multiple ARM platforms in a single kernel binary, > because at that point we will actually need to select > multiple DMA drivers and pick the right one at run-time. I thought there was some work going on to convert this to use the dmaengine stuff? But in any case, a stop-gap fix is needed for randconfig. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
The logic to allow only one DMA driver in MUSB is currently flawed, because it also allows picking no DMA driver at all and also not selecting PIO mode. Using a choice statement makes this foolproof for now and also simplifies the Makefile. Unfortunately, we will have to revisit this when we start supporting multiple ARM platforms in a single kernel binary, because at that point we will actually need to select multiple DMA drivers and pick the right one at run-time. Signed-off-by: Arnd Bergmann Cc: Felipe Balbi --- drivers/usb/musb/Kconfig | 57 ++-- drivers/usb/musb/Makefile | 26 +++- 2 files changed, 38 insertions(+), 45 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index fc34b8b..d596fb2 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -64,46 +64,57 @@ config USB_MUSB_UX500 endchoice -config MUSB_PIO_ONLY - bool 'Disable DMA (always use PIO)' - depends on USB_MUSB_HDRC - default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X +choice + prompt 'MUSB DMA mode' + default USB_UX500_DMA if USB_MUSB_UX500 + default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN + default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI + default USB_TUSB_OMAP_DMA if USB_MUSB_TUSB6010 + default MUSB_PIO_ONLY if USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X help - All data is copied between memory and FIFO by the CPU. - DMA controllers are ignored. - - Do not select 'n' here unless DMA support for your SOC or board - is unavailable (or unstable). When DMA is enabled at compile time, - you can still disable it at run time using the "use_dma=n" module - parameter. + Unfortunately, only one option can be enabled here. Ideally one + should be able to build all these drivers into one kernel to + allow using DMA on multiplatform kernels. config USB_UX500_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_UX500 + bool 'ST Ericsson U8500 and U5500' + depends on USB_MUSB_HDRC + depends on USB_MUSB_UX500 help Enable DMA transfers on UX500 platforms. config USB_INVENTRA_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN + bool 'Inventra' + depends on USB_MUSB_HDRC + depends on USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN help Enable DMA transfers using Mentor's engine. config USB_TI_CPPI_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_DAVINCI + bool 'TI CPPI (Davinci)' + depends on USB_MUSB_HDRC + depends on USB_MUSB_DAVINCI help Enable DMA transfers when TI CPPI DMA is available. config USB_TUSB_OMAP_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY + bool 'TUSB 6010' + depends on USB_MUSB_HDRC depends on USB_MUSB_TUSB6010 depends on ARCH_OMAP - default y help Enable DMA transfers on TUSB 6010 when OMAP DMA is available. +config MUSB_PIO_ONLY + bool 'Disable DMA (always use PIO)' + depends on USB_MUSB_HDRC + help + All data is copied between memory and FIFO by the CPU. + DMA controllers are ignored. + + Do not choose this unless DMA support for your SOC or board + is unavailable (or unstable). When DMA is enabled at compile time, + you can still disable it at run time using the "use_dma=n" module + parameter. + +endchoice diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..88bfb9d 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -24,25 +24,7 @@ obj-$(CONFIG_USB_MUSB_UX500) += ux500.o # PIO only, or DMA (several potential schemes). # though PIO is always there to back up DMA, and for ep0 -ifneq ($(CONFIG_MUSB_PIO_ONLY),y) - - ifeq ($(CONFIG_USB_INVENTRA_DMA),y) -musb_hdrc-y+= musbhsdma.o - - else -ifeq ($(CONFIG_USB_TI_CPPI_DMA),y) - musb_hdrc-y += cppi_dma.o - -else - ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y) - musb_hdrc-y += tusb6010_omap.o - - else -ifeq ($(CONFIG_USB_UX500_DMA),y) - musb_hdrc-y += ux500_dma.o - -endif - endif -endif - endif -endif +musb_hdrc-$(CONFIG_USB_INVENTRA_DMA) += musbhsdma.o +musb_hdrc-$(CONFIG_USB_TI_CPPI_DMA)+= cppi_dma.o +musb_hdrc-$(CONFIG_USB_TUSB_OMAP_DMA) += tusb6010_omap.o +musb_hdrc-$(CONFIG_USB_UX500_DMA) += ux500_dma.o -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at ht
