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 a...@arndb.de Cc: Felipe Balbi ba...@ti.com applied, thanks -- 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 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 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
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
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 arch/.. asm/.. and plat/.. 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 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 arch/.. asm/.. and plat/.. 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 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 arch/.. asm/.. and plat/.. 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
