Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: +OMAP CONTROL USB + +Required properties: + - compatible: Should be ti,omap-control-usb + - reg : Address and length of the register set for the device. It contains + the address of control_dev_conf and otghs_control. + - reg-names: The names of the register addresses corresponding to the registers + filled in reg. + - ti,has_mailbox: This is used to specify if the platform uses mailbox in + control module. I wonder whether we need to have a phandle here to connect the control device to the actual usb device. What happens if you have multiple instances of each? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/7] usb: musb: add driver for control module
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote: Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Also added the dt data to get MUSB working in OMAP platforms. This series has patches for both drivers and ARCH folders, so If it has to be split I'll do it. The series looks good to me, I just had a minor comment on one patch. One a somewhat related topic, I wonder whether there are any plans on your side to change this driver to support multiple bus glues to be built for one kernel image. With a multiplatform kernel, we may need all of TUSB6010/OMAP2PLUS/DSPS/UX500 for instance. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/7] drivers: usb: phy: add a new driver for usb part of control module
On Tuesday 15 January 2013, kishon wrote: Good point :-). Currently, none of the OMAP platforms have multiple control modules and it doesn't seem to be in the future (AFAIK). While it might be simpler to support multiple control devices with phandle, it might face the same complications as faced by the USB PHY framework for non-dt boot. Maybe you can put the phandle into the binding then but don't use it until hardware actually requires it. If anything needs it, then we can always change the code later, but it's harder to change the binding. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
In linux-3.8-rc1 it became possible to build the imx and mvebu platforms together in a single kernel, which clashes in the ehci driver. Manjunath Goudar is already working on a patch to convert both the imx and the mvebu glue drivers (along with all the other ARM specific ones) to the new probing method, but that will be too late to fix v3.8. This patch instead adds yet another hack like the existing ones to allow the ehci driver to load both back-ends. Without this patch, building allyesconfig results in: drivers/usb/host/ehci-hcd.c:1285:0: error: PLATFORM_DRIVER redefined drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition In file included from drivers/usb/host/ehci-hcd.c:1254:0: drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org Cc: Manjunath Goudar manjunath.gou...@linaro.org Cc: Shawn Guo shawn@linaro.org Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Gregory Clement gregory.clem...@free-electrons.com --- drivers/usb/host/ehci-hcd.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c97503b..92e7180 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1282,7 +1282,7 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_PLAT_ORION #include ehci-orion.c -#definePLATFORM_DRIVER ehci_orion_driver +#defineORION_PLATFORM_DRIVER ehci_orion_driver #endif #ifdef CONFIG_USB_W90X900_EHCI @@ -1353,6 +1353,7 @@ MODULE_LICENSE (GPL); #if !IS_ENABLED(CONFIG_USB_EHCI_PCI) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) \ !defined(CONFIG_USB_CHIPIDEA_HOST) \ + !defined(ORION_PLATFORM_DRIVER) \ !defined(PLATFORM_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(OF_PLATFORM_DRIVER) \ @@ -1393,6 +1394,12 @@ static int __init ehci_hcd_init(void) goto clean0; #endif +#ifdef ORION_PLATFORM_DRIVER + retval = platform_driver_register(ORION_PLATFORM_DRIVER); + if (retval 0) + goto clean1; +#endif + #ifdef PS3_SYSTEM_BUS_DRIVER retval = ps3_ehci_driver_register(PS3_SYSTEM_BUS_DRIVER); if (retval 0) @@ -1424,6 +1431,10 @@ clean3: ps3_ehci_driver_unregister(PS3_SYSTEM_BUS_DRIVER); clean2: #endif +#ifdef ORION_PLATFORM_DRIVER + platform_driver_unregister(ORION_PLATFORM_DRIVER); +clean1: +#endif #ifdef PLATFORM_DRIVER platform_driver_unregister(PLATFORM_DRIVER); clean0: @@ -1446,6 +1457,9 @@ static void __exit ehci_hcd_cleanup(void) #ifdef OF_PLATFORM_DRIVER platform_driver_unregister(OF_PLATFORM_DRIVER); #endif +#ifdef ORION_PLATFORM_DRIVER + platform_driver_unregister(ORION_PLATFORM_DRIVER); +#endif #ifdef PLATFORM_DRIVER platform_driver_unregister(PLATFORM_DRIVER); #endif -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] ARM build regressions in v3.8
I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.
It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.
The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.
The same binutils update also broke the samsung
and w90x900 platforms.
A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.
Arnd
Arnd Bergmann (15):
ARM: compressed/head.S: work around new binutils warning
ARM: mvebu: build coherency_ll.S for arch=armv7-a
ARM: samsung: fix assembly syntax for new gas
ARM: w90x900: fix legacy assembly syntax
ASoC: fsl: fiq and dma cannot both be modules
clk: export __clk_get_name
drm/exynos: don't include plat/gpio-cfg.h
drm/exynos: fimd and ipp are broken on multiplatform
media: coda: don't build on multiplatform
mfd/vexpress: export vexpress_config_func_{put,get}
mtd: davinci_nand: fix OF support
USB: gadget/freescale: disable non-multiplatform drivers
USB: ehci: make orion and mxc bus glues coexist
samples/seccomp: be less stupid about cross compiling
staging/omapdrm: don't build on multiplatform
arch/arm/boot/compressed/Makefile|2 +-
arch/arm/boot/compressed/head.S | 12
arch/arm/mach-mvebu/coherency_ll.S |1 +
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++--
arch/arm/mach-s3c24xx/include/mach/entry-macro.S |4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S |2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++--
arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++--
arch/arm/mach-w90x900/include/mach/entry-macro.S |4 ++--
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +-
drivers/clk/clk.c|1 +
drivers/gpu/drm/exynos/Kconfig |4 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c |1 -
drivers/media/platform/Kconfig |2 +-
drivers/mfd/vexpress-config.c|3 ++-
drivers/mtd/nand/davinci_nand.c |2 +-
drivers/staging/omapdrm/Kconfig |2 +-
drivers/usb/gadget/Kconfig |3 ++-
drivers/usb/host/ehci-hcd.c | 16 +++-
samples/seccomp/Makefile |2 ++
sound/soc/fsl/Kconfig|3 +++
21 files changed, 76 insertions(+), 42 deletions(-)
--
1.7.10.4
Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: David Airlie airl...@linux.ie
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: James Morris james.l.mor...@oracle.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Rob Clark r...@ti.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Shawn Guo shawn@linaro.org
Cc: alsa-de...@alsa-project.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Monday 21 January 2013, Felipe Balbi wrote: On Mon, Jan 21, 2013 at 05:16:06PM +, Arnd Bergmann wrote: Manjunath Goudar is already working on a patch to convert both the imx and the mvebu glue drivers (along with all the other ARM specific ones) to the new probing method, but that will be too late to fix v3.8. This patch instead adds yet another hack like the existing ones to allow the ehci driver to load both back-ends. NAK, should be converted to the new usage of ehci library driver. Alan Stern already implemented for a few drivers, help is very welcome. As I explained above, Manjunath already has a patch [1] for that, but I think it's too late to include that in v3.8 given the regression potential and size of the patch. Once he submits that patch for 3.9, my change would get taken out anyway, but it lets us build important configurations (including allyesconfig build tests) on 3.8. Arnd [1] http://git.linaro.org/gitweb?p=people/manjunathgoudar/usb-refactoring.git;a=commitdiff;h=d9f28dba727212d022605c955796a3a83b3978ae -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
On Monday 21 January 2013, Greg Kroah-Hartman wrote: On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote: NAK, I prefer to see a real fix for the problem (which in fact is already in my fixes branch). I'll pull that branch now, sorry for the delay. Ok, great! Thanks a lot, both of you, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Monday 21 January 2013, Alan Stern wrote: On Mon, 21 Jan 2013, Felipe Balbi wrote: On Mon, Jan 21, 2013 at 05:16:06PM +, Arnd Bergmann wrote: In linux-3.8-rc1 it became possible to build the imx and mvebu platforms together in a single kernel, which clashes in the ehci driver. Manjunath Goudar is already working on a patch to convert both the imx and the mvebu glue drivers (along with all the other ARM specific ones) to the new probing method, but that will be too late to fix v3.8. This patch instead adds yet another hack like the existing ones to allow the ehci driver to load both back-ends. Pardon me for being confused. Is this about imx and mvebu (as mentioned here) or about orion and mxc (as described in the patch title, the error messages below, and the patch itself)? mxc is the old name for imx: the platform got removed, but some of the drivers still carry the old name. Similarly, orion was used before as the name for the superset of various Marvell platforms, and mvebu is the superset of that and some of the newer ones. Sorry for the confusion. Without this patch, building allyesconfig results in: drivers/usb/host/ehci-hcd.c:1285:0: error: PLATFORM_DRIVER redefined drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition In file included from drivers/usb/host/ehci-hcd.c:1254:0: drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used Was the point here to fix the build error or to allow the two drivers to coexist? The first would be eaiser than the second. Fixing the build error is probably the more important part here, but we also really want this to work, since people are migrating towards multiplatform kernels now, and mvebu/orion and imx/mxc are two of the more important ones. NAK, should be converted to the new usage of ehci library driver. Alan Stern already implemented for a few drivers, help is very welcome. Arnd, please take a look at http://marc.info/?l=linux-usbamp;m=135843716515529amp;w=2 I can't test it easily, not being set up for cross compilation. I'm waiting to hear from anybody whether it works before submitting it. (There's also a report of memory corruption involving a similar patch for ehci-omap; it hasn't been tracked down yet.) Your patch looks good to me, but it also seems to do some other changes that are not required to fix the problem but could wait for 3.9 instead. You definitely have my Ack if you are willing to take it for 3.8 though. Shawn or Sascha should be able to test it. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Monday 21 January 2013, Alan Stern wrote: Is Manjunath aware of the first patch attached to this email message? http://marc.info/?l=linux-usbamp;m=135843902916416amp;w=2 I would not expect so. Manjunath is still learning about the open source processes, but he has also done a similar patch in his tree, and one for most of the other ARM based platforms. Manjunath: following up on the discussions we've had, I would suggest you take a look at that patch, and do a comparison with your version (apply it on the same base, then use git-diff to show the differences between the version) and thing about whether your they are significant or not. Since Alan posted his version on the mailing list first, that's the one that should get merged, but there might be something in it that you can learn from it and that I did not see. Alan, one comment about your version: You keep maintaining the '#if IS_ENABLED' list in the main driver, which I think can actually get removed now. Since the base driver can be built independent of the presence of platform glue drivers, there is no need to forbid it any more, and the #if block will cause merge conflicts for each patch that converts or adds another platform. I think we can actually get the same results by turning the Kconfig logic around and making the platform glue drivers 'select USB_EHCI_HCD' than depending on it. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
On Tuesday 22 January 2013, Alan Stern wrote: In order to prevent this, you have to make sure that each glue driver depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround the Kconfig entries for those drivers with if USB USB_ARCH_HAS_EHCI ... endif. I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI as well once we have inverted the logic for selecting USB_EHCI_HCD, but there is another problem with that, because then we still need something to select USB_ARCH_HAS_HCD, or kill that symbol as well. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
On Monday 21 January 2013, Greg Kroah-Hartman wrote: On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote: Hi, On Mon, Jan 21, 2013 at 05:16:05PM +, Arnd Bergmann wrote: Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build without the mach/hardware.h file that is not available when building for multiplatform. Let's disable these drivers for v3.8 in combination with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless someone has an better solution. Without this patch, building allyesconfig results in: drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Shawn Guo shawn@linaro.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org NAK, I prefer to see a real fix for the problem (which in fact is already in my fixes branch). I'll pull that branch now, sorry for the delay. Apparently it hasn't made it into the upstream kernel yet, and it also doesn't seem to be in linux-next. Maybe this got lost while you were travelling? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
On Tuesday 05 February 2013, Felipe Balbi wrote: [linus/master] Merge branch 'fix-max-write' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm It's building find for me: $ crossmake drivers/usb/gadget/fsl_udc_core.o \ drivers/usb/gadget/fsl_mxc_udc.o /dev/null (crossmake is an alias to make ARCH=arm) Arnd, are you maybe missing a merge of v3.8-rc6 ? I can see that imx_udc.c is broken still, but there are no maintainers for that driver. I'm adding Sascha to Cc list, maybe he knows someone who can help, but if this driver isn't fixed in 2 merge windows, I will schedule for removal from tree and someone else will have to re-introduce it later without all the bogus includes. Ah, I see what happened now: I submitted a patch that lumped together two patches, disabling both fsl_mxc_udc and imx_udc. You already had a fix for the first one, so I dropped my patch, but now I see the build error for the second one that my patch was avoiding. The last patch to imx_udc that seems to have seen more than just build testing was probably USB: gadget: imx_udc: don't queue more data when zlp is to be sent, while fsl_mxc_udc looks actively maintained. It's not completely clear to me whether these are actually two drivers for the same hardware, of whether imx_udc is the i.mx1 variant and fsl_mxc_udc is the i.mx2 variant. What I can say is that no platform in the kernel currently defines an imx_udc platform_device, so it is certainly unused, and has been since at least e08300043e in 2010. I would suggest that we mark the imx_udc driver as 'depends on BROKEN' right away, since no in-tree user needs it, and any out of tree user is already broken in 3.8. I also wouldn't mind removing the driver unless the imx maintainers have a plan for it. build breaks --- sound/soc/fsl/imx-pcm.c: In function 'snd_imx_pcm_mmap': sound/soc/fsl/imx-pcm.c:28:2: error: 'KBUILD_MODNAME' undeclared (first use in this function) sound/soc/fsl/imx-pcm.c:28:2: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [sound/soc/fsl/imx-pcm.o] Error 1 drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div': drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function) drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1 Yes, I submitted patches for these, too, and like this case, we decided to drop my patch in favor of a better fix, which has not yet gone in. Today I sent emails about these as well, in the hope that we can find a solution. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: imx_udc: make it depend on BROKEN
On Wednesday 06 February 2013, Felipe Balbi wrote: that driver hasn't been maintained for quite some time, at least since e08300043e (ARM: imx: dynamically allocate imx_udc device). Because of that, and because driver doesn't even compile with allyesconfig and allmodconfig, we're making it depend on BROKEN. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Felipe Balbi ba...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Thanks for taking care of this! -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] USB: EHCI: make ehci-orion a separate driver
On Thursday 07 February 2013, manjunath.gou...@linaro.org wrote:
@@ -155,7 +155,7 @@ static inline unsigned ehci_read_frame_index(struct
ehci_hcd *ehci)
* before driver shutdown. But it also seems to be caused by bugs in cardbus
* bridge shutdown: shutting down the bridge before the devices using it.
*/
-static int handshake (struct ehci_hcd *ehci, void __iomem *ptr,
+int handshake(struct ehci_hcd *ehci, void __iomem *ptr,
u32 mask, u32 done, int usec)
{
u32 result;
I had not noticed this before, but apparently it belongs into the
tegra patch that you dropped, rather than this patch.
Same thing for all the changes below.
@@ -172,9 +172,9 @@ static int handshake (struct ehci_hcd *ehci, void __iomem
*ptr,
} while (usec 0);
return -ETIMEDOUT;
}
-
+EXPORT_SYMBOL_GPL(handshake);
/* check TDI/ARC silicon is in host mode */
-static int tdi_in_host_mode (struct ehci_hcd *ehci)
+static int tdi_in_host_mode(struct ehci_hcd *ehci)
{
u32 tmp;
@@ -186,7 +186,7 @@ static int tdi_in_host_mode (struct ehci_hcd *ehci)
* Force HC to halt state from unknown (EHCI spec section 2.3).
* Must be called with interrupts enabled and the lock not held.
*/
-static int ehci_halt (struct ehci_hcd *ehci)
+int ehci_halt(struct ehci_hcd *ehci)
{
u32 temp;
@@ -215,9 +215,9 @@ static int ehci_halt (struct ehci_hcd *ehci)
return handshake(ehci, ehci-regs-status,
STS_HALT, STS_HALT, 16 * 125);
}
-
+EXPORT_SYMBOL_GPL(ehci_halt);
/* put TDI/ARC silicon into EHCI mode */
-static void tdi_reset (struct ehci_hcd *ehci)
+void tdi_reset(struct ehci_hcd *ehci)
{
u32 tmp;
@@ -231,12 +231,12 @@ static void tdi_reset (struct ehci_hcd *ehci)
tmp |= USBMODE_BE;
ehci_writel(ehci, tmp, ehci-regs-usbmode);
}
-
+EXPORT_SYMBOL_GPL(tdi_reset);
/*
* Reset a non-running (STS_HALT == 1) controller.
* Must be called with interrupts enabled and the lock not held.
*/
-static int ehci_reset (struct ehci_hcd *ehci)
+int ehci_reset(struct ehci_hcd *ehci)
{
int retval;
u32 command = ehci_readl(ehci, ehci-regs-command);
@@ -272,7 +272,7 @@ static int ehci_reset (struct ehci_hcd *ehci)
ehci-resuming_ports = 0;
return retval;
}
-
+EXPORT_SYMBOL_GPL(ehci_reset);
/*
* Idle the controller (turn off the schedules).
* Must be called with interrupts enabled and the lock not held.
@@ -352,7 +352,7 @@ static void ehci_silence_controller(struct ehci_hcd *ehci)
* This forcibly disables dma and IRQs, helping kexec and other cases
* where the next system software may expect clean state.
*/
-static void ehci_shutdown(struct usb_hcd *hcd)
+void ehci_shutdown(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -366,7 +366,7 @@ static void ehci_shutdown(struct usb_hcd *hcd)
hrtimer_cancel(ehci-hrtimer);
}
-
+EXPORT_SYMBOL_GPL(ehci_shutdown);
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] usb: ehci: more bus glues as separate modules
On Monday 11 February 2013, manjunath.gou...@linaro.org wrote: From: Manjunath Goudar manjunath.gou...@linaro.org Separate the SOC On-Chip host controller driver from ehci-hcd host code into its own driver module Hi Manjunath, Please include in your next version of this a more verbose description of why this is all done, as Ezequiel Garcia suggested. It would also be helpful to have a list of the changes from the previous version here. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2 0/8] usb: ehci: more bus glues as separate modules
On Friday 15 February 2013, Manjunath Goudar wrote: Separate the SOC On-Chip host controller driver from ehci-hcd host code into its own driver module V2: Modified the patches, based on the first version review comments The series looks good to me now, great work! Please add my 'Acked-by: Arnd Bergmann a...@arndb.de' for each patch. Alan, Greg: I realize that it's too late to take the entire series for 3.9, but with the move of more ARM platforms to CONFIG_ARCH_MULTIPLATFORM, it is now possible to enable OMAP, VT8500 and ORION concurrently, along with the ones that are already moved out. You should have a patch for OMAP, but that has not made it into linux-next yet. It would be good to have at least two out the three I mentioned merged into 3.9, in order to keep allyesconfig building, and take the rest after the merge window, for integration into 3.10. What I get today with linux-next ARM allyesconfig is this: /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default] #define PLATFORM_DRIVER ehci_orion_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1257:0: note: this is the location of the previous definition #definePLATFORM_DRIVER ehci_hcd_omap_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default] #define PLATFORM_DRIVER vt8500_ehci_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition #define PLATFORM_DRIVER ehci_orion_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default] #define PLATFORM_DRIVER ehci_orion_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1257:0: note: this is the location of the previous definition #definePLATFORM_DRIVER ehci_hcd_omap_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default] #define PLATFORM_DRIVER vt8500_ehci_driver ^ /home/arnd/arm-soc/drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition #define PLATFORM_DRIVER ehci_orion_driver ^ In 3.10, we are going to need spear and s5p as well, possibly also atmel, mv and tegra, but Manjunath has done all the ARM platforms now (the tegra patch still has issues). Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2 0/8] usb: ehci: more bus glues as separate modules
On Friday 15 February 2013, Greg KH wrote: Alan, Greg: I realize that it's too late to take the entire series for 3.9, but with the move of more ARM platforms to CONFIG_ARCH_MULTIPLATFORM, it is now possible to enable OMAP, VT8500 and ORION concurrently, along with the ones that are already moved out. You should have a patch for OMAP, but that has not made it into linux-next yet. It would be good to have at least two out the three I mentioned merged into 3.9, in order to keep allyesconfig building, and take the rest after the merge window, for integration into 3.10. I have no idea what to do with ANY of these patches as they are all sent without proper changelog comments saying why they are needed, come in random series without proper ordering, get sent multiple times in the same series with no known differences between them, and probably other issues that I just don't even know about. So I can't take these this late in the development process, sorry, that would be negligent of me. Yes, as I said above I think we should only merge two of them for 3.9 in order to keep the bus glues that are now conflicting (omap, orion and vt8500) working when you enable all of the EHCI back-ends. These three are actually all pretty popular targets (vt8500 not yet so much, but it's used in some of the new sub-$100 tablets and HDMI stick computers), so I would actually expect that distros like Debin will want to enable them all together. The other patches are mainly there to solve the problem for all ARM platforms so we don't have to deal with them one by one as we make the remaining platforms multiplatform capable. Manjunath, please get this all working properly, as it is, I've deleted all of your patches from my to-apply queue for all of the above reasons. Sorry for the time this is causing you, I'm still teaching Manjunath how to follow all the processes and it took us a bit longer than expected to get this far. I'll try to make this less painful for you with the rest of the patches that should go into 3.10, and I'll send you the two patches that I'd like to still see in 3.9 with a proper changelog and in a form that applies on your usb-next branch. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like
drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous
definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but
not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-orion.c | 90 ---
4 files changed, 52 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d77e028..7ac6f48 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -162,6 +162,14 @@ config USB_EHCI_HCD_OMAP
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
+config USB_EHCI_HCD_ORION
+tristate Support for Marvell Orion on-chip EHCI USB controller
+depends on USB_EHCI_HCD PLAT_ORION
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Morvell Orion chips.
+
config USB_EHCI_HCD_VT8500
tristate Support for VT8500 on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_VT8500
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b0da9cf..4db3f01 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o
+obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 487ebb8..26154f0 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1272,11 +1272,6 @@ MODULE_LICENSE (GPL);
#define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver
#endif
-#ifdef CONFIG_PLAT_ORION
-#include ehci-orion.c
-#definePLATFORM_DRIVER ehci_orion_driver
-#endif
-
#ifdef CONFIG_USB_W90X900_EHCI
#include ehci-w90x900.c
#definePLATFORM_DRIVER ehci_hcd_w90x900_driver
@@ -1343,6 +1338,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!defined(PLATFORM_DRIVER) \
!IS_ENABLED(CONFIG_ARCH_VT8500) \
+ !IS_ENABLED(CONFIG_PLAT_ORION) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 914a3ec..cfc4803 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -17,6 +17,13 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_irq.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
+
+#include ehci.h
+
#define rdl(off) __raw_readl(hcd-regs + (off))
#define wrl(off, val) __raw_writel((val), hcd-regs + (off))
@@ -34,6 +41,17 @@
#define USB_PHY_IVREF_CTRL 0x440
#define USB_PHY_TST_GRP_CTRL 0x450
+#define DRIVER_DESC EHCI orion driver
+
+static const char hcd_name[] = ehci-orion;
+
+static struct hc_driver __read_mostly ehci_orion_hc_driver;
+
+static const struct ehci_driver_overrides orion_overrides __initdata = {
+ .reset = ehci_setup,
+};
+
+
/*
* Implement Orion USB controller specification guidelines
*/
@@ -104,51 +122,6 @@ static void orion_usb_phy_v1_setup(struct usb_hcd *hcd)
wrl(USB_MODE, 0x13);
}
-static const struct hc_driver ehci_orion_hc_driver = {
- .description = hcd_name,
- .product_desc = Marvell Orion EHCI,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
-* basic lifecycle operations
-*/
- .reset = ehci_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
-* managing i/o requests and associated
[PATCH 1/2] USB: EHCI: make ehci-vt8500 a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the vt8500 platform at the same time
as other platforms that require a conflicting EHCI bus
glue. At the moment, this results in a warning like
drivers/usb/host/ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1257:0: note: this is the location of the previous
definition
drivers/usb/host/ehci-omap.c:319:31: warning: 'ehci_hcd_omap_driver' defined
but not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the vt8500 bus glue.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Tony Prisk li...@prisktech.co.nz
Cc: Alexey Charkov alch...@gmail.com
---
drivers/usb/host/Kconfig | 8 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c| 6 +---
drivers/usb/host/ehci-vt8500.c | 73 +++---
4 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c59a112..d77e028 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -162,6 +162,14 @@ config USB_EHCI_HCD_OMAP
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
+config USB_EHCI_HCD_VT8500
+tristate Support for VT8500 on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_VT8500
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ VT8500 chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 001fbff..b0da9cf 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
+obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index b416a3f..487ebb8 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1292,11 +1292,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include ehci-vt8500.c
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include ehci-spear.c
#define PLATFORM_DRIVERspear_ehci_hcd_driver
@@ -1347,6 +1342,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) \
!IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!defined(PLATFORM_DRIVER) \
+ !IS_ENABLED(CONFIG_ARCH_VT8500) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
!defined(XILINX_OF_PLATFORM_DRIVER)
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index 11695d5..98d65bd 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,52 +16,25 @@
*
*/
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
#include linux/of.h
#include linux/platform_device.h
-static const struct hc_driver vt8500_ehci_hc_driver = {
- .description= hcd_name,
- .product_desc = VT8500 EHCI,
- .hcd_priv_size = sizeof(struct ehci_hcd),
+#include ehci.h
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
-* basic lifecycle operations
-*/
- .reset = ehci_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
+#define DRIVER_DESC vt8500 On-Chip EHCI Host driver
- /*
-* managing i/o requests and associated device resources
-*/
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
+static const char hcd_name[] = ehci-vt8500;
- /*
-* scheduling support
-*/
- .get_frame_number = ehci_get_frame,
+static struct hc_driver __read_mostly vt8500_ehci_hc_driver
[PATCH] USB: update host controller Kconfig entries
On Saturday 16 February 2013, Ezequiel Garcia wrote: s/Morvell/Marvell Just this tiny nitpick. Thanks for pointing this out! Tony Prisk had another comment about the VT8500 patch, so I figured it would be good to update both here, and I found a few more outdated changeset comments about drivers that have become used on more platforms now. Greg, please apply to whichever release you see fit. This is based on your current usb-next branch. Arnd 8--- Subject: USB: update host controller Kconfig entries The recent patches from Manjunath Goudar introduced two small mistakes in the Kconfig help text for the new options. Let's fix those and the other entries that have become stale over time. Signed-off-by: Arnd Bergmann a...@arndb.de --- drivers/usb/host/Kconfig | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 7ac6f48..245da35 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -163,23 +163,28 @@ config USB_EHCI_HCD_OMAP OMAP3 and later chips. config USB_EHCI_HCD_ORION -tristate Support for Marvell Orion on-chip EHCI USB controller +tristate Support for Marvell EBU on-chip EHCI USB controller depends on USB_EHCI_HCD PLAT_ORION default y ---help--- Enables support for the on-chip EHCI controller on - Morvell Orion chips. + Marvell's embedded ARM SoCs, including Orion, + Kirkwood, Dove, Armada XP, Armada 370. + This is different from the EHCI implementation on + Marvell's mobile PXA and MMP SoC, see USB_EHCI_MV + for those. + config USB_EHCI_HCD_VT8500 -tristate Support for VT8500 on-chip EHCI USB controller +tristate Support for VIA/Wondermedia on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_VT8500 default y ---help--- Enables support for the on-chip EHCI controller on - VT8500 chips. + VIA VT8500 and Wondermedia WM8x50 chips. config USB_EHCI_MSM - bool Support for MSM on-chip EHCI USB controller + bool Support for Qualcomm QSD/MSM on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_MSM select USB_EHCI_ROOT_HUB_TT select USB_MSM_OTG @@ -215,10 +220,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_S5P - boolean S5P EHCI support - depends on USB_EHCI_HCD PLAT_S5P - help -Enable support for the S5P SOC's on-chip EHCI controller. + boolean EHCI support for Samsung S5P/EXYNOS SoC Series + depends on USB_EHCI_HCD PLAT_S5P + help +Enable support for the Samsung S5P and Exynos3/4/5 SOC's +on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell on-chip controller @@ -228,6 +234,8 @@ config USB_EHCI_MV Enables support for Marvell (including PXA and MMP series) on-chip USB SPH and OTG controller. SPH is a single port host, and it can only be EHCI host. OTG is controller that can switch to host mode. + Note that there is a separate driver for Marvell's embedded ARM + SoCs, see USB_EHCI_HCD_ORION for those. config USB_W90X900_EHCI bool W90X900(W90P910) EHCI support -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On Monday 18 February 2013, Bo Shen wrote: - .name = atmel-ehci, + .name = hcd_name, This change will cause atmel ehci won't work with the none device tree kernel. it can be fixed with replace other places using atmel-ehci with hcd_name, that means replace atmel-ehci with ehci-atmel at other places. Ah, that is right. Thanks for pointing it out! Manjunath, please revert this change and ensure you are not changing the contents of the 'platform_driver-name' field in any of the drivers. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
On Tuesday 19 February 2013, Manjunath Goudar wrote: This is not necessary; ehci_setup is the default value anyway. This structure can be omitted. ehci_init_driver function we are passing orion_overrides,if we are removing above struct initialization, what should we need to pass in the ehci_init_driver function. ehci_init_driver already checks if you pass an override in there, and does not override anything in that case, so you can simply pass NULL as the argument. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, kishon wrote: On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the platform_device (or something else) that gets probed by its parent bus or the DT. The operations that you define for the PHY actually mirror some of the things that we have for a 'struct device', so I think it would be quite logical to do it the same way. Note that MDIO has both a 'bus' and a 'class', and what we want here is more like what the 'class' was meant for, except that for new classes, we should actually use a 'bus', since the long-term plan is to kill off the concept of a 'class'. I hope that was not too confusing. :) Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? We'd like the PHY drivers spread all over the kernel to get merged to drivers/phy including Ethernet. Having said that, Ethernet itself has a huge PHY framework and it's going to be little challenging to adapt to the new PHY framework (of course there'll be changes in this PHY framework when we want to have network PHY added here). But adapting USB PHYs to the new framework will be simpler and will be taken first. Also when we add SATA PHY (OMAP5), it will make use of this framework as both SATA and USB3 uses the same PHY IP. I think you need to have at least a concept of where you want to end up. It's totally fine to introduce a new subsystem that does only the minimum of what you need here, and add things as you go, but if you already plan to merge the existing mdio bus into this, you should really have an idea of what that will mean in the long run. I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Right. For now Ethernet should continue to use their own PHY abstraction layer till we are a bit more clear on how to move it to drivers/phy. Ok. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that one should be converted to a bus_type instead.
Also, you really should not need the global phy_list, phy_list_mutex
and phy_bind_list variables, since the driver core already provides
you with ways to iterate through devices on a class or bus.
+/**
+ * of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, const char *phandle, u8 index)
+{
+ struct phy *phy = NULL;
+ struct phy_bind *phy_map = NULL;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
I wonder whether this one should be of_parse_phandle_with_args() instead,
so you can have client-specific configuration in the property. Basically
instead of
phy = usbphy0 usbphy1;
you can pass an arbitrary number of arguments along with this, as
determined by some property in the phy node:
usbphy0: phy@1 {
#phy-cells = 1;
};
ehci@2 {
phy = usbphy0 23;
};
Which in turn leads to the argument (23) being passed into a phy_bind().
I also wonder if you should allow arbitrary names for the property.
Can't this always be called 'phy'? If you allow named phys, it would
more more consistent with other bindings to have a list of phy handles
in a property called phy, and a second property called phy-names
that contains the named strings.
+/**
+ * phy_create - create a new phy
+ * @dev: device that is creating the new phy
+ * @desc: descriptor of the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
+{
+ int ret;
+ struct phy *phy;
+ struct phy_bind *phy_bind;
+ const char *devname = NULL;
...
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy
+ * @poweron: powering on the phy
+ * @shutdown: shutting down the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+ int (*init)(struct phy_descriptor *desc);
+ int (*exit)(struct phy_descriptor *desc);
+ int (*suspend)(struct phy_descriptor *desc);
+ int (*resume)(struct phy_descriptor *desc);
+ int (*poweron)(struct phy_descriptor *desc);
+ int (*shutdown)(struct phy_descriptor *desc);
+ struct module *owner;
+};
Shouldn't these take the 'struct phy' as an argument? struct phy_descriptor is
not even based on a 'struct device'.
+struct phy {
+ struct device dev;
+ struct phy_descriptor *desc;
+ struct list_headhead;
+};
Please kill off the 'head' member here and use the infrastructure we
already have. The concept of the phy_descriptor seems even more foreign
here, so best just collapse that into 'struct phy'. Maybe also rename
the structure to 'phy_device'.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On Tuesday 19 February 2013, kishon wrote:
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
I thought if we are adding ethernet phys here (say drivers/phy/net), we
can make phy_device_create() (currently in drivers/net/phy/phy_device.c)
call phy_create with bus_type set to mdio_bus_type. Then we can have all
the PHYs showing up in /sys/class/phy/ and ethernet can continue to use
its own phy abstraction layer.
Hmm, that relies on the fact that mdio uses a 'bus_type' while the new phy
support uses a 'class', and it will break if we ever get to the point
where those two concepts are merged. I would rather not plan ahead here.
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
since while calling the callback functions using ops, there wont be
anyway to get back the device specific structure pointer.
struct phy_dev {
.
.
struct phy_descriptor desc;
void __iomem*base;
.
.
};
static int phy_resume(struct phy_descriptor *desc)
{
//if we dont pass a member of phy_dev while *phy_create* we can't get
back phy_dev from callback functions as used below.
struct phy_dev *phy = desc_to_omapusb(desc);
return 0;
}
static struct phy_ops ops = {
.resume = phy_resume,
.owner = THIS_MODULE,
};
In other subsystems, that is what the device-private_data pointer is used
for, which you could also pass to phy_create, or set after calling that
function.
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
Not sure I understood this point. Care to explain?
Nevermind, when I wrote that sentence, I had not yet noticed that the
phy_descriptor is kept around. I was thinking that the structure was
only used to pass more arguments into phy_create.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) it's not so simple :-) if we must use bus_type we need to introduce all the device/driver matching mechanism which isn't necessary with a class. I think the idea is to use a bus_type that has devices but no drivers associated with it, but I might be misremembering things. I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. right, but maybe we need another mechanism. If, in the long run we must use bus_type, then eventually pwm, led, regulators, etc will all be converted to bus_type. It will look quite weird IMHO. Yes, it would be a bit unusual, I agree. Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I believe for now, the idea is to not add any new classes, but keep the existing ones for compatibility. 'struct class_device' however was already removed and got turned into 'struct device'. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
On Wednesday 20 February 2013, Alan Stern wrote: Currently there is no Kconfig option to control specifically whether the ehci-orion driver gets built; it always gets built whenever CONFIG_PLAT_ORION and CONFIG_USB_EHCI_HCD are both enabled. Do you think it is a good idea to add an option for this? Should it at least be non-interactive, so that the driver always gets built under the same conditions as currently? A later patch can make it interactive, if desired. I think it's good to have it interactive, because we are now building for multiplatform with Orion being one of many. It's useful to be able to build EHCI_HCD=y AND EHCD_HCD_ORION=m. However, you are right that this is a change that was not mentioned in the patch description and would better have been kept separate or at least explicitly spelled out. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
On Wednesday 20 February 2013, Greg KH wrote: On Tue, Feb 19, 2013 at 08:24:38AM +0100, Andrew Lunn wrote: GregKH: Please can you drop this patch from usb-next. It breaks more than it fixes. I've now reverted both of these, and the follow-on patch that Arnd sent in. Arnd, sorry, but please be more careful, especially when you ask for patches to be rushed into the tree... Yes, I understand. I'll try to come up with a less invasive way to deal with the build error in 3.9 once the ARM multiplatform branch gets pulled. I guess we could either forbid the combinations that are now broken using Kconfig dependencies, or add just add separate registriation paths to ehci_hcd_init() and ehci_hcd_cleanup() as we have for powerpc, although Alan did not like that too much last time I suggested it. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On Friday 08 March 2013, Stephen Warren wrote: Yes, I think it should instead work like: ARCH_TEGRA* selects nothing in particular related to USB. The Tegra EHCI controller Kconfig depends on ARCH_TEGRA so it doesn't show up for other builds. Yes, that's fine. I hope it's OK for the EHCI controller to select USB_ARCH_HAS_EHCI? I think that would create a circular dependency, which Kconfig will refuse. We talked about the USB_ARCH_HAS_* Kconfig symbols recently and Alan Stern agreed to my suggestion of removing all of them, reworking the logic so we can always enable USB and EHCI but even when there is no bus glue enabled. I'll have to do a proper patch one of these days, or find someone in my team to do it right for all the corner cases. The Tegra PHY Kconfig probably shouldn't be user-visible (relying on being selected by the Tegra EHCI controller) and itself selects anything it relies on. Does that sound reasonable? It is often safer to express the logic using depends on than using select, e.g. doing config USB_EHCI_TEGRA bool EHCI support for NVIDIA Tegra depends on USB_EHCI_HCD depends on ARCH_TEGRA config USB_ULPI_VIEWPORT def_bool y depends on USB_EHCI_TEGRA If USB_ULPI_VIEWPORT has any other dependencies, the best solution in the above scenario is to make USB_EHCI_TEGRA depend on those. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On Friday 08 March 2013, Stephen Warren wrote: config USB_ULPI_VIEWPORT def_bool y depends on USB_EHCI_TEGRA If USB_ULPI_VIEWPORT has any other dependencies, the best solution in the above scenario is to make USB_EHCI_TEGRA depend on those. USB_ULPI_VIEWPORT is, AFAIK, a generic piece of infra-structure that USB_EHCI_TEGRA depends upon. Sorry, I was probably confusing the symbol names. I meant whatever you were going to select from USB_EHCI_TEGRA. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
A number of ARM platforms were changed in linux-3.9 so they can be enabled
at a single kernel configuration. Unfortunately, the necessary changes for
the EHCI driver were not ready in time and the first attempt to split out
the EHCI bus glues into separate modules had to get reverted before the
merge window.
This means we are still stuck with a situation where enabling any
combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
platforms at the same time leaves us with an EHCI driver that does
not work properly and spits out this build warning:
ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
In file included from ehci-hcd.c:1256:0:
ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used
[-Wunused-variable]
In file included from ehci-hcd.c:1276:0:
ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used
[-Wunused-variable]
ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
This is the simplest patch I could come up with that will restore some
sanity in multiplatform configuration and allow us to build an ARM
allyesconfig kernel. Disallowing the broken configuration in Kconfig
would actually end up in a larger patch and more regression potential
than this one.
We had a similar situation in 3.8 with a conflict between Orion and MXC,
and Alan Stern objected to the simple hack back then and instead provided
a better full conversion of the MXC backend in patch dba63b2f7. A proper
patch for OMAP was submitted in January but also did not make it into 3.9,
see https://patchwork.kernel.org/patch/2055131.
I expect that for 3.10 we will be able to do this correctly and
turn all ARM bus glues into separate modules, ripping out the
code that this patch changes.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Roger Quadros rog...@ti.com
Cc: Andrew Lunn and...@lunn.ch
CC: Jason Cooper ja...@lakedaemon.net
---
drivers/usb/host/ehci-hcd.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index dd1d41d..c750d71 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1254,7 +1254,7 @@ MODULE_LICENSE (GPL);
#ifdef CONFIG_USB_EHCI_HCD_OMAP
#include ehci-omap.c
-#definePLATFORM_DRIVER ehci_hcd_omap_driver
+#defineOMAP_PLATFORM_DRIVERehci_hcd_omap_driver
#endif
#ifdef CONFIG_PPC_PS3
@@ -1274,7 +1274,7 @@ MODULE_LICENSE (GPL);
#ifdef CONFIG_PLAT_ORION
#include ehci-orion.c
-#definePLATFORM_DRIVER ehci_orion_driver
+#defineORION_PLATFORM_DRIVER ehci_orion_driver
#endif
#ifdef CONFIG_USB_W90X900_EHCI
@@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void)
if (retval 0)
goto clean4;
#endif
+
+#ifdef OMAP_PLATFORM_DRIVER
+ retval = platform_driver_register(OMAP_PLATFORM_DRIVER);
+ if (retval 0)
+ goto clean5;
+#endif
return retval;
+#ifdef OMAP_PLATFORM_DRIVER
+ /* platform_driver_unregister(OMAP_PLATFORM_DRIVER); */
+clean5:
+#endif
#ifdef XILINX_OF_PLATFORM_DRIVER
- /* platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER); */
+ platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER);
clean4:
#endif
#ifdef OF_PLATFORM_DRIVER
@@ -1423,6 +1433,10 @@ clean3:
ps3_ehci_driver_unregister(PS3_SYSTEM_BUS_DRIVER);
clean2:
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ platform_driver_unregister(ORION_PLATFORM_DRIVER);
+clean1:
+#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
clean0:
@@ -1439,12 +1453,18 @@ module_init(ehci_hcd_init);
static void __exit ehci_hcd_cleanup(void)
{
+#ifdef OMAP_PLATFORM_DRIVER
+ platform_driver_unregister(OMAP_PLATFORM_DRIVER);
+#endif
#ifdef XILINX_OF_PLATFORM_DRIVER
platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER);
#endif
#ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(OF_PLATFORM_DRIVER);
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ platform_driver_unregister(ORION_PLATFORM_DRIVER);
+#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Friday 15 March 2013, Arnd Bergmann wrote: @@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void) if (retval 0) goto clean4; #endif + +#ifdef OMAP_PLATFORM_DRIVER + retval = platform_driver_register(OMAP_PLATFORM_DRIVER); + if (retval 0) + goto clean5; +#endif There was a missing hunk for the ORION part like the one above since I unfortunately had done this patch on the wrong base. I will resubmit a proper patch if we get an agreement on the approach taken. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Friday 15 March 2013, Alan Stern wrote:
On Fri, 15 Mar 2013, Arnd Bergmann wrote:
@@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device
*dev)
return -ENXIO;
}
- if (pdata-power_on) {
+ if (pdata pdata-power_on) {
err = pdata-power_on(dev);
if (err 0)
return err;
}
Instead of adding these tests for non-NULL pdata all over the place,
you could define a static structure with default settings and store a
pointer to it if pdata wasn't set initially.
Yes, good idea. Here is a new version. Maybe Alexey or Tony can verify if
that works for them on wm8850. That should be independent of the decision
into which kernel to merge this patch.
Arnd
8--
From 016f7ecd1bce61c18d621acf746776491cc8487e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Fri, 15 Feb 2013 23:12:28 +0100
Subject: [PATCH] USB: EHCI: DT support for generic bus glue
This lets us use the ehci-generic driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Tony Prisk li...@prisktech.co.nz
Cc: Alexey Charkov alch...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-platform.c | 25 +++--
drivers/usb/host/ehci-vt8500.c | 150 ---
3 files changed, 19 insertions(+), 161 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c750d71..9dfcef6 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1292,11 +1292,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include ehci-vt8500.c
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include ehci-spear.c
#define PLATFORM_DRIVERspear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..eaf 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/kernel.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -62,22 +64,26 @@ static const struct ehci_driver_overrides
platform_overrides __initdata = {
.reset =ehci_platform_reset,
};
+static struct usb_ehci_pdata ehci_platform_defaults;
+
static int ehci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
struct resource *res_mem;
- struct usb_ehci_pdata *pdata = dev-dev.platform_data;
+ struct usb_ehci_pdata *pdata;
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ if (!dev-dev.platform_data) {
+ dev-dev.platform_data = ehci_platform_defaults;
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ }
+ pdata = dev-dev.platform_data;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static const struct platform_device_id ehci_platform_table[] = {
{ ehci-platform, 0 },
{ }
@@ -203,6 +215,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..000
--- a/drivers/usb/host/ehci-vt8500.c
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
- * drivers/usb/host/ehci-vt8500.c
- *
- * Copyright (C) 2010 Alexey Charkov alch...@gmail.com
- *
- * Based on ehci-au1xxx.c
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Friday 15 March 2013, Alan Stern wrote: I just got an automated message from Greg: -- This is a note to let you know that I've just added the patch titled USB: EHCI: split ehci-omap out to a separate driver to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. -- Unless something is changed, this patch won't get into 3.9-final. Do you want Greg to move it to his usb-linus branch? I don't care much which way we do it, but I'd certainly like to see one of these two solutions for the bug: a) Apply Roger's patch for 3.9, and add my USB: EHCI: DT support for generic bus glue patch on top after it has been tested b) Apply my USB: EHCI: hot-fix OMAP and Orion multiplatform config when I send a version based on the proper tree for 3.9, and leave the other ones to do it properly for 3.10. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Friday 15 March 2013, Sergei Shtylyov wrote: a) Apply Roger's patch for 3.9, and add my USB: EHCI: DT support for generic bus glue patch on top after it has been tested Arnd, sorry, where can I find this patch? Archive search doesn't turn up anything... It's in this email thread, in one of my earlier replies to Alan. Since Greg already said that he won't take Roger's patch for 3.9, taking this one would be pointless as well. I can resubmit it for 3.10 once we know what to do about my hot-fix. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Friday 15 March 2013, Greg Kroah-Hartman wrote: Unless something is changed, this patch won't get into 3.9-final. Do you want Greg to move it to his usb-linus branch? It's a bit too big for 3.9-final, sorry. Would you consider the hot fix at the start of this thread for 3.9 then? I can resubmit it as a patch for inclusion with the missing hunk added in if there are no objections. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Saturday 16 March 2013, Greg Kroah-Hartman wrote: On Fri, Mar 15, 2013 at 09:13:52PM +, Arnd Bergmann wrote: On Friday 15 March 2013, Greg Kroah-Hartman wrote: Unless something is changed, this patch won't get into 3.9-final. Do you want Greg to move it to his usb-linus branch? It's a bit too big for 3.9-final, sorry. Would you consider the hot fix at the start of this thread for 3.9 then? I can resubmit it as a patch for inclusion with the missing hunk added in if there are no objections. Feel free to resend, but remember, I am very leery of pushing this type of patch in at the moment, given my past history with it... Sure, it's your decision. I just don't want to be accused of abandoning the issue that I caused. It's not strictly a regression because no configuration that was working in 3.8 is broken in 3.9, and embedded systems won't normally run a multiplatform kernel anyway. Also, the patch is really an ugly hack, which is probably enough reason not to take it. ;-) The only situation I can think of that is broken without the hotfix is distribution kernels that were already running multiplatform on Armada XP (mvebu/orion) and now want to add OMAP support without breaking the platforms that are already working. Peter Robinson is doing this on for Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo people will be in a similar situation, but they can all apply the patch manually if it doesn't make it into 3.9. It won't be the only patch they need to get there, it's just the only one for 3.9 we already know about. Arnd [1] https://plus.google.com/117898952501074015902/posts/VgnDhJBxbU4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] USB: EHCI: hot-fix OMAP and Orion multiplatform config
A number of ARM platforms were changed in linux-3.9 so they can be enabled
at a single kernel configuration. Unfortunately, the necessary changes for
the EHCI driver were not ready in time and the first attempt to split out
the EHCI bus glues into separate modules had to get reverted before the
merge window.
This means we are still stuck with a situation where enabling any
combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
platforms at the same time leaves us with an EHCI driver that does
not work properly and spits out this build warning:
ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
In file included from ehci-hcd.c:1256:0:
ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used
[-Wunused-variable]
In file included from ehci-hcd.c:1276:0:
ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used
[-Wunused-variable]
ehci-hcd.c:1277:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
This is the simplest patch I could come up with that will restore some
sanity in multiplatform configuration and allow us to build an ARM
allyesconfig kernel. Disallowing the broken configuration in Kconfig
would actually end up in a larger patch and more regression potential
than this one.
We had a similar situation in 3.8 with a conflict between Orion and MXC,
and Alan Stern objected to the simple hack back then and instead provided
a better full conversion of the MXC backend in patch dba63b2f7. A proper
patch for OMAP was submitted in January but also did not make it into 3.9,
see https://patchwork.kernel.org/patch/2055131.
I expect that for 3.10 we will be able to do this correctly and
turn all ARM bus glues into separate modules, ripping out the
code that this patch changes.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Roger Quadros rog...@ti.com
Cc: Andrew Lunn and...@lunn.ch
CC: Jason Cooper ja...@lakedaemon.net
---
changes since RFC v1:
* fix ORION_PLATFORM_DRIVER registration
* rebase on top of usb-linus branch
drivers/usb/host/ehci-hcd.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 416a6dc..f98f2a2 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1253,7 +1253,7 @@ MODULE_LICENSE (GPL);
#ifdef CONFIG_USB_EHCI_HCD_OMAP
#include ehci-omap.c
-#definePLATFORM_DRIVER ehci_hcd_omap_driver
+#defineOMAP_PLATFORM_DRIVERehci_hcd_omap_driver
#endif
#ifdef CONFIG_PPC_PS3
@@ -1273,7 +1273,7 @@ MODULE_LICENSE (GPL);
#ifdef CONFIG_PLAT_ORION
#include ehci-orion.c
-#definePLATFORM_DRIVER ehci_orion_driver
+#defineORION_PLATFORM_DRIVER ehci_orion_driver
#endif
#ifdef CONFIG_USB_W90X900_EHCI
@@ -1385,6 +1385,12 @@ static int __init ehci_hcd_init(void)
goto clean0;
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ retval = platform_driver_register(ORION_PLATFORM_DRIVER);
+ if (retval 0)
+ goto clean1;
+#endif
+
#ifdef PS3_SYSTEM_BUS_DRIVER
retval = ps3_ehci_driver_register(PS3_SYSTEM_BUS_DRIVER);
if (retval 0)
@@ -1402,10 +1408,20 @@ static int __init ehci_hcd_init(void)
if (retval 0)
goto clean4;
#endif
+
+#ifdef OMAP_PLATFORM_DRIVER
+ retval = platform_driver_register(OMAP_PLATFORM_DRIVER);
+ if (retval 0)
+ goto clean5;
+#endif
return retval;
+#ifdef OMAP_PLATFORM_DRIVER
+ /* platform_driver_unregister(OMAP_PLATFORM_DRIVER); */
+clean5:
+#endif
#ifdef XILINX_OF_PLATFORM_DRIVER
- /* platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER); */
+ platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER);
clean4:
#endif
#ifdef OF_PLATFORM_DRIVER
@@ -1416,6 +1432,10 @@ clean3:
ps3_ehci_driver_unregister(PS3_SYSTEM_BUS_DRIVER);
clean2:
#endif
+#ifdef ORION_PLATFORM_DRIVER
+ platform_driver_unregister(ORION_PLATFORM_DRIVER);
+clean1:
+#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
clean0:
@@ -1432,12 +1452,18 @@ module_init(ehci_hcd_init);
static void __exit ehci_hcd_cleanup(void)
{
+#ifdef OMAP_PLATFORM_DRIVER
+ platform_driver_unregister(OMAP_PLATFORM_DRIVER);
+#endif
#ifdef XILINX_OF_PLATFORM_DRIVER
platform_driver_unregister(XILINX_OF_PLATFORM_DRIVER);
#endif
#ifdef OF_PLATFORM_DRIVER
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
On Monday 18 March 2013, Arnaud Patard wrote: Arnd Bergmann a...@arndb.de writes: Sure, it's your decision. I just don't want to be accused of abandoning the issue that I caused. It's not strictly a regression because no configuration that was working in 3.8 is broken in 3.9, and embedded systems won't normally run a multiplatform kernel anyway. Also, the patch is really an ugly hack, which is probably enough reason not to take it. ;-) Given that the omap patch has been accepted and that the patch is an ugly hack, how hard it would be to provide a working patch for mvebu (well, orion usb driver) ? The OMAP patch was accepted for 3.10, and I'm sure we will have good patches for the other bus glues as well, but the bug is also present on 3.9, and the proper patches are too invasive now to get merged there. platforms that are already working. Peter Robinson is doing this on for Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo people will be in a similar situation, but they can all apply the patch fwiw, I've mentionned this usb issue few days ago when talking about multiplatform on the debian-arm ml. Yes, we've known about it for a long time, but failed to get the proper patches out in time :( manually if it doesn't make it into 3.9. It won't be the only patch they it can applied in the debian kernel, as long as the patch is merged upstream. It won't be merged in 3.10, but in that case Debian can backport the proper patches from 3.10. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB: simplify clock lookup for mv ehci/otg/udc
While going over the suggested changes for the ehci-mv separation patch,
we noticed that the driver uses a variable number of clock names it gets
passed from the platform code, which is highly unusual behavior and adds
a lot of extra complexity.
Even though there is a comment in the mv_udc driver stating that some SoCs
require multiple clocks, none of the code in the upstream kernel provides
more than one, and even if an out of tree SoC port needs multiple clocks,
it is still wrong to pass them them through platform data, since they are
a property of the device, not a property of the platform.
This patch attempts to clean up the situation by turning the one clock
that is passed into the ehci/udc/otg devices into an anomymous one and
removing the clkname array from the platform data. Another simplification
is to always call clk_prepare_enable/clk_disable_unprepare directly,
since that is a valid operation on a NULL clk pointer if the platform
has not attacked a clk to the device.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
Haojian, does this look reasonable to you?
arch/arm/mach-mmp/aspenite.c | 5 -
arch/arm/mach-mmp/clock-pxa168.c | 2 +-
arch/arm/mach-mmp/clock-pxa910.c | 4 +++-
arch/arm/mach-mmp/ttc_dkb.c | 6 --
drivers/usb/gadget/mv_udc.h | 4 +---
drivers/usb/gadget/mv_udc_core.c | 37 +
drivers/usb/host/ehci-mv.c | 43
++-
drivers/usb/otg/mv_otg.c | 38
+-
drivers/usb/otg/mv_otg.h | 3 +--
include/linux/platform_data/mv_usb.h | 1 -
10 files changed, 34 insertions(+), 109 deletions(-)
diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..988bd80 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -223,13 +223,8 @@ static struct pxa27x_keypad_platform_data
aspenite_keypad_info __initdata = {
};
#if defined(CONFIG_USB_EHCI_MV)
-static char *pxa168_sph_clock_name[] = {
- [0] = PXA168-USBCLK,
-};
-
static struct mv_usb_platform_data pxa168_sph_pdata = {
.clknum = 1,
- .clkname= pxa168_sph_clock_name,
.mode = MV_USB_MODE_HOST,
.phy_init = pxa_usb_phy_init,
.phy_deinit = pxa_usb_phy_deinit,
diff --git a/arch/arm/mach-mmp/clock-pxa168.c b/arch/arm/mach-mmp/clock-pxa168.c
index 5e6c18c..9edc50e 100644
--- a/arch/arm/mach-mmp/clock-pxa168.c
+++ b/arch/arm/mach-mmp/clock-pxa168.c
@@ -81,7 +81,7 @@ static struct clk_lookup pxa168_clkregs[] = {
INIT_CLKREG(clk_gpio, pxa-gpio, NULL),
INIT_CLKREG(clk_keypad, pxa27x-keypad, NULL),
INIT_CLKREG(clk_eth, pxa168-eth, MFUCLK),
- INIT_CLKREG(clk_usb, NULL, PXA168-USBCLK),
+ INIT_CLKREG(clk_usb, pxa-sph, NULL);
INIT_CLKREG(clk_rtc, sa1100-rtc, NULL),
};
diff --git a/arch/arm/mach-mmp/clock-pxa910.c b/arch/arm/mach-mmp/clock-pxa910.c
index 933ea71..6849155 100644
--- a/arch/arm/mach-mmp/clock-pxa910.c
+++ b/arch/arm/mach-mmp/clock-pxa910.c
@@ -57,7 +57,9 @@ static struct clk_lookup pxa910_clkregs[] = {
INIT_CLKREG(clk_pwm4, pxa910-pwm.3, NULL),
INIT_CLKREG(clk_nand, pxa3xx-nand, NULL),
INIT_CLKREG(clk_gpio, pxa-gpio, NULL),
- INIT_CLKREG(clk_u2o, NULL, U2OCLK),
+ INIT_CLKREG(clk_u2o, pxa-u2oehci, NULL),
+ INIT_CLKREG(clk_u2o, mv-udc, NULL),
+ INIT_CLKREG(clk_u2o, mv-otg, NULL),
INIT_CLKREG(clk_rtc, sa1100-rtc, NULL),
};
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 22a9058..39a7ad5 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -161,14 +161,8 @@ static struct i2c_board_info ttc_dkb_i2c_info[] = {
#ifdef CONFIG_USB_SUPPORT
#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
-
-static char *pxa910_usb_clock_name[] = {
- [0] = U2OCLK,
-};
-
static struct mv_usb_platform_data ttc_usb_pdata = {
.clknum = 1,
- .clkname= pxa910_usb_clock_name,
.vbus = NULL,
.mode = MV_USB_MODE_OTG,
.otg_force_a_bus_req = 1,
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index 9073436..fa87981 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -221,9 +221,7 @@ struct mv_udc {
struct mv_usb_platform_data *pdata;
- /* some SOC has mutiple clock sources for USB*/
- unsigned intclknum;
- struct clk *clk[0];
+ struct clk *clk;
};
/* endpoint data structure */
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c8cf959..8c4d4d2 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -1004,22 +1004,6 @@ static struct usb_ep_ops mv_ep_ops = {
.fifo_flush = mv_ep_fifo_flush, /* flush fifo
Re: [PATCH] USB: EHCI: fix for leaking isochronous data
On Thursday 21 March 2013, Jason Cooper wrote: On Thu, Mar 21, 2013 at 06:04:59PM +0100, Soeren Moch wrote: Now I found out what is going on here: In itd_urb_transaction() we allocate 9 iTDs for each URB with number_of_packets == 64 in my case. The iTDs are added to sched-td_list. For a frame-aligned scheduling we need 8 iTDs, the 9th one is released back to the front of the streams free_list in iso_sched_free(). This iTD was cleared after allocation and has a frame number of 0 now. So for each allocation when now_frame == 0 we allocate from the dma_pool, not from the free_list. The attached patch invalidates the frame number in each iTD before it is sent to the scheduler. This fixes the problem without the need to iterate over a iTD list. Signed-off-by: Soeren Moch sm...@web.de Wow! Great work Soeren! Talk about a long road to a small fix. Thanks for keeping after it. +1 I hardly understand half of the description above, but that much sounds plausible. Is this a bug fix that should get backported to stable kernels? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: EHCI: DT support for generic bus glue
This lets us use the ehci-generic driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.
Cc: Tony Prisk li...@prisktech.co.nz
Cc: Alexey Charkov alch...@gmail.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Arnd Bergmann a...@arndb.de
---
Tony, Alexey et al: could one of you test if this works for you?
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-platform.c | 28 ++--
drivers/usb/host/ehci-vt8500.c | 150 -
3 files changed, 22 insertions(+), 161 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 0c3314c..960e7cf 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1286,11 +1286,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include ehci-vt8500.c
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include ehci-spear.c
#define PLATFORM_DRIVERspear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..27e9227 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/kernel.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -62,22 +64,26 @@ static const struct ehci_driver_overrides
platform_overrides __initdata = {
.reset =ehci_platform_reset,
};
+static struct usb_ehci_pdata ehci_platform_defaults;
+
static int ehci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
struct resource *res_mem;
- struct usb_ehci_pdata *pdata = dev-dev.platform_data;
+ struct usb_ehci_pdata *pdata;
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ if (!dev-dev.platform_data) {
+ dev-dev.platform_data = ehci_platform_defaults;
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ }
+ pdata = dev-dev.platform_data;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -139,6 +145,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (pdata == ehci_platform_defaults)
+ dev-dev.platform_data = NULL;
+
return 0;
}
@@ -183,6 +192,12 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static const struct platform_device_id ehci_platform_table[] = {
{ ehci-platform, 0 },
{ }
@@ -203,6 +218,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..000
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: EHCI: DT support for generic bus glue
On Monday 25 March 2013, Tony Prisk wrote: I'll take a look at this and get back to you before Easter. Great, thanks a lot! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: EHCI: DT support for generic bus glue
On Monday 25 March 2013, Alan Stern wrote: On Mon, 25 Mar 2013, Felipe Balbi wrote: this ehci_platform_defaults is quite a hack. Would be much better to see a proper re-factoring of the code so that it actually learns about DT and platform_data. So, if dev-dev.platform_data is NULL, you shouldn't error, rather you should just assume the default, rather than this quick little hack. Alan has final saying though. IMO, using ehci_platform_defaults is a way of assuming the default. In other words, it's not a bad hack. I'm okay with this this approach (in fact, it was my suggestion originally). I intentionally did not add any properties for the fields in the current usb_ehci_pdata. It's not possible to implement the callbacks using just DT, and the flags are all defined so that 'false' is the default that happens to be used by the compatible=wm,prizm-ehci binding. We can easily extend this driver to also cover the flags or the caps_offset, or we can add support for regulators and clocks, but I would prefer to do those only when we actually add support for a device that needs them. On the other hand, it would be nice to have a clearer way of indicating that the driver was invoked because of a DT match, something better than just noticing that dev-dev.platform_data is NULL. But I guess this is a legitimate option even for regular platform drivers -- if they don't have any specific requirements, they may as well pass a NULL pointer instead of a pointer to an empty structure. I'm certainly fine doing it either way: leave the defaults for pdata=NULL or require either a DT match or a pdata pointer (or both, in case of auxdata, I guess). Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: EHCI: DT support for generic bus glue
On Monday 25 March 2013, Alan Stern wrote:
+ if (!dev-dev.platform_data) {
+ dev-dev.platform_data = ehci_platform_defaults;
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
In view of Felipe's comment, shouldn't these last two lines be
controlled by dev-dev.of_node != NULL instead?
We could do that, or alternatively like this
if (!dev-dev.platform_data) {
dev-dev.platform_data = ehci_platform_defaults;
if (!dev-dev.dma_mask)
dev-dev.dma_mask = dev-dev.coherent_dma_mask;
if (!dev-dev.coherent_dma_mask)
dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
which would have the additional advantage that platforms can then
call platform_device_register_resndata() to create the device
and get a reasonable default dma mask (EHCI should always have
32 bit DMA, unless the platform is really screwed), rather than
statically declaring platform devices.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: EHCI: DT support for generic bus glue
On Tuesday 26 March 2013, Alan Stern wrote: That's up to platform guys. I wasn't aware of any common practice whereby drivers would fill in a missing dma_mask, except in the DT case. I don't think we are consistent in any way. PowerPC sets up a 32 bit DMA mask for all devices during DT probe from arch code, while the common code sets up coherent_dma_mask but not dma_mask, except for AMBA devices, which also get the 32 bit mask. The MIPS Octeon and PowerPC PS3 EHCI backends set up the dma mask because platform code doesn't do it for them, but both drivers are not using DT. The Xilinx and PPC-OF EHCI back-end do not set it up, because on microblaze and powerpc it does come from the platform code. I think it's a horrible mess and if anyone has an idea of what the right solution is, we should probably implement that, but from what I see here, setting a 32-bit dma mask unless there is already one is a reasonable choice. Don't forget that EHCI is theoretically capable of using 64-bit DMA. This may not matter for any of the platforms you're concerned about now, but it may matter in the future. Ah, I wasn't aware of that. I had previously used a platform EHCI on PowerPC64 and the hardware manual said that it was 32-bit only. Apparently the chip designers screwed up there. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] USB: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol
On Tuesday 26 March 2013, Florian Fainelli wrote: Just like the OHCI counter part we just can remove the architecture specific symbols which prevent these configuration symbols from being selected by platforms/architectures requiring it. The original implementation did not scale at all since it required each and every single architecture to be added for these configuration symbols to be selected. Now it is up to the EHCI driver and/or platform to select these configuration symbols accordingly. Signed-off-by: Florian Fainelli flor...@openwrt.org Good idea, just one suggestion: config USB_EHCI_BIG_ENDIAN_MMIO bool - depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX || \ - ARCH_IXP4XX || XPS_USB_HCD_XILINX || \ - PPC_MPC512x || CPU_CAVIUM_OCTEON || \ - PMC_MSP || SPARC_LEON || MIPS_SEAD3) - default y + depends on USB_EHCI_HCD + default n config USB_EHCI_BIG_ENDIAN_DESC bool - depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX || \ - PPC_MPC512x || PMC_MSP || SPARC_LEON || \ - MIPS_SEAD3) - default y + depends on USB_EHCI_HCD + default n config XPS_USB_HCD_XILINX bool Use Xilinx usb host EHCI controller core You can drop the default n line as well, it's the default. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] USB: EHCI: DT support for generic bus glue
This lets us use the ehci-generic driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.
Tested-by: Tony Prisk li...@prisktech.co.nz
Tested-by: Peter Vasil peterva...@gmail.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Arnd Bergmann a...@arndb.de
---
v3: always set dma_mask and coherent_dma_mask when not already set,
rather than overriding them for any device without platform data
v2: reset the platform data pointer on unload
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-platform.c | 28 ++--
drivers/usb/host/ehci-vt8500.c | 150 -
3 files changed, 22 insertions(+), 161 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 0c3314c..960e7cf 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1286,11 +1286,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include ehci-vt8500.c
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include ehci-spear.c
#define PLATFORM_DRIVERspear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..cda0fa9 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/kernel.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -62,22 +64,32 @@ static const struct ehci_driver_overrides
platform_overrides __initdata = {
.reset =ehci_platform_reset,
};
+static struct usb_ehci_pdata ehci_platform_defaults;
+
static int ehci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
struct resource *res_mem;
- struct usb_ehci_pdata *pdata = dev-dev.platform_data;
+ struct usb_ehci_pdata *pdata;
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ /*
+* use reasonable defaults so platforms don't have to provide these.
+* with DT probing on ARM, none of these are set.
+*/
+ if (!dev-dev.platform_data)
+ dev-dev.platform_data = ehci_platform_defaults;
+ if (!dev-dev.dma_mask)
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
+ if (!dev-dev.coherent_dma_mask)
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+ pdata = dev-dev.platform_data;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -139,6 +151,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (pdata == ehci_platform_defaults)
+ dev-dev.platform_data = NULL;
+
return 0;
}
@@ -183,6 +198,12 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static const struct platform_device_id ehci_platform_table[] = {
{ ehci-platform, 0 },
{ }
@@ -203,6 +224,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..000
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] USB: EHCI: DT support for generic bus glue
On Wednesday 27 March 2013, Peter Vasil wrote: Hi, unfortunately I still can't apply it on 3.9-rc4 :-( $ git apply --check ehci-dt-bus-glue.patch error: removal patch leaves file contents error: drivers/usb/host/ehci-vt8500.c: patch does not apply Looks git really doesn't like ehci-vt8500.c removal. If I delete the file manually, git diff actually outputs full file content prefixed with -. Are you using an old git version? I normally use 'git format-patch -M -D' to produce patches in the reduced format that handles moves and deletions nicer but is incompatible with older versions of 'patch'. I'll fix up the changelog to mention the correct driver and resend without -D. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] USB: EHCI: DT support for generic bus glue
This lets us use the ehci-platform driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.
Tested-by: Tony Prisk li...@prisktech.co.nz
Tested-by: Peter Vasil peterva...@gmail.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Arnd Bergmann a...@arndb.de
---
v4: fix the name of the driver in the changelog
submit the patch with the full file deletion.
v3: always set dma_mask and coherent_dma_mask when not already set,
rather than overriding them for any device without platform data
v2: reset the platform data pointer on unload
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-platform.c | 34 +++--
drivers/usb/host/ehci-vt8500.c | 150 ---
3 files changed, 28 insertions(+), 161 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 0c3314c..960e7cf 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1286,11 +1286,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include ehci-vt8500.c
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include ehci-spear.c
#define PLATFORM_DRIVERspear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..cda0fa9 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/kernel.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -62,22 +64,32 @@ static const struct ehci_driver_overrides
platform_overrides __initdata = {
.reset =ehci_platform_reset,
};
+static struct usb_ehci_pdata ehci_platform_defaults;
+
static int ehci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
struct resource *res_mem;
- struct usb_ehci_pdata *pdata = dev-dev.platform_data;
+ struct usb_ehci_pdata *pdata;
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ /*
+* use reasonable defaults so platforms don't have to provide these.
+* with DT probing on ARM, none of these are set.
+*/
+ if (!dev-dev.platform_data)
+ dev-dev.platform_data = ehci_platform_defaults;
+ if (!dev-dev.dma_mask)
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
+ if (!dev-dev.coherent_dma_mask)
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+ pdata = dev-dev.platform_data;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -139,6 +151,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (pdata == ehci_platform_defaults)
+ dev-dev.platform_data = NULL;
+
return 0;
}
@@ -183,6 +198,12 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = via,vt8500-ehci, },
+ { .compatible = wm,prizm-ehci, },
+ {}
+};
+
static const struct platform_device_id ehci_platform_table[] = {
{ ehci-platform, 0 },
{ }
@@ -203,6 +224,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..000
--- a/drivers/usb/host/ehci-vt8500.c
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
- * drivers/usb/host/ehci-vt8500.c
- *
- * Copyright (C) 2010 Alexey Charkov alch...@gmail.com
- *
- * Based on ehci-au1xxx.c
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details
Re: [PATCH v3] USB: EHCI: DT support for generic bus glue
On Wednesday 27 March 2013, Peter Vasil wrote: Hm, no idea what the latest versions are :-) I use archlinux, with latest updates installed. Here are my git and patch versions: $ git --version git version 1.8.2 $ patch --version GNU patch 2.7.1 Btw. my git understands format-patch -D, but its help looks a bit suspicous: -D, --irreversible-delete Omit the preimage for deletes, i.e. print only the header but not the diff between the preimage and /dev/null. The resulting patch is not meant to be applied with patch nor git apply; this is solely for people who want to just concentrate on reviewing the text after the change. In addition, the output obviously lack enough information to apply such a patch in reverse, even manually, hence the name of the option. When used together with -B, omit also the preimage in the deletion part of a delete/create pair. Perhaps there is a newer version that can also apply such a reduced patch? Hmm, my version is slightly older than yours. I also find the same thing here: $ git format-patch -M -D HEAD^ 0001-USB-EHCI-DT-support-for-generic-bus-glue.patch $ git reset --hard HEAD^ HEAD is now at 417c765 USB: EHCI: fix up incorrect merge resolution $ git am 0001-USB-EHCI-DT-support-for-generic-bus-glue.patch Applying: USB: EHCI: DT support for generic bus glue error: removal patch leaves file contents error: drivers/usb/host/ehci-vt8500.c: patch does not apply Patch failed at 0001 USB: EHCI: DT support for generic bus glue The copy of the patch that failed is found in: /home/arnd/arm-soc/.git/rebase-apply/patch When you have resolved this problem, run git am --resolved. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. I guess I won't be using the -D switch again then. Thanks for pointing this out! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: ehci: mark unlink_empty_async_suspended() as __maybe_unused
Patch 4d053fdac3 usb: ehci: unlink_empty_async_suspended() only used
with CONFIG_PM tried to hide the unlink_empty_async_suspended function
inside of an #ifdef to work around an unused function warning.
Unfortunately that had the effect of introducing a new warning:
drivers/usb/host/ehci-q.c:1297:13: warning: 'unlink_empty_async_suspended'
declared 'static' but never defined [-Wunused-function]
While we could add another #ifdef around the function declaration to avoid
this, a nicer solution is to mark it as __maybe_unused, which will let
gcc silently drop the function definition when it is not needed.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 7562d76..d34b399 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1293,9 +1293,8 @@ static void unlink_empty_async(struct ehci_hcd *ehci)
}
}
-#ifdef CONFIG_PM
/* The root hub is suspended; unlink all the async QHs */
-static void unlink_empty_async_suspended(struct ehci_hcd *ehci)
+static void __maybe_unused unlink_empty_async_suspended(struct ehci_hcd *ehci)
{
struct ehci_qh *qh;
@@ -1306,7 +1305,6 @@ static void unlink_empty_async_suspended(struct ehci_hcd
*ehci)
}
start_iaa_cycle(ehci);
}
-#endif
/* makes sure the async qh will become idle */
/* caller must own ehci-lock */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: mark unlink_empty_async_suspended() as __maybe_unused
On Thursday 28 March 2013, Arnd Bergmann wrote: Patch 4d053fdac3 usb: ehci: unlink_empty_async_suspended() only used with CONFIG_PM tried to hide the unlink_empty_async_suspended function inside of an #ifdef to work around an unused function warning. Hi Greg, Apparently the warning is now also in 3.8.5, so you might want to backport this fix as well after you send it upstream. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V3:
-Detailed commit message added here about why this patch is required.
-Eliminated ehci_spear_setup routine beacuse hcd registers
directly setting in spear_ehci_hcd_drv_probe function.
-spear_overrides struct initialized.
-Eliminate struct ehci_hcd ehci from struct spear_ehci,to enable SPEAr clock
uses directly usb_hcd *hcd in spear_start_ehci function.
-to_spear_ehci() macro modified for spear_ehci.
In V2:
Replaced spear as SPEAr everywhere, leaving functions/variables/config options.
Signed-off-by: Deepak Saxena dsax...@linaro.org
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Viresh Kumar viresh.li...@gmail.com
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Shiraz Hashim shiraz.has...@st.com
Cc: linux-usb@vger.kernel.org
Cc: spear-de...@list.st.com
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-spear.c | 88 ---
4 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d89b7ad..12fb83e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -173,6 +173,14 @@ config USB_EHCI_HCD_ORION
Armada 370. This is different from the EHCI implementation
on Marvell's mobile PXA and MMP SoC, see USB_EHCI_MV for those.
+config USB_EHCI_HCD_SPEAR
+tristate Support for ST SPEAr on-chip EHCI USB controller
+depends on USB_EHCI_HCD PLAT_SPEAR
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ ST SPEAr chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9492f50..3e02471 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
+obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1f97268..c8c70a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1264,11 +1264,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_PLAT_SPEAR
-#include ehci-spear.c
-#define PLATFORM_DRIVERspear_ehci_hcd_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_MSM
#include ehci-msm.c
#define PLATFORM_DRIVERehci_msm_driver
@@ -1315,6 +1310,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 210bb67..d3a5859 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -1,5 +1,5 @@
/*
-* Driver for EHCI HCD on SPEAR SOC
+* Driver for EHCI HCD on SPEAr SOC
*
* Copyright (C) 2010 ST Micro Electronics,
* Deepak Sikri deepak.si...@st.com
@@ -12,17 +12,28 @@
*/
#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/io.h
#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
#include linux/pm.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI SPEAr driver
+
+static const char hcd_name[] = SPEAr-ehci;
struct spear_ehci {
- struct ehci_hcd ehci;
struct clk *clk;
};
-#define to_spear_ehci(hcd) (struct spear_ehci *)hcd_to_ehci(hcd)
+#define to_spear_ehci(hcd) (struct spear_ehci *)(hcd_to_ehci(hcd)-priv)
static void spear_start_ehci(struct spear_ehci *ehci)
{
@@ -34,49 +45,7 @@ static void spear_stop_ehci
[PATCH v3 7/7] USB: OHCI: avoid conflicting platform drivers
Like the EHCI driver, OHCI supports a large number of different platform glue drivers by directly including them, which causes problems with conflicting macro definitions in some cases. As more ARM architecture specific back-ends are required to coexist in a single build, we should split those out into separate drivers. Unfortunately, the infrastructure for that is still under development, so to give us more time, this uses a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend, just like we already do on PowerPC and some of the other ARM platforms. In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict without this patch, but over time we would get more of them, so this is a way to avoid having to patch the driver every time it breaks. We should still split out all back-ends into separate loadable modules, but that work is only needed to improve code size and cleanliness after this patch, not for correctness. While we're here, this fixes the incorrectly sorted error path for the OMAP1 and OMAP3 backends to ensure we always unregister the exact set of drivers that were registered before erroring out. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Manjunath Goudar manjunath.gou...@linaro.org Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-hcd.c | 136 ++-- 1 file changed, 118 insertions(+), 18 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 180a2b0..9e6de95 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1102,12 +1102,12 @@ MODULE_LICENSE (GPL); #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX) #include ohci-s3c2410.c -#define PLATFORM_DRIVERohci_hcd_s3c2410_driver +#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver #endif #ifdef CONFIG_USB_OHCI_EXYNOS #include ohci-exynos.c -#define PLATFORM_DRIVERexynos_ohci_driver +#define EXYNOS_PLATFORM_DRIVER exynos_ohci_driver #endif #ifdef CONFIG_USB_OHCI_HCD_OMAP1 @@ -1127,25 +1127,24 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_ARCH_EP93XX #include ohci-ep93xx.c -#define PLATFORM_DRIVERohci_hcd_ep93xx_driver +#define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver #endif #ifdef CONFIG_ARCH_AT91 #include ohci-at91.c -#define PLATFORM_DRIVERohci_hcd_at91_driver +#define AT91_PLATFORM_DRIVER ohci_hcd_at91_driver #endif #ifdef CONFIG_ARCH_LPC32XX #include ohci-nxp.c -#define PLATFORM_DRIVERusb_hcd_nxp_driver +#define NXP_PLATFORM_DRIVERusb_hcd_nxp_driver #endif #ifdef CONFIG_ARCH_DAVINCI_DA8XX #include ohci-da8xx.c -#define PLATFORM_DRIVERohci_hcd_da8xx_driver +#define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver #endif - #ifdef CONFIG_USB_OHCI_HCD_PPC_OF #include ohci-ppc-of.c #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver @@ -1153,7 +1152,7 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_PLAT_SPEAR #include ohci-spear.c -#define PLATFORM_DRIVERspear_ohci_hcd_driver +#define SPEAR_PLATFORM_DRIVER spear_ohci_hcd_driver #endif #ifdef CONFIG_PPC_PS3 @@ -1199,7 +1198,14 @@ MODULE_LICENSE (GPL); !defined(SA_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(SM501_OHCI_DRIVER) \ - !defined(TMIO_OHCI_DRIVER) + !defined(TMIO_OHCI_DRIVER) \ + !defined(S3C2410_PLATFORM_DRIVER) \ + !defined(EXYNOS_PLATFORM_DRIVER) \ + !defined(EP93XX_PLATFORM_DRIVER) \ + !defined(AT91_PLATFORM_DRIVER) \ + !defined(NXP_PLATFORM_DRIVER) \ + !defined(DAVINCI_PLATFORM_DRIVER) \ + !defined(SPEAR_PLATFORM_DRIVER) #error missing bus glue for ohci-hcd #endif @@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void) goto error_tmio; #endif +#ifdef S3C2410_PLATFORM_DRIVER + retval = platform_driver_register(S3C2410_PLATFORM_DRIVER); + if (retval 0) + goto error_s3c2410; +#endif + +#ifdef EXYNOS_PLATFORM_DRIVER + retval = platform_driver_register(EXYNOS_PLATFORM_DRIVER); + if (retval 0) + goto error_exynos; +#endif + +#ifdef EP93XX_PLATFORM_DRIVER + retval = platform_driver_register(EP93XX_PLATFORM_DRIVER); + if (retval 0) + goto error_ep93xx; +#endif + +#ifdef AT91_PLATFORM_DRIVER + retval = platform_driver_register(AT91_PLATFORM_DRIVER); + if (retval 0) + goto error_at91; +#endif + +#ifdef NXP_PLATFORM_DRIVER + retval = platform_driver_register(NXP_PLATFORM_DRIVER); + if (retval 0) + goto error_nxp; +#endif + +#ifdef DAVINCI_PLATFORM_DRIVER + retval = platform_driver_register(DAVINCI_PLATFORM_DRIVER); + if (retval 0) + goto error_davinci; +#endif + +#ifdef SPEAR_PLATFORM_DRIVER + retval
[PATCH v3 5/7] USB: EHCI: make ehci-atmel a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Atmel host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Atmel can be
booted with a multi-platform kernel. This is currently planned for
Linux-3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the Atmel bus glue.
In V3:
-Detailed commit message added here about why this patch is required.
-Replaced hcd_name string ehci-atmel to atmel-ehci.
-In Makefile inserted Blank line that separates the EHCI drivers from the
following non-EHCI drivers.
-Export ehci_shutdown symbol as it is needed by the Atmel driver.
-Eliminated ehci_atmel_setup routine beacuse hcd registers
directly setting in ehci_atmel_drv_probe function.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function
'ehci_shutdown'
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: Andrew Victor li...@maxim.org.za
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-atmel.c | 85 ---
drivers/usb/host/ehci-hcd.c | 6 +--
4 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 01c1acb..8c564aa 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -181,6 +181,14 @@ config USB_EHCI_HCD_SPEAR
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
+config USB_EHCI_HCD_AT91
+tristate Support for Atmel on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3d895b5..368d3eb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index f3beac4..9ce1217 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -15,6 +15,19 @@
#include linux/platform_device.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI atmel driver
+
+static const char hcd_name[] = ehci-atmel;
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -50,51 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
/*-*/
-static int ehci_atmel_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci-caps = hcd-regs;
-
- return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = Atmel EHCI UHP HS,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset
[PATCH v3 0/7] USB EHCI multiplatform series again
Hi Alan, These are the current patches from Manjunath, after I helped him address the remaining review comments and found a few more in the process. Unfortunately, Manjunath is currently on vacation and I will be away for the next couple of days when he returns, so I took the liberty to send the patches myself to have a chance of getting them merged in time for 3.10. The patches are all based on today's usb-next branch, which includes my earlier patch to remove the vt8500 backend. They are sorted by priority: the first one obviously should have been in 3.9 but didn't make it. The second one will be needed in 3.10, and the third one quite likely as well. The atmel and msm patches can wait for 3.11 since we don't plan to have multiplatform support for those SoCs in 3.10. Manjunath also did patches for the tegra, mv and w90X900 back-ends, but there are still known bugs in them so we don't submit them yet. Tegra might become multiplatform in 3.10, but that will still work as long as it's the only platform defining the PLATFORM_DRIVER macro. Please review the latest version so we can get at least the first three patches merged for 3.10, or more if you are happy with them. I'm not sure what to do about OHCI, the last patch in this series is the best I could think of, given that nobody has worked on a proper series. Nicolas and David: the at91 and msm patches have no maintainer Ack so far and are build-tested only. Please let us know if you want to get them merged for 3.10, or if we should drop them for now and let you pick them up when you get around to adding multiplatform support for your SoCs. The at91 patch requires USB: EHCI: export ehci_shutdown, which will also be needed for the upcoming Tegra patch. Arnd Arnd Bergmann (2): USB: EHCI: export ehci_shutdown USB: OHCI: avoid conflicting platform drivers Manjunath Goudar (5): USB: EHCI: make ehci-orion a separate driver USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-msm a separate driver drivers/usb/host/Kconfig | 33 - drivers/usb/host/Makefile | 5 ++ drivers/usb/host/ehci-atmel.c | 85 +++ drivers/usb/host/ehci-hcd.c | 33 ++--- drivers/usb/host/ehci-msm.c | 85 ++- drivers/usb/host/ehci-orion.c | 82 ++ drivers/usb/host/ehci-s5p.c | 153 +- drivers/usb/host/ehci-spear.c | 88 +++- drivers/usb/host/ehci.h | 1 + drivers/usb/host/ohci-hcd.c | 136 - 10 files changed, 391 insertions(+), 310 deletions(-) Cc: Alan Stern st...@rowland.harvard.edu Cc: Bryan Huntsman bry...@codeaurora.org Cc: David Brown dav...@codeaurora.org Cc: Greg KH g...@kroah.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Kukjin Kim kgene@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Manjunath Goudar manjunath.gou...@linaro.org Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Shiraz Hashim shiraz.has...@st.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: spear-de...@list.st.com -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] USB: EHCI: export ehci_shutdown
The ehci_shutdown function is used by the platform specific ehci backends
for at91, tegra and ps3. In order to turn any of these into separate
modules, we need to make this function globally visible and export it.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ehci-hcd.c | 3 ++-
drivers/usb/host/ehci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8f1f4b4..1c9aa17 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -353,7 +353,7 @@ static void ehci_silence_controller(struct ehci_hcd *ehci)
* This forcibly disables dma and IRQs, helping kexec and other cases
* where the next system software may expect clean state.
*/
-static void ehci_shutdown(struct usb_hcd *hcd)
+void ehci_shutdown(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -367,6 +367,7 @@ static void ehci_shutdown(struct usb_hcd *hcd)
hrtimer_cancel(ehci-hrtimer);
}
+EXPORT_SYMBOL_GPL(ehci_shutdown);
/*-*/
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e666999..915739d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -799,6 +799,7 @@ struct ehci_driver_overrides {
extern voidehci_init_driver(struct hc_driver *drv,
const struct ehci_driver_overrides *over);
extern int ehci_setup(struct usb_hcd *hcd);
+extern voidehci_shutdown(struct usb_hcd *hcd);
#ifdef CONFIG_PM
extern int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] USB: EHCI: make ehci-orion a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. In V3: 1.More detail provided in commit message regarding this patch. 2.Replaced hcd_name string ehci-orion into orion-ehci. 3.MODULE_LICENSE is GPL v2. 4.In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Jason Cooper ja...@lakedaemon.net Tested-by: Andrew Lunn and...@lunn.ch Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org --- drivers/usb/host/Kconfig | 10 ++ drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +--- drivers/usb/host/ehci-orion.c | 82 ++- 4 files changed, 47 insertions(+), 52 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 2f68221..d89b7ad 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -163,6 +163,16 @@ config USB_EHCI_HCD_OMAP Enables support for the on-chip EHCI controller on OMAP3 and later chips. +config USB_EHCI_HCD_ORION + tristate Support for Marvell EBU on-chip EHCI USB controller + depends on USB_EHCI_HCD PLAT_ORION + default y + ---help--- + Enables support for the on-chip EHCI controller on Marvell's + embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP, + Armada 370. This is different from the EHCI implementation + on Marvell's mobile PXA and MMP SoC, see USB_EHCI_MV for those. + config USB_EHCI_MSM bool Support for MSM on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_MSM diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 56de410..9492f50 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_EHCI_PCI)+= ehci-pci.o obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o +obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index b12b97d..1f97268 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1249,11 +1249,6 @@ MODULE_LICENSE (GPL); #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver #endif -#ifdef CONFIG_PLAT_ORION -#include ehci-orion.c -#definePLATFORM_DRIVER ehci_orion_driver -#endif - #ifdef CONFIG_USB_W90X900_EHCI #include ehci-w90x900.c #definePLATFORM_DRIVER ehci_hcd_w90x900_driver @@ -1319,6 +1314,7 @@ MODULE_LICENSE (GPL); !IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) \ !IS_ENABLED(CONFIG_USB_EHCI_MXC) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \ + !IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \ !defined(PLATFORM_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(OF_PLATFORM_DRIVER) \ diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c index 38c45fb..54c5794 100644 --- a/drivers/usb/host/ehci-orion.c +++ b/drivers/usb/host/ehci-orion.c @@ -17,6 +17,12 @@ #include linux/of.h #include linux/of_device.h #include linux/of_irq.h +#include linux/usb.h +#include linux/usb/hcd.h +#include linux/io.h +#include linux/dma-mapping.h + +#include ehci.h #define rdl(off) __raw_readl(hcd-regs + (off)) #define wrl(off, val) __raw_writel((val), hcd-regs + (off)) @@ -34,6 +40,12 @@ #define USB_PHY_IVREF_CTRL 0x440 #define USB_PHY_TST_GRP_CTRL
[PATCH v3 3/7] USB: EHCI: make ehci-s5p a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Samsung S5P/EXYNOS host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before S5P/EXYNOS can be booted with a multi-platform kernel. We currently expect those to get merged for 3.10. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the s5p bus glue. In V3: -Detail commit message added here,why this patch is required. -MODULE_LICENSE is GPL v2. -Added .extra_priv_size to eliminate the separate allocation of the s5p_ehci_hcd structure and removed .reset function pointer initialization. -Arranged #include's in alphabetical order. -After using extra_priv_size initialization,struct usb_hcd *hcd is redundant that's why removed from the prob function. -Eliminated s5p_ehci_phy_enable,contents of statements moved into the s5p_ehci_probe -Eliminated s5p_ehci_phy_disable, contents of statements moved into the s5p_ehci_remove. In V2: Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Acked-by: Jingoo Han jg1@samsung.com Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Kukjin Kim kgene@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: linux-usb@vger.kernel.org Signed-off-by: Arnd Bergmann a...@arndb.de --- drivers/usb/host/Kconfig| 5 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +- drivers/usb/host/ehci-s5p.c | 153 ++-- 4 files changed, 82 insertions(+), 83 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 12fb83e..01c1acb 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -218,10 +218,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_S5P - boolean S5P EHCI support + tristate EHCI support for Samsung S5P/EXYNOS SoC Series depends on USB_EHCI_HCD PLAT_S5P help -Enable support for the S5P SOC's on-chip EHCI controller. + Enable support for the Samsung S5P and Exynos3/4/5 SOC's + on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell on-chip controller diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 3e02471..3d895b5 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o +obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c8c70a1..8f1f4b4 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1284,11 +1284,6 @@ MODULE_LICENSE (GPL); #define PLATFORM_DRIVERtegra_ehci_driver #endif -#ifdef CONFIG_USB_EHCI_S5P -#include ehci-s5p.c -#define PLATFORM_DRIVERs5p_ehci_driver -#endif - #ifdef CONFIG_SPARC_LEON #include ehci-grlib.c #define PLATFORM_DRIVERehci_grlib_driver @@ -1311,6 +1306,7 @@ MODULE_LICENSE (GPL); !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \ + !IS_ENABLED(CONFIG_USB_EHCI_S5P) \ !defined(PLATFORM_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(OF_PLATFORM_DRIVER) \ diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index 738490e..f32be6f 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -13,13 +13,24 @@ */ #include linux/clk.h +#include linux/dma-mapping.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h #include linux/of.h -#include linux/platform_device.h #include linux/of_gpio.h +#include linux/platform_device.h #include linux/platform_data/usb-ehci-s5p.h #include linux/usb/phy.h #include linux/usb/samsung_usb_phy.h #include plat/usb-phy.h +#include linux/usb.h +#include linux/usb/hcd.h +#include linux/usb/otg.h + +#include ehci.h + +#define DRIVER_DESC EHCI s5p driver #define EHCI_INSNREG00(base) (base + 0x90) #define EHCI_INSNREG00_ENA_INCR16 (0x1 25) @@ -30,65 +41,17 @@ (EHCI_INSNREG00_ENA_INCR16 | EHCI_INSNREG00_ENA_INCR8 | \ EHCI_INSNREG00_ENA_INCR4
[PATCH v3 6/7] USB: EHCI: make ehci-msm a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Qualcomm QSD/MSM on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Qualcomm QSD/MSM
can be booted with a multi-platform kernel, which is not expected before
3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the msm bus glue.
In V3:
1.Detail commit message added here,why this patch is required.
2.Arranged #include's in alphabetical order.
3.drive.name initialized hcd_name[] = ehci-msm in platform_driver structure
initialization
instead of msm-ehci,that is reason it was breaking in EHCI USB testing.this
one fixed in V3.
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Brian Swetland swetl...@google.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +---
drivers/usb/host/ehci-msm.c | 85 -
4 files changed, 40 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8c564aa..35a5d3b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -190,7 +190,7 @@ config USB_EHCI_HCD_AT91
Atmel chips.
config USB_EHCI_MSM
- bool Support for MSM on-chip EHCI USB controller
+ tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
select USB_EHCI_ROOT_HUB_TT
select USB_MSM_OTG
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 368d3eb..4fb73c1 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
+obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index efc641c..d5c4ae8 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1260,11 +1260,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_USB_EHCI_MSM
-#include ehci-msm.c
-#define PLATFORM_DRIVERehci_msm_driver
-#endif
-
#ifdef CONFIG_TILE_USB
#include ehci-tilegx.c
#definePLATFORM_DRIVER ehci_hcd_tilegx_driver
@@ -1304,6 +1299,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) \
+ !IS_ENABLED(CONFIG_USB_EHCI_MSM) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 88a49c8..3b45f0c 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -22,16 +22,26 @@
* along with this program; if not, you can find it at http://www.fsf.org
*/
-#include linux/platform_device.h
#include linux/clk.h
#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
-
#include linux/usb/otg.h
#include linux/usb/msm_hsusb_hw.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
#define MSM_USB_BASE (hcd-regs)
+#define DRIVER_DESC Qualcomm On-Chip EHCI Host Controller
+
+static const char hcd_name[] = ehci-msm;
+static struct hc_driver __read_mostly msm_hc_driver;
static struct usb_phy *phy;
static int ehci_msm_reset(struct usb_hcd *hcd)
@@ -56,52 +66,6 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
return 0;
}
-static struct hc_driver msm_hc_driver = {
- .description= hcd_name,
- .product_desc = Qualcomm On-Chip EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_USB2 | HCD_MEMORY,
-
- .reset = ehci_msm_reset,
- .start = ehci_run,
-
- .stop
Re: [PATCH v3 1/7] USB: EHCI: make ehci-orion a separate driver
On Friday 29 March 2013, Alan Stern wrote: I don't know about this last phrase. When someone is running make menuconfig, for example, what shows up is the symbol's description, not the symbol's name. That person would see EHCI support for Marvell on-chip controller, not USB_EHCI_MV. In fact, shouldn't the description for USB_EHCI_MV be changed too, to make it more distinct from this one? All the code changes are fine. Ok, I've included these Kconfig changes. Originally, the text change for PXA/MMP was included in the patch for ehci-mv, but that one is deferred to 3.11 now because of dependencies for the platform code that we want to first merge in 3.10. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
On Friday 29 March 2013, Alan Stern wrote:
On Thu, 28 Mar 2013, Arnd Bergmann wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V3:
-Detailed commit message added here about why this patch is required.
-Eliminated ehci_spear_setup routine beacuse hcd registers
directly setting in spear_ehci_hcd_drv_probe function.
Fix the grammar, please.
Done. I agree some of this is hardly legible.
Manjunath, I can teach you about device drivers and submission
procedures, but I cannot teach you basic English. If necessary, find
someone to proofread your emails.
-static int ehci_spear_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci-caps = hcd-regs;
This line never got moved into spear_ehci_hcd_drv_probe().
Ah, I missed it. Thanks for looking at this more carefully than
I did.
@@ -161,7 +130,7 @@ static int spear_ehci_hcd_drv_probe(struct
platform_device *pdev)
goto err_put_hcd;
}
- ehci = (struct spear_ehci *)hcd_to_ehci(hcd);
+ ehci = to_spear_ehci(hcd);
ehci-clk = usbh_clk;
I strongly believe that the name ehci should be reserved for
variables of type struct ehci_hcd. Here and in the start, stop, and
remove routines, please use spear_ehci as the name for a variable of
type struct spear_ehci. Or whatever else you want -- just don't call
it ehci or ehci_p.
Ok, renamed to sehci in lack of a better idea. I noticed this before,
but I did not ask Manjunath to fix it because it was a preexisting mistake
in the driver.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/7] USB: EHCI: make ehci-s5p a separate driver
On Friday 29 March 2013, Alan Stern wrote:
On Thu, 28 Mar 2013, Arnd Bergmann wrote:
Personally, I would have left these two functions the way they were and
relied on the compiler to inline them when appropriate. Eliminating
them just makes the code more complicated.
Yes, makes sense. I'm leaving the change in now, because I don't
see a strong reason to undo the change, and the two functions
will likely get collapsed into a single line each after the move
to the phy subsystem is complete.
static int s5p_ehci_probe(struct platform_device *pdev)
{
+ struct usb_hcd *hcd ;
struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
+ const struct hc_driver *driver = s5p_ehci_hc_driver;
struct s5p_ehci_hcd *s5p_ehci;
- struct usb_hcd *hcd;
What's the reason for these changes? There's no need for the driver
variable, and improper whitespace was added to the declaration of
hcd.
I'll let Manjunath answer this, I have no idea. My suspicion is that
it was a misguided attempt to work around a checkpatch warning for
an overly long line.
I've reverted the above changes now for v4.
@@ -153,16 +117,12 @@ static int s5p_ehci_probe(struct platform_device
*pdev)
s5p_ehci-otg = phy-otg;
}
- s5p_ehci-dev = pdev-dev;
-
- hcd = usb_create_hcd(s5p_ehci_hc_driver, pdev-dev,
- dev_name(pdev-dev));
+ hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
s5p_ehci is not initialized correctly. The devm_kzalloc() call was
left in and to_s5p_ehci() was not called.
Oh crap.
I checked that Manjunath had fixed this bug in the other drivers, but
missed it here. I updated it for v4 now.
Was anybody able to test this patch?
I thought that Manjunath had received hardware for it now, but it's pretty
evident that the patch was not tested. The Ack from Jingoo Han was for an
older version that did not contain the change to .extra_priv_size.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] USB: EHCI: make ehci-atmel a separate driver
On Friday 29 March 2013, Alan Stern wrote: While not absolutely necessary, it would be nice to have the #include files in alphabetical order. + +#include ehci.h + +#define DRIVER_DESC EHCI atmel driver atmel should have a capital 'A'. Ok, added these changes for v4 along with Nicolas' Ack, and removed the call to ehci_shutdown. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/7] USB: EHCI: make ehci-msm a separate driver
On Friday 29 March 2013, Alan Stern wrote: On Thu, 28 Mar 2013, Arnd Bergmann wrote: This patch is good. However the ehci-msm driver itself is not. While checking through the code, I was struck by the fact that it never calls usb_add_hcd() or usb_remove_hcd(). Obviously the driver cannot work properly. In addition, it stores the PHY pointer in a global variable. (ehci-atmel does much the same thing for its clocks.) This means the driver cannot be used on a system having more than one EHCI controller. Maybe this doesn't matter, though. Maybe somebody would like to fix and test it... I'm not too surprised. The driver was added the last time that the MSM maintainers started a serious attempt to get a lot of their code mainlined, a little over two years ago. While there is some activity from Qualcomm in specific areas of the code every now and then, they literally have thousands of patches on top of the kernel that they use in actual products and I would not expect a mainline kernel to actually work on any recent Qualcomm hardware. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/7] USB: OHCI: avoid conflicting platform drivers
On Friday 29 March 2013, Alan Stern wrote: I have not checked the details of all the changes; however, the basic idea is okay as a stop-gap measure. Ok, thanks. I guess this means the onus is now on me to split up ohci-hcd into a central library and separate bus drivers, like ehci-hcd... The original plan in my teams was that Manjunath would do that after he was done with the simple conversion of the EHCI drivers. I think we can all agree now that it's better if you at least the groundwork instead. Please let us know if you would like Manjunath to continue with splitting out the OHCI back-ends into separate drivers, or if you think that there is no point given the quality of the earlier patches. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/6] USB: EHCI: make ehci-orion a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. While we are here, use the opportunity to disabiguate the two Marvell EHCI controller implementations in Kconfig. In V3: 1.More detail provided in commit message regarding this patch. 2.Replaced hcd_name string ehci-orion into orion-ehci. 3.MODULE_LICENSE is GPL v2. 4.In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Jason Cooper ja...@lakedaemon.net Tested-by: Andrew Lunn and...@lunn.ch Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Russell King li...@arm.linux.org.uk Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org --- drivers/usb/host/Kconfig | 17 - drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +--- drivers/usb/host/ehci-orion.c | 82 ++- 4 files changed, 53 insertions(+), 53 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 2f68221..e5649c1 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -163,6 +163,17 @@ config USB_EHCI_HCD_OMAP Enables support for the on-chip EHCI controller on OMAP3 and later chips. +config USB_EHCI_HCD_ORION + tristate Support for Marvell EBU on-chip EHCI USB controller + depends on USB_EHCI_HCD PLAT_ORION + default y + ---help--- + Enables support for the on-chip EHCI controller on Marvell's + embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP, + Armada 370. This is different from the EHCI implementation + on Marvell's mobile PXA and MMP SoC, see EHCI support for + Marvell PXA/MMP USB controller for those. + config USB_EHCI_MSM bool Support for MSM on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_MSM @@ -206,13 +217,17 @@ config USB_EHCI_S5P Enable support for the S5P SOC's on-chip EHCI controller. config USB_EHCI_MV - bool EHCI support for Marvell on-chip controller + bool EHCI support for Marvell PXA/MMP USB controller depends on USB_EHCI_HCD (ARCH_PXA || ARCH_MMP) select USB_EHCI_ROOT_HUB_TT ---help--- Enables support for Marvell (including PXA and MMP series) on-chip USB SPH and OTG controller. SPH is a single port host, and it can only be EHCI host. OTG is controller that can switch to host mode. + Note that this driver will not work on Marvell's other EHCI + controller used by the EBU-type SoCs including Orion, Kirkwood, + Dova, Armada 370 and Armada XP. See Support for Marvell EBU + on-chip EHCI USB controller for those. config USB_W90X900_EHCI bool W90X900(W90P910) EHCI support diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 56de410..9492f50 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_EHCI_PCI)+= ehci-pci.o obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o +obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index b12b97d..1f97268 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1249,11 +1249,6 @@ MODULE_LICENSE (GPL); #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver #endif -#ifdef CONFIG_PLAT_ORION -#include ehci-orion.c -#definePLATFORM_DRIVER
[PATCH v4 3/6] USB: EHCI: make ehci-s5p a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Samsung S5P/EXYNOS host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before S5P/EXYNOS can be booted with a multi-platform kernel. We currently expect those to get merged for 3.10. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the s5p bus glue. In V4 (arnd) - revert some of the pointless changes. - fix allocation of s5p specific data structure. In V3: -Detail commit message added here,why this patch is required. -MODULE_LICENSE is GPL v2. -Added .extra_priv_size to eliminate the separate allocation of the s5p_ehci_hcd structure and removed .reset function pointer initialization. -Arranged #include's in alphabetical order. -After using extra_priv_size initialization,struct usb_hcd *hcd is redundant that's why removed from the prob function. -Eliminated s5p_ehci_phy_enable,contents of statements moved into the s5p_ehci_probe -Eliminated s5p_ehci_phy_disable, contents of statements moved into the s5p_ehci_remove. In V2: Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Acked-by: Jingoo Han jg1@samsung.com Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Kukjin Kim kgene@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: linux-usb@vger.kernel.org Signed-off-by: Arnd Bergmann a...@arndb.de --- drivers/usb/host/Kconfig| 5 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +- drivers/usb/host/ehci-s5p.c | 164 +--- 4 files changed, 85 insertions(+), 91 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 4723f79..98abec0f 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -219,10 +219,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_S5P - boolean S5P EHCI support + tristate EHCI support for Samsung S5P/EXYNOS SoC Series depends on USB_EHCI_HCD PLAT_S5P help -Enable support for the S5P SOC's on-chip EHCI controller. + Enable support for the Samsung S5P and Exynos3/4/5 SOC's + on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell PXA/MMP USB controller diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 3e02471..3d895b5 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o +obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c8c70a1..8f1f4b4 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1284,11 +1284,6 @@ MODULE_LICENSE (GPL); #define PLATFORM_DRIVERtegra_ehci_driver #endif -#ifdef CONFIG_USB_EHCI_S5P -#include ehci-s5p.c -#define PLATFORM_DRIVERs5p_ehci_driver -#endif - #ifdef CONFIG_SPARC_LEON #include ehci-grlib.c #define PLATFORM_DRIVERehci_grlib_driver @@ -1311,6 +1306,7 @@ MODULE_LICENSE (GPL); !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \ + !IS_ENABLED(CONFIG_USB_EHCI_S5P) \ !defined(PLATFORM_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(OF_PLATFORM_DRIVER) \ diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index 738490e..3147984 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -13,13 +13,24 @@ */ #include linux/clk.h +#include linux/dma-mapping.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h #include linux/of.h -#include linux/platform_device.h #include linux/of_gpio.h +#include linux/platform_device.h #include linux/platform_data/usb-ehci-s5p.h #include linux/usb/phy.h #include linux/usb/samsung_usb_phy.h #include plat/usb-phy.h +#include linux/usb.h +#include linux/usb/hcd.h +#include linux/usb/otg.h + +#include ehci.h + +#define DRIVER_DESC EHCI s5p driver #define EHCI_INSNREG00(base) (base + 0x90) #define EHCI_INSNREG00_ENA_INCR16 (0x1 25) @@ -30,65 +41,17
[PATCH v4 5/6] USB: EHCI: make ehci-msm a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Qualcomm QSD/MSM on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Qualcomm QSD/MSM
can be booted with a multi-platform kernel, which is not expected before
3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the msm bus glue.
In V3:
1.Detail commit message added here,why this patch is required.
2.Arranged #include's in alphabetical order.
3.drive.name initialized hcd_name[] = ehci-msm in platform_driver structure
initialization
instead of msm-ehci,that is reason it was breaking in EHCI USB testing.this
one fixed in V3.
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Brian Swetland swetl...@google.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +---
drivers/usb/host/ehci-msm.c | 85 -
4 files changed, 40 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f6f7872..b9cdbbb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -191,7 +191,7 @@ config USB_EHCI_HCD_AT91
Atmel chips.
config USB_EHCI_MSM
- bool Support for MSM on-chip EHCI USB controller
+ tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
select USB_EHCI_ROOT_HUB_TT
select USB_MSM_OTG
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 368d3eb..4fb73c1 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
+obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index ccc78ab..2e0c2bd 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1259,11 +1259,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_USB_EHCI_MSM
-#include ehci-msm.c
-#define PLATFORM_DRIVERehci_msm_driver
-#endif
-
#ifdef CONFIG_TILE_USB
#include ehci-tilegx.c
#definePLATFORM_DRIVER ehci_hcd_tilegx_driver
@@ -1303,6 +1298,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) \
+ !IS_ENABLED(CONFIG_USB_EHCI_MSM) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 88a49c8..3b45f0c 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -22,16 +22,26 @@
* along with this program; if not, you can find it at http://www.fsf.org
*/
-#include linux/platform_device.h
#include linux/clk.h
#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
-
#include linux/usb/otg.h
#include linux/usb/msm_hsusb_hw.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
#define MSM_USB_BASE (hcd-regs)
+#define DRIVER_DESC Qualcomm On-Chip EHCI Host Controller
+
+static const char hcd_name[] = ehci-msm;
+static struct hc_driver __read_mostly msm_hc_driver;
static struct usb_phy *phy;
static int ehci_msm_reset(struct usb_hcd *hcd)
@@ -56,52 +66,6 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
return 0;
}
-static struct hc_driver msm_hc_driver = {
- .description= hcd_name,
- .product_desc = Qualcomm On-Chip EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_USB2 | HCD_MEMORY,
-
- .reset = ehci_msm_reset,
- .start = ehci_run,
-
- .stop
[PATCH v4 2/6] USB: EHCI: make ehci-spear a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V4 (arnd):
- renamed all 'struct spear_ehci' pointers from 'ehci' to the
less ambiguous 'sehci'.
- folded trivial spear_start_ehci/spear_stop_ehci functions into
callers.
- brought back initialization of ehci-caps.
In V3:
- Detailed commit message added here about why this patch is required.
- Eliminated ehci_spear_setup routine because hcd registers can
be directly set in the spear_ehci_hcd_drv_probe function.
- spear_overrides struct initialized.
- Converted to using .extra_priv_size for allocating spear_ehci,
and updated all users of that structure.
- to_spear_ehci() macro modified for spear_ehci.
In V2:
- Replaced spear as SPEAr everywhere, leaving functions/variables/config
options.
Signed-off-by: Deepak Saxena dsax...@linaro.org
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Viresh Kumar viresh.li...@gmail.com
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Shiraz Hashim shiraz.has...@st.com
Cc: linux-usb@vger.kernel.org
Cc: spear-de...@list.st.com
---
drivers/usb/host/Kconfig | 8 +++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-spear.c | 115 +++---
4 files changed, 61 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e5649c1..4723f79 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -174,6 +174,14 @@ config USB_EHCI_HCD_ORION
on Marvell's mobile PXA and MMP SoC, see EHCI support for
Marvell PXA/MMP USB controller for those.
+config USB_EHCI_HCD_SPEAR
+tristate Support for ST SPEAr on-chip EHCI USB controller
+depends on USB_EHCI_HCD PLAT_SPEAR
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ ST SPEAr chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9492f50..3e02471 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
+obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1f97268..c8c70a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1264,11 +1264,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_PLAT_SPEAR
-#include ehci-spear.c
-#define PLATFORM_DRIVERspear_ehci_hcd_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_MSM
#include ehci-msm.c
#define PLATFORM_DRIVERehci_msm_driver
@@ -1315,6 +1310,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 210bb67..61ecfb3 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -1,5 +1,5 @@
/*
-* Driver for EHCI HCD on SPEAR SOC
+* Driver for EHCI HCD on SPEAr SOC
*
* Copyright (C) 2010 ST Micro Electronics,
* Deepak Sikri deepak.si...@st.com
@@ -12,71 +12,30 @@
*/
#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/io.h
#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
#include linux/pm.h
+#include linux/usb.h
+#include linux/usb/hcd.h
-struct spear_ehci {
- struct ehci_hcd ehci;
- struct clk *clk;
-};
-
-#define to_spear_ehci(hcd) (struct spear_ehci *)hcd_to_ehci(hcd)
+#include ehci.h
-static void spear_start_ehci(struct spear_ehci *ehci
[PATCH v4 0/6] USB EHCI multiplatform conversion
Hi Alan, This is a quick update to v3, addressing all issues you pointed in yesterday's review. Thanks for taking a thorough look on short notice on a public holiday! Arnd Arnd Bergmann (1): USB: OHCI: avoid conflicting platform drivers Manjunath Goudar (5): USB: EHCI: make ehci-orion a separate driver USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-msm a separate driver drivers/usb/host/Kconfig | 40 +-- drivers/usb/host/Makefile | 5 ++ drivers/usb/host/ehci-atmel.c | 88 +++ drivers/usb/host/ehci-hcd.c | 30 ++-- drivers/usb/host/ehci-msm.c | 85 ++ drivers/usb/host/ehci-orion.c | 82 + drivers/usb/host/ehci-s5p.c | 164 +- drivers/usb/host/ehci-spear.c | 115 + drivers/usb/host/ohci-hcd.c | 136 ++- 9 files changed, 408 insertions(+), 337 deletions(-) -- 1.8.1.2 Cc: Alan Stern st...@rowland.harvard.edu Cc: Bryan Huntsman bry...@codeaurora.org Cc: David Brown dav...@codeaurora.org Cc: Greg KH g...@kroah.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Kukjin Kim kgene@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Manjunath Goudar manjunath.gou...@linaro.org Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Shiraz Hashim shiraz.has...@st.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: spear-de...@list.st.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/6] USB: EHCI: make ehci-atmel a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Atmel host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Atmel can be
booted with a multi-platform kernel. This is currently planned for
Linux-3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the Atmel bus glue.
In V4 (arnd):
- reordered #include statements.
- removed call to ehci_shutdown.
In V3:
-Detailed commit message added here about why this patch is required.
-Replaced hcd_name string ehci-atmel to atmel-ehci.
-In Makefile inserted Blank line that separates the EHCI drivers from the
following non-EHCI drivers.
-Export ehci_shutdown symbol as it is needed by the Atmel driver.
-Eliminated ehci_atmel_setup routine beacuse hcd registers
directly setting in ehci_atmel_drv_probe function.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function
'ehci_shutdown'
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: Andrew Victor li...@maxim.org.za
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-atmel.c | 88 ---
drivers/usb/host/ehci-hcd.c | 6 +--
4 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 98abec0f..f6f7872 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -182,6 +182,14 @@ config USB_EHCI_HCD_SPEAR
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
+config USB_EHCI_HCD_AT91
+tristate Support for Atmel on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3d895b5..368d3eb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index f3beac4..6642009 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -12,9 +12,22 @@
*/
#include linux/clk.h
-#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI Atmel driver
+
+static const char hcd_name[] = ehci-atmel;
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -50,51 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
/*-*/
-static int ehci_atmel_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci-caps = hcd-regs;
-
- return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = Atmel EHCI UHP HS,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue
[PATCH v4 6/6] USB: OHCI: avoid conflicting platform drivers
Like the EHCI driver, OHCI supports a large number of different platform glue drivers by directly including them, which causes problems with conflicting macro definitions in some cases. As more ARM architecture specific back-ends are required to coexist in a single build, we should split those out into separate drivers. Unfortunately, the infrastructure for that is still under development, so to give us more time, this uses a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend, just like we already do on PowerPC and some of the other ARM platforms. In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict without this patch, but over time we would get more of them, so this is a way to avoid having to patch the driver every time it breaks. We should still split out all back-ends into separate loadable modules, but that work is only needed to improve code size and cleanliness after this patch, not for correctness. While we're here, this fixes the incorrectly sorted error path for the OMAP1 and OMAP3 backends to ensure we always unregister the exact set of drivers that were registered before erroring out. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Manjunath Goudar manjunath.gou...@linaro.org Cc: Greg KH g...@kroah.com Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-hcd.c | 136 ++-- 1 file changed, 118 insertions(+), 18 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 180a2b0..9e6de95 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1102,12 +1102,12 @@ MODULE_LICENSE (GPL); #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX) #include ohci-s3c2410.c -#define PLATFORM_DRIVERohci_hcd_s3c2410_driver +#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver #endif #ifdef CONFIG_USB_OHCI_EXYNOS #include ohci-exynos.c -#define PLATFORM_DRIVERexynos_ohci_driver +#define EXYNOS_PLATFORM_DRIVER exynos_ohci_driver #endif #ifdef CONFIG_USB_OHCI_HCD_OMAP1 @@ -1127,25 +1127,24 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_ARCH_EP93XX #include ohci-ep93xx.c -#define PLATFORM_DRIVERohci_hcd_ep93xx_driver +#define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver #endif #ifdef CONFIG_ARCH_AT91 #include ohci-at91.c -#define PLATFORM_DRIVERohci_hcd_at91_driver +#define AT91_PLATFORM_DRIVER ohci_hcd_at91_driver #endif #ifdef CONFIG_ARCH_LPC32XX #include ohci-nxp.c -#define PLATFORM_DRIVERusb_hcd_nxp_driver +#define NXP_PLATFORM_DRIVERusb_hcd_nxp_driver #endif #ifdef CONFIG_ARCH_DAVINCI_DA8XX #include ohci-da8xx.c -#define PLATFORM_DRIVERohci_hcd_da8xx_driver +#define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver #endif - #ifdef CONFIG_USB_OHCI_HCD_PPC_OF #include ohci-ppc-of.c #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver @@ -1153,7 +1152,7 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_PLAT_SPEAR #include ohci-spear.c -#define PLATFORM_DRIVERspear_ohci_hcd_driver +#define SPEAR_PLATFORM_DRIVER spear_ohci_hcd_driver #endif #ifdef CONFIG_PPC_PS3 @@ -1199,7 +1198,14 @@ MODULE_LICENSE (GPL); !defined(SA_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(SM501_OHCI_DRIVER) \ - !defined(TMIO_OHCI_DRIVER) + !defined(TMIO_OHCI_DRIVER) \ + !defined(S3C2410_PLATFORM_DRIVER) \ + !defined(EXYNOS_PLATFORM_DRIVER) \ + !defined(EP93XX_PLATFORM_DRIVER) \ + !defined(AT91_PLATFORM_DRIVER) \ + !defined(NXP_PLATFORM_DRIVER) \ + !defined(DAVINCI_PLATFORM_DRIVER) \ + !defined(SPEAR_PLATFORM_DRIVER) #error missing bus glue for ohci-hcd #endif @@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void) goto error_tmio; #endif +#ifdef S3C2410_PLATFORM_DRIVER + retval = platform_driver_register(S3C2410_PLATFORM_DRIVER); + if (retval 0) + goto error_s3c2410; +#endif + +#ifdef EXYNOS_PLATFORM_DRIVER + retval = platform_driver_register(EXYNOS_PLATFORM_DRIVER); + if (retval 0) + goto error_exynos; +#endif + +#ifdef EP93XX_PLATFORM_DRIVER + retval = platform_driver_register(EP93XX_PLATFORM_DRIVER); + if (retval 0) + goto error_ep93xx; +#endif + +#ifdef AT91_PLATFORM_DRIVER + retval = platform_driver_register(AT91_PLATFORM_DRIVER); + if (retval 0) + goto error_at91; +#endif + +#ifdef NXP_PLATFORM_DRIVER + retval = platform_driver_register(NXP_PLATFORM_DRIVER); + if (retval 0) + goto error_nxp; +#endif + +#ifdef DAVINCI_PLATFORM_DRIVER + retval = platform_driver_register(DAVINCI_PLATFORM_DRIVER); + if (retval 0) + goto error_davinci; +#endif + +#ifdef SPEAR_PLATFORM_DRIVER + retval
Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
On Saturday 30 March 2013, Arnd Bergmann wrote: In V3: -Detailed commit message added here about why this patch is required. -Eliminated ehci_spear_setup routine beacuse hcd registers directly setting in spear_ehci_hcd_drv_probe function. Fix the grammar, please. Done. I agree some of this is hardly legible. I realized later that the other patches have similarly screwed up changelogs. I'll send a new version once you've commented on v4, so in case there is anything else I missed I'm not spamming everyone another time. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 5/6] USB: EHCI: make ehci-msm a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Qualcomm QSD/MSM on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Qualcomm QSD/MSM
can be booted with a multi-platform kernel, which is not expected before
3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the msm bus glue.
In V5 (arnd):
- add FIXME about missing usb_add_hcd() or usb_remove_hcd() calls
In V3:
- Detailed commit message added here describing why this patch is required.
- Arranged #include's in alphabetical order.
- driver.name initialized hcd_name[] = ehci-msm in platform_driver
structure initialization instead of msm-ehci, which was the reason
why it broke in EHCI USB testing
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: David Brown dav...@codeaurora.org
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-msm.c | 89 +
4 files changed, 44 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f6f7872..b9cdbbb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -191,7 +191,7 @@ config USB_EHCI_HCD_AT91
Atmel chips.
config USB_EHCI_MSM
- bool Support for MSM on-chip EHCI USB controller
+ tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
select USB_EHCI_ROOT_HUB_TT
select USB_MSM_OTG
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 368d3eb..4fb73c1 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
+obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index ccc78ab..2e0c2bd 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1259,11 +1259,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_USB_EHCI_MSM
-#include ehci-msm.c
-#define PLATFORM_DRIVERehci_msm_driver
-#endif
-
#ifdef CONFIG_TILE_USB
#include ehci-tilegx.c
#definePLATFORM_DRIVER ehci_hcd_tilegx_driver
@@ -1303,6 +1298,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!IS_ENABLED(CONFIG_USB_EHCI_S5P) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_AT91) \
+ !IS_ENABLED(CONFIG_USB_EHCI_MSM) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 88a49c8..93f062c 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -22,16 +22,26 @@
* along with this program; if not, you can find it at http://www.fsf.org
*/
-#include linux/platform_device.h
#include linux/clk.h
#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
-
#include linux/usb/otg.h
#include linux/usb/msm_hsusb_hw.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
#define MSM_USB_BASE (hcd-regs)
+#define DRIVER_DESC Qualcomm On-Chip EHCI Host Controller
+
+static const char hcd_name[] = ehci-msm;
+static struct hc_driver __read_mostly msm_hc_driver;
static struct usb_phy *phy;
static int ehci_msm_reset(struct usb_hcd *hcd)
@@ -56,52 +66,6 @@ static int ehci_msm_reset(struct usb_hcd *hcd)
return 0;
}
-static struct hc_driver msm_hc_driver = {
- .description= hcd_name,
- .product_desc = Qualcomm On-Chip EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
-* generic hardware linkage
-*/
- .irq= ehci_irq,
- .flags = HCD_USB2 | HCD_MEMORY,
-
- .reset = ehci_msm_reset,
- .start = ehci_run,
-
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
-* managing i/o requests
[PATCH V5 0/6] USB: EHCI multiplatform for 3.10
Hi Greg, Here are the EHCI patches that I think are good for inclusion in 3.10, I hope you are willing to include them after the debacle over these patches in 3.9. The patches are all logically independent but sorted by priority, so decide for yourself how many you want to take, starting at the first one. The first six patches all have an Ack from Alan Stern and from the respective ARM platform maintainers. * The first patch (Orion) fixes a preexisting bug because the driver conflicts with the OMAP and vt8500 back-ends in 3.9. Both of those are fixed in usb-next now, but the same problem comes back with any other platform we enable for ARM multiplatform support. * The second patch fixes a problem that will happen in 3.10 as we enable SPEAr multiplatform support. * S5P/Exynos multiplatform support is not yet part of linux-next, but I still have hope for 3.10, so the third patch will be needed as well then. * The ehci-atmel patch will not be needed in 3.10 but quite likely in 3.11. * I have no time line for MSM multiplatform support, but we will get there eventually and the driver is broken already so there is no risk of regressions. * The final patch is from me and still waiting for an Ack from Alan Stern, so please wait for his feedback before applying that one. There is one more patch coming for ehci-tegra. I've forwarded Manjunath's work on that driver to the Tegra developers, who will test it and send it directly to you. The version I had was incomplete. Arnd Arnd Bergmann (1): USB: OHCI: avoid conflicting platform drivers Manjunath Goudar (5): USB: EHCI: make ehci-orion a separate driver USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-msm a separate driver drivers/usb/host/Kconfig | 40 +-- drivers/usb/host/Makefile | 5 ++ drivers/usb/host/ehci-atmel.c | 88 +++ drivers/usb/host/ehci-hcd.c | 30 ++-- drivers/usb/host/ehci-msm.c | 89 +++ drivers/usb/host/ehci-orion.c | 82 + drivers/usb/host/ehci-s5p.c | 164 +- drivers/usb/host/ehci-spear.c | 115 + drivers/usb/host/ohci-hcd.c | 136 ++- 9 files changed, 412 insertions(+), 337 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 3/6] USB: EHCI: make ehci-s5p a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Samsung S5P/EXYNOS host controller driver from ehci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; however, note that other changes are still needed before S5P/EXYNOS can be booted with a multi-platform kernel. We currently expect those to get merged for 3.10. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the s5p bus glue. In V4 (arnd) - revert some of the pointless changes. - fix allocation of s5p specific data structure. In V3: - Detailed commit message added here, why this patch is required. - MODULE_LICENSE is GPL v2. - Added .extra_priv_size to eliminate the separate allocation of the s5p_ehci_hcd structure and removed .reset function pointer initialization. - Arranged #include's in alphabetical order. - After using extra_priv_size initialization, struct usb_hcd *hcd is redundant and can be removed from the probe function. - Eliminated s5p_ehci_phy_enable,contents of statements moved into the s5p_ehci_probe - Eliminated s5p_ehci_phy_disable, contents of statements moved into the s5p_ehci_remove. In V2: - Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Acked-by: Jingoo Han jg1@samsung.com Acked-by: Alan Stern st...@rowland.harvard.edu Cc: Kukjin Kim kgene@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Arnd Bergmann a...@arndb.de --- drivers/usb/host/Kconfig| 5 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +- drivers/usb/host/ehci-s5p.c | 164 +--- 4 files changed, 85 insertions(+), 91 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 4723f79..98abec0f 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -219,10 +219,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_S5P - boolean S5P EHCI support + tristate EHCI support for Samsung S5P/EXYNOS SoC Series depends on USB_EHCI_HCD PLAT_S5P help -Enable support for the S5P SOC's on-chip EHCI controller. + Enable support for the Samsung S5P and Exynos3/4/5 SOC's + on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell PXA/MMP USB controller diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 3e02471..3d895b5 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o +obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c8c70a1..8f1f4b4 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1284,11 +1284,6 @@ MODULE_LICENSE (GPL); #define PLATFORM_DRIVERtegra_ehci_driver #endif -#ifdef CONFIG_USB_EHCI_S5P -#include ehci-s5p.c -#define PLATFORM_DRIVERs5p_ehci_driver -#endif - #ifdef CONFIG_SPARC_LEON #include ehci-grlib.c #define PLATFORM_DRIVERehci_grlib_driver @@ -1311,6 +1306,7 @@ MODULE_LICENSE (GPL); !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \ + !IS_ENABLED(CONFIG_USB_EHCI_S5P) \ !defined(PLATFORM_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(OF_PLATFORM_DRIVER) \ diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index 738490e..3147984 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -13,13 +13,24 @@ */ #include linux/clk.h +#include linux/dma-mapping.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h #include linux/of.h -#include linux/platform_device.h #include linux/of_gpio.h +#include linux/platform_device.h #include linux/platform_data/usb-ehci-s5p.h #include linux/usb/phy.h #include linux/usb/samsung_usb_phy.h #include plat/usb-phy.h +#include linux/usb.h +#include linux/usb/hcd.h +#include linux/usb/otg.h + +#include ehci.h + +#define DRIVER_DESC EHCI s5p driver #define EHCI_INSNREG00(base) (base + 0x90) #define EHCI_INSNREG00_ENA_INCR16 (0x1 25) @@ -30,65 +41,17 @@ (EHCI_INSNREG00_ENA_INCR16 | EHCI_INSNREG00_ENA_INCR8 | \ EHCI_INSNREG00_ENA_INCR4
[PATCH V5 6/6] USB: OHCI: avoid conflicting platform drivers
Like the EHCI driver, OHCI supports a large number of different platform glue drivers by directly including them, which causes problems with conflicting macro definitions in some cases. As more ARM architecture specific back-ends are required to coexist in a single build, we should split those out into separate drivers. Unfortunately, the infrastructure for that is still under development, so to give us more time, this uses a separate *_PLATFORM_DRIVER macro for each ARM specific OHCI backend, just like we already do on PowerPC and some of the other ARM platforms. In linux-3.10, only the SPEAr and CNS3xxx back-ends would actually conflict without this patch, but over time we would get more of them, so this is a way to avoid having to patch the driver every time it breaks. We should still split out all back-ends into separate loadable modules, but that work is only needed to improve code size and cleanliness after this patch, not for correctness. While we're here, this fixes the incorrectly sorted error path for the OMAP1 and OMAP3 backends to ensure we always unregister the exact set of drivers that were registered before erroring out. Signed-off-by: Arnd Bergmann a...@arndb.de --- drivers/usb/host/ohci-hcd.c | 136 ++-- 1 file changed, 118 insertions(+), 18 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 180a2b0..9e6de95 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1102,12 +1102,12 @@ MODULE_LICENSE (GPL); #if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX) #include ohci-s3c2410.c -#define PLATFORM_DRIVERohci_hcd_s3c2410_driver +#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver #endif #ifdef CONFIG_USB_OHCI_EXYNOS #include ohci-exynos.c -#define PLATFORM_DRIVERexynos_ohci_driver +#define EXYNOS_PLATFORM_DRIVER exynos_ohci_driver #endif #ifdef CONFIG_USB_OHCI_HCD_OMAP1 @@ -1127,25 +1127,24 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_ARCH_EP93XX #include ohci-ep93xx.c -#define PLATFORM_DRIVERohci_hcd_ep93xx_driver +#define EP93XX_PLATFORM_DRIVER ohci_hcd_ep93xx_driver #endif #ifdef CONFIG_ARCH_AT91 #include ohci-at91.c -#define PLATFORM_DRIVERohci_hcd_at91_driver +#define AT91_PLATFORM_DRIVER ohci_hcd_at91_driver #endif #ifdef CONFIG_ARCH_LPC32XX #include ohci-nxp.c -#define PLATFORM_DRIVERusb_hcd_nxp_driver +#define NXP_PLATFORM_DRIVERusb_hcd_nxp_driver #endif #ifdef CONFIG_ARCH_DAVINCI_DA8XX #include ohci-da8xx.c -#define PLATFORM_DRIVERohci_hcd_da8xx_driver +#define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver #endif - #ifdef CONFIG_USB_OHCI_HCD_PPC_OF #include ohci-ppc-of.c #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver @@ -1153,7 +1152,7 @@ MODULE_LICENSE (GPL); #ifdef CONFIG_PLAT_SPEAR #include ohci-spear.c -#define PLATFORM_DRIVERspear_ohci_hcd_driver +#define SPEAR_PLATFORM_DRIVER spear_ohci_hcd_driver #endif #ifdef CONFIG_PPC_PS3 @@ -1199,7 +1198,14 @@ MODULE_LICENSE (GPL); !defined(SA_DRIVER) \ !defined(PS3_SYSTEM_BUS_DRIVER) \ !defined(SM501_OHCI_DRIVER) \ - !defined(TMIO_OHCI_DRIVER) + !defined(TMIO_OHCI_DRIVER) \ + !defined(S3C2410_PLATFORM_DRIVER) \ + !defined(EXYNOS_PLATFORM_DRIVER) \ + !defined(EP93XX_PLATFORM_DRIVER) \ + !defined(AT91_PLATFORM_DRIVER) \ + !defined(NXP_PLATFORM_DRIVER) \ + !defined(DAVINCI_PLATFORM_DRIVER) \ + !defined(SPEAR_PLATFORM_DRIVER) #error missing bus glue for ohci-hcd #endif @@ -1277,9 +1283,79 @@ static int __init ohci_hcd_mod_init(void) goto error_tmio; #endif +#ifdef S3C2410_PLATFORM_DRIVER + retval = platform_driver_register(S3C2410_PLATFORM_DRIVER); + if (retval 0) + goto error_s3c2410; +#endif + +#ifdef EXYNOS_PLATFORM_DRIVER + retval = platform_driver_register(EXYNOS_PLATFORM_DRIVER); + if (retval 0) + goto error_exynos; +#endif + +#ifdef EP93XX_PLATFORM_DRIVER + retval = platform_driver_register(EP93XX_PLATFORM_DRIVER); + if (retval 0) + goto error_ep93xx; +#endif + +#ifdef AT91_PLATFORM_DRIVER + retval = platform_driver_register(AT91_PLATFORM_DRIVER); + if (retval 0) + goto error_at91; +#endif + +#ifdef NXP_PLATFORM_DRIVER + retval = platform_driver_register(NXP_PLATFORM_DRIVER); + if (retval 0) + goto error_nxp; +#endif + +#ifdef DAVINCI_PLATFORM_DRIVER + retval = platform_driver_register(DAVINCI_PLATFORM_DRIVER); + if (retval 0) + goto error_davinci; +#endif + +#ifdef SPEAR_PLATFORM_DRIVER + retval = platform_driver_register(SPEAR_PLATFORM_DRIVER); + if (retval 0) + goto error_spear; +#endif + return retval; /* Error
[PATCH V5 2/6] USB: EHCI: make ehci-spear a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the SPEAr host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before SPEAr can be
booted with a multi-platform kernel, but they are queued in the
arm-soc tree for 3.10.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the SPEAr bus glue.
In V4 (arnd):
- renamed all 'struct spear_ehci' pointers from 'ehci' to the
less ambiguous 'sehci'.
- folded trivial spear_start_ehci/spear_stop_ehci functions into
callers.
- brought back initialization of ehci-caps.
In V3:
- Detailed commit message added here about why this patch is required.
- Eliminated ehci_spear_setup routine because hcd registers can
be directly set in the spear_ehci_hcd_drv_probe function.
- spear_overrides struct initialized.
- Converted to using .extra_priv_size for allocating spear_ehci,
and updated all users of that structure.
- to_spear_ehci() macro modified for spear_ehci.
In V2:
- Replaced spear as SPEAr everywhere, leaving functions/variables/config
options.
Signed-off-by: Deepak Saxena dsax...@linaro.org
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Viresh Kumar viresh.li...@gmail.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Cc: Shiraz Hashim shiraz.has...@st.com
Cc: spear-de...@list.st.com
---
drivers/usb/host/Kconfig | 8 +++
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +--
drivers/usb/host/ehci-spear.c | 115 +++---
4 files changed, 61 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e5649c1..4723f79 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -174,6 +174,14 @@ config USB_EHCI_HCD_ORION
on Marvell's mobile PXA and MMP SoC, see EHCI support for
Marvell PXA/MMP USB controller for those.
+config USB_EHCI_HCD_SPEAR
+tristate Support for ST SPEAr on-chip EHCI USB controller
+depends on USB_EHCI_HCD PLAT_SPEAR
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ ST SPEAr chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9492f50..3e02471 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
+obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 1f97268..c8c70a1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1264,11 +1264,6 @@ MODULE_LICENSE (GPL);
#define PLATFORM_DRIVERehci_octeon_driver
#endif
-#ifdef CONFIG_PLAT_SPEAR
-#include ehci-spear.c
-#define PLATFORM_DRIVERspear_ehci_hcd_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_MSM
#include ehci-msm.c
#define PLATFORM_DRIVERehci_msm_driver
@@ -1315,6 +1310,7 @@ MODULE_LICENSE (GPL);
!IS_ENABLED(CONFIG_USB_EHCI_MXC) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) \
!IS_ENABLED(CONFIG_USB_EHCI_HCD_ORION) \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_SPEAR) \
!defined(PLATFORM_DRIVER) \
!defined(PS3_SYSTEM_BUS_DRIVER) \
!defined(OF_PLATFORM_DRIVER) \
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 210bb67..61ecfb3 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -1,5 +1,5 @@
/*
-* Driver for EHCI HCD on SPEAR SOC
+* Driver for EHCI HCD on SPEAr SOC
*
* Copyright (C) 2010 ST Micro Electronics,
* Deepak Sikri deepak.si...@st.com
@@ -12,71 +12,30 @@
*/
#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/io.h
#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
#include linux/pm.h
+#include linux/usb.h
+#include linux/usb/hcd.h
-struct spear_ehci {
- struct ehci_hcd ehci;
- struct clk *clk;
-};
-
-#define to_spear_ehci(hcd) (struct spear_ehci *)hcd_to_ehci(hcd)
+#include ehci.h
-static void spear_start_ehci(struct spear_ehci *ehci)
-{
- clk_prepare_enable(ehci-clk);
-}
+#define DRIVER_DESC EHCI SPEAr
[PATCH V5 1/6] USB: EHCI: make ehci-orion a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org Separate the Orion host controller driver from ehci-hcd host code into its own driver module because of following reason. With the multiplatform changes in arm-soc tree, it becomes possible to enable the mvebu platform (which uses ehci-orion) at the same time as other platforms that require a conflicting EHCI bus glue. At the moment, this results in a warning like drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined [enabled by default] drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable] and an ehci driver that only works on one of them. With the infrastructure added by Alan Stern in patch 3e0232039 USB: EHCI: prepare to make ehci-hcd a library module, we can avoid this problem by turning a bus glue into a separate module, as we do here for the orion bus glue. An earlier version of this patch was included in 3.9 but caused a regression there, which has subsequently been fixed. While we are here, use the opportunity to disabiguate the two Marvell EHCI controller implementations in Kconfig. In V4 (arnd): - Improve Kconfig text In V3: - More detail provided in commit message regarding this patch. - Replaced hcd_name string ehci-orion into orion-ehci. - MODULE_LICENSE is GPL v2. - In ehci_init_driver calling second argument passed as NULL instead of ehci_orion_overrides because ehci_orion_overrides is removed. In V2: - Tegra patch related changes removed from this patch. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Jason Cooper ja...@lakedaemon.net Tested-by: Andrew Lunn and...@lunn.ch Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/host/Kconfig | 17 - drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 6 +--- drivers/usb/host/ehci-orion.c | 82 ++- 4 files changed, 53 insertions(+), 53 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 2f68221..e5649c1 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -163,6 +163,17 @@ config USB_EHCI_HCD_OMAP Enables support for the on-chip EHCI controller on OMAP3 and later chips. +config USB_EHCI_HCD_ORION + tristate Support for Marvell EBU on-chip EHCI USB controller + depends on USB_EHCI_HCD PLAT_ORION + default y + ---help--- + Enables support for the on-chip EHCI controller on Marvell's + embedded ARM SoCs, including Orion, Kirkwood, Dove, Armada XP, + Armada 370. This is different from the EHCI implementation + on Marvell's mobile PXA and MMP SoC, see EHCI support for + Marvell PXA/MMP USB controller for those. + config USB_EHCI_MSM bool Support for MSM on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_MSM @@ -206,13 +217,17 @@ config USB_EHCI_S5P Enable support for the S5P SOC's on-chip EHCI controller. config USB_EHCI_MV - bool EHCI support for Marvell on-chip controller + bool EHCI support for Marvell PXA/MMP USB controller depends on USB_EHCI_HCD (ARCH_PXA || ARCH_MMP) select USB_EHCI_ROOT_HUB_TT ---help--- Enables support for Marvell (including PXA and MMP series) on-chip USB SPH and OTG controller. SPH is a single port host, and it can only be EHCI host. OTG is controller that can switch to host mode. + Note that this driver will not work on Marvell's other EHCI + controller used by the EBU-type SoCs including Orion, Kirkwood, + Dova, Armada 370 and Armada XP. See Support for Marvell EBU + on-chip EHCI USB controller for those. config USB_W90X900_EHCI bool W90X900(W90P910) EHCI support diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 56de410..9492f50 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_EHCI_PCI)+= ehci-pci.o obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o +obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index b12b97d..1f97268 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -1249,11 +1249,6 @@ MODULE_LICENSE (GPL); #define XILINX_OF_PLATFORM_DRIVER ehci_hcd_xilinx_of_driver #endif -#ifdef CONFIG_PLAT_ORION -#include ehci-orion.c -#definePLATFORM_DRIVER ehci_orion_driver -#endif - #ifdef CONFIG_USB_W90X900_EHCI #include ehci-w90x900.c #define
[PATCH V5 4/6] USB: EHCI: make ehci-atmel a separate driver
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Atmel host controller driver from ehci-hcd host code
so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before Atmel can be
booted with a multi-platform kernel. This is currently planned for
Linux-3.11.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the Atmel bus glue.
In V4 (arnd):
- reordered #include statements.
- removed call to ehci_shutdown and the corresponding export
In V3:
- Detailed commit message added here about why this patch is required.
- Replaced hcd_name string ehci-atmel to atmel-ehci.
- Inserted blank line in the Makefile to separate the EHCI drivers from
the following non-EHCI drivers.
- Exported ehci_shutdown symbol as it is needed by the Atmel driver.
- Eliminated ehci_atmel_setup routine because hcd registers
can be directly set in the ehci_atmel_drv_probe function.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function
'ehci_shutdown'
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Andrew Victor li...@maxim.org.za
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-atmel.c | 88 ---
drivers/usb/host/ehci-hcd.c | 6 +--
4 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 98abec0f..f6f7872 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -182,6 +182,14 @@ config USB_EHCI_HCD_SPEAR
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
+config USB_EHCI_HCD_AT91
+tristate Support for Atmel on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3d895b5..368d3eb 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index f3beac4..6642009 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -12,9 +12,22 @@
*/
#include linux/clk.h
-#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI Atmel driver
+
+static const char hcd_name[] = ehci-atmel;
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -50,51 +63,6 @@ static void atmel_stop_ehci(struct platform_device *pdev)
/*-*/
-static int ehci_atmel_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* registers start at offset 0x0 */
- ehci-caps = hcd-regs;
-
- return ehci_setup(hcd);
-}
-
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = Atmel EHCI UHP HS,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue
Re: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
On Wednesday 03 April 2013, Felipe Balbi wrote:
const ? Maybe provide a:
#define DEFINE_PHY_OPS(name)\
const struct phy_ops #name_phy_ops = {
macro ? This will force people to add the const keyword :-)
Forcing people to use const structures is good, but I think it would be
better without the macro, just by marking the argument in
devm_phy_create() as const.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v3] USB: regroup all depends on USB within an if USB block
On Thursday 04 April 2013, Felipe Balbi wrote: On Thu, Apr 04, 2013 at 01:42:18PM -0400, Alan Stern wrote: diff --git a/drivers/usb/misc/sisusbvga/Kconfig b/drivers/usb/misc/sisusbvga/Kconfig index 30ea7ca..0d03a52 100644 --- a/drivers/usb/misc/sisusbvga/Kconfig +++ b/drivers/usb/misc/sisusbvga/Kconfig @@ -1,7 +1,7 @@ config USB_SISUSBVGA tristate USB 2.0 SVGA dongle support (Net2280/SiS315) - depends on USB (USB_MUSB_HDRC || USB_EHCI_HCD) + depends on (USB_MUSB_HDRC || USB_EHCI_HCD) is it just me or would everybody agree that depending on MUSB or EHCI here is wrong ? That line certainly looks like it could be removed entirely. Perhaps the original author can enlighten us. In any case, it's not relevant to the purpose of this patch set. right :-) Originally it had just depends on USB_EHCI_HCD and the text mentions that it requires USB 2.0, so it probably comes from a time where EHCI was the only high speed capable USB HCD. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
On Monday 08 April 2013, Greg KH wrote: On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote: Hi Greg, Here are the EHCI patches that I think are good for inclusion in 3.10, I hope you are willing to include them after the debacle over these patches in 3.9. The patches are all logically independent but sorted by priority, so decide for yourself how many you want to take, starting at the first one. The first six patches all have an Ack from Alan Stern and from the respective ARM platform maintainers. I don't see an ACK for the 6th patch from Alan, any reason for that? I've applied the first 5 for now, if you want the 6th one applied, please resend. Thanks a lot! I had mentioned the fact that the last one is missing the ack in my email, maybe not prominently enough when I wrote: * The final patch is from me and still waiting for an Ack from Alan Stern, so please wait for his feedback before applying that one. It would be nice to get that in, but it's not as important for 3.10 since the only conflict between backends I expect is between Exynos and SPEAr. SPEAr is not widely used for all I can tell, and whether Exynos actually makes the multiplatform conversion is still an open question, since there are a number of missing patches and we are about to close the window for arm-soc patches as well. In 3.11, things will look quite different. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/30] ARM: exynos multiplatform support
Hi everyone, I have updated my series for multiplatform support of the ARM exynos platform, based on what is currently queued up in arm-soc. It would be really nice to still get this merged for 3.10. A lot of the patches are really trivial, but there are some complex ones as well. To all subsystem maintainers: feel free to directly apply the patches for your subsystem, there should be no dependencies between any of them, aside from the last patch requiring all of the earlier ones to be applied first. Getting an Ack is also fine so we can put the patches into arm-soc. Arnd Arnd Bergmann (30): ARM: exynos: introduce EXYNOS_ATAGS symbol ARM: exynos: prepare for sparse IRQ ARM: exynos: move debug-macro.S to include/debug/ ARM: samsung: move mfc device definition to s5p-dev-mfc.c tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions video/s3c: move platform_data out of arch/arm thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local pwm: samsung: repair the worst MMIO abuses ASoC: samsung: move plat/ headers to local directory ASoC: samsung: use irq resource for idma ASoC: samsung: convert to dmaengine API ASoC: samsung/i2s: fix module_device_table ASoC: samsung/idma: export idma_reg_addr_init clk: exynos: prepare for multiplatform clocksource: exynos_mct: remove platform header dependency irqchip: exynos: pass max combiner number to combiner_init irqchip: exynos: allocate combiner_data dynamically irqchip: exynos: localize irq lookup for ATAGS irqchip: exynos: pass irq_base from platform spi: s3c64xx: move to generic dmaengine API ARM: exynos: enable multiplatform support arch/arm/Kconfig | 10 +- arch/arm/Kconfig.debug | 8 + arch/arm/configs/exynos4_defconfig | 2 +- .../mach/debug-macro.S = include/debug/exynos.S} | 12 +- .../plat/debug-macro.S = include/debug/samsung.S} | 2 +- arch/arm/mach-exynos/Kconfig | 40 ++- arch/arm/mach-exynos/Makefile | 5 +- arch/arm/mach-exynos/common.c | 26 +- arch/arm/mach-exynos/common.h | 7 +- arch/arm/mach-exynos/dev-uart.c| 1 + arch/arm/mach-exynos/include/mach/irqs.h | 5 +- arch/arm/mach-exynos/mach-armlex4210.c | 2 + arch/arm/mach-exynos/mach-exynos4-dt.c | 3 + arch/arm/mach-exynos/mach-exynos5-dt.c | 2 + arch/arm/mach-exynos/mach-nuri.c | 2 + arch/arm/mach-exynos/mach-origen.c | 2 + arch/arm/mach-exynos/mach-smdk4x12.c | 2 + arch/arm/mach-exynos/mach-smdkv310.c | 3 + arch/arm/mach-exynos/setup-sdhci-gpio.c| 2 +- arch/arm/mach-exynos/setup-usb-phy.c | 8 +- arch/arm/mach-s3c24xx/clock-s3c2440.c | 5 + arch/arm/mach-s3c24xx/common.c | 5 + arch/arm/mach-s3c24xx/dma-s3c2410.c| 2 - arch/arm/mach-s3c24xx/dma-s3c2412.c| 2 - arch/arm/mach-s3c24xx/dma-s3c2440.c| 2 - arch/arm/mach-s3c24xx/dma-s3c2443.c| 2 - arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 2 +- arch/arm/mach-s3c24xx/mach-rx1950.c| 1 - arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 2 +- arch/arm/mach-s3c64xx/setup-usb-phy.c | 4 +- arch/arm/mach-s5p64x0/include/mach/debug-macro.S | 2 +- arch/arm/mach-s5pc100/include/mach/debug-macro.S | 2 +- arch/arm/mach-s5pc100/setup-sdhci-gpio.c | 1 - arch/arm/mach-s5pv210/include/mach/debug-macro.S | 2 +- arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 1 - arch/arm/mach-s5pv210/setup-usb-phy.c | 4 +- arch/arm/plat-samsung/Kconfig | 7 +- arch/arm/plat-samsung/Makefile | 8 +- arch/arm/plat-samsung/devs.c | 62 ++--- arch/arm/plat-samsung/include/plat/fb.h| 50 +--- arch/arm/plat-samsung/include/plat/pm.h| 5 + arch/arm/plat-samsung/include/plat/regs-serial.h | 282 + arch/arm/plat-samsung/include/plat/sdhci.h | 56 +--- arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +- arch/arm/plat-samsung/irq-vic-timer.c | 1 + arch/arm/plat-samsung/pm.c | 1 + arch/arm/plat-samsung/s5p-dev-mfc.c| 42 ++- arch/arm/plat-samsung/s5p-irq.c
[PATCH 10/30] usb: exynos: do not include plat/usb-phy.h
The definitions have moved to include/linux/usb/samsung-usb-phy.h,
and plat/usb-phy.h is unavailable from drivers in a multiplatform
configuration.
Also fix up the plat/usb-phy.h header file to use the definitions
from the new header instead of providing a separate copy.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
---
arch/arm/mach-exynos/setup-usb-phy.c | 8
arch/arm/mach-s3c64xx/setup-usb-phy.c| 4 ++--
arch/arm/mach-s5pv210/setup-usb-phy.c| 4 ++--
arch/arm/plat-samsung/include/plat/usb-phy.h | 5 +
drivers/usb/host/ehci-s5p.c | 1 -
drivers/usb/host/ohci-exynos.c | 1 -
6 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..6af4066 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -204,9 +204,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_init(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_init(pdev);
return -EINVAL;
@@ -214,9 +214,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_exit(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index c8174d9..ca960bd 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -76,7 +76,7 @@ static int s3c_usb_otgphy_exit(struct platform_device *pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_init(pdev);
return -EINVAL;
@@ -84,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c
b/arch/arm/mach-s5pv210/setup-usb-phy.c
index 356a090..b2ee533 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -80,7 +80,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_init(pdev);
return -EINVAL;
@@ -88,7 +88,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h
b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 959bcdb..ab34dfa 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,10 +11,7 @@
#ifndef __PLAT_SAMSUNG_USB_PHY_H
#define __PLAT_SAMSUNG_USB_PHY_H __FILE__
-enum s5p_usb_phy_type {
- S5P_USB_PHY_DEVICE,
- S5P_USB_PHY_HOST,
-};
+#include linux/usb/samsung_usb_phy.h
extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 20ebf6a..7dc9c15 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -19,7 +19,6 @@
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
-#include plat/usb-phy.h
#define EHCI_INSNREG00(base) (base + 0x90)
#define EHCI_INSNREG00_ENA_INCR16 (0x1 25)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 0bd6f47..0792bfd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,7 +18,6 @@
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
-#include plat/usb-phy.h
struct exynos_ohci_hcd {
struct device *dev;
--
1.8.1.2
[PATCH v3] usb: exynos: do not include plat/usb-phy.h
The definitions have moved to include/linux/usb/samsung-usb-phy.h,
and plat/usb-phy.h is unavailable from drivers in a multiplatform
configuration.
Also fix up the plat/usb-phy.h header file to use the definitions
from the new header instead of providing a separate copy.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
---
v3: rebase to usb-next (2871782ae1)
v2: rebase whole series on top of arm-soc for testing
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..6af4066 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -204,9 +204,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_init(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_init(pdev);
return -EINVAL;
@@ -214,9 +214,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_exit(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index c8174d9..ca960bd 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -76,7 +76,7 @@ static int s3c_usb_otgphy_exit(struct platform_device *pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_init(pdev);
return -EINVAL;
@@ -84,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s3c_usb_otgphy_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c
b/arch/arm/mach-s5pv210/setup-usb-phy.c
index 356a090..b2ee533 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -80,7 +80,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_init(pdev);
return -EINVAL;
@@ -88,7 +88,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h
b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 959bcdb..ab34dfa 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,10 +11,7 @@
#ifndef __PLAT_SAMSUNG_USB_PHY_H
#define __PLAT_SAMSUNG_USB_PHY_H __FILE__
-enum s5p_usb_phy_type {
- S5P_USB_PHY_DEVICE,
- S5P_USB_PHY_HOST,
-};
+#include linux/usb/samsung_usb_phy.h
extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 580548a..6357752 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -23,7 +23,6 @@
#include linux/platform_data/usb-ehci-s5p.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
-#include plat/usb-phy.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/otg.h
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 509fa51..114583a 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -17,7 +17,6 @@
#include linux/platform_data/usb-exynos.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
-#include plat/usb-phy.h
struct exynos_ohci_hcd {
struct device *dev;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] USB: OHCI: prepare to make ohci-hcd a library module
On Tuesday 16 April 2013, manjunath.gou...@linaro.org wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
This patch prepares ohci-hcd for being split up into a core
library and separate platform driver modules. A generic
ohci_hc_driver structure is created, containing all the standard
values, and a new mechanism is added whereby a driver module can
specify a set of overrides to those values. In addition the
ohci_init(),ohci_restart(),ohci_hcd_init(),ohci_run() ohci_stop(),
ohci_suspend() and ohci_resume() routines need to be EXPORTed
for use by the drivers.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
Hi Manjunath,
This looks nice I think, but let's see what Alan has to say about it.
I did not see any information in your description about how you
tested the changes. Are you able to use any USB-1.1 devices with
this on a PC, using ohci-pci as a loadable module?
+
+#if defined(CONFIG_PM) || defined(CONFIG_PCI)
+extern int ohci_restart (struct ohci_hcd *ohci);
+#else
+static inline int ohci_restart (struct ohci_hcd *ohci)
+{
+ return;
+}
+#endif
I looked at who calls ohci_restart, and I don't think the #else clause
is actually needed here, or the return for that matter.
Just declare the function unconditionally.
I would also remove the space after the ohci_restart identifier, since
that is the common coding style.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] USB: OHCI: make ohci-pci a separate driver
On Tuesday 16 April 2013, manjunath.gou...@linaro.org wrote:
-
/*
* On architectures with edge-triggered interrupts we must never return
* IRQ_NONE.
@@ -585,7 +574,6 @@ int ohci_init(struct ohci_hcd *ohci)
return ret;
}
EXPORT_SYMBOL_GPL(ohci_init);
-
/*-*/
diff --git a/drivers/usb/host/ohci-mem.c b/drivers/usb/host/ohci-mem.c
index 1a4dede..f98727f 100644
--- a/drivers/usb/host/ohci-mem.c
+++ b/drivers/usb/host/ohci-mem.c
@@ -30,7 +30,6 @@ void ohci_hcd_init (struct ohci_hcd *ohci)
INIT_LIST_HEAD (ohci-pending);
}
EXPORT_SYMBOL_GPL(ohci_hcd_init);
-
/*-*/
static int ohci_mem_init (struct ohci_hcd *ohci)
No need to remove the empty lines here.
@@ -175,7 +182,7 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
return 0;
}
-static void sb800_prefetch(struct ohci_hcd *ohci, int on)
+void sb800_prefetch(struct ohci_hcd *ohci, int on)
{
struct pci_dev *pdev;
u16 misc;
@@ -187,6 +194,7 @@ static void sb800_prefetch(struct ohci_hcd *ohci, int on)
else
pci_write_config_word(pdev, 0x50, misc | 0x0300);
}
+EXPORT_SYMBOL_GPL(sb800_prefetch);
/* List of quirks for OHCI */
I think this won't work when both ehci-hcd and ehci-pci are loadable modules,
since you cannot export symbols both ways. Since the function is used in
drivers/usb/host/ohci-q.c but does not actually require code from ehci-pci.c,
the easiest solution I see would be to make it a static function in ohci-q.c.
Alternatively, it could be an exported function in
drivers/usb/host/pci-quirks.c.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] of_platform_driver and OF_DEVICE removal
On Monday 22 April 2013, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This series is a relatively straight-forward removal of the last remaining user of of_platform_driver (ibmebus) and removal of CONFIG_OF_DEVICE which is always enabled when CONFIG_OF is enabled. Compile tested on powerpc and sparc. Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] usb: musb: ux500: add device tree probing support
On Tuesday 23 April 2013, Lee Jones wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do - mode : Should be 3 to represent OTG. 1 signifies HOST and 2 represents PERIPHERAL. Or you match fsl-usb.txt and nvidia,tegra20-ehci.txt, defining - dr_mode : dual role mode. Indicates the working mode to controllers. Can be host, peripheral, or otg. Default to host if not defined for backward compatibility. +Optional properties: + - dmas : A list of dma channels; +dma-controller, event-line, fixed-channel, flags + - dma-names : An ordered list of channel names affiliated to the above Please list the exact dma-names that are required. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] usb: musb: ux500: add device tree probing support
On Tuesday 23 April 2013, Felipe Balbi wrote: On Tue, Apr 23, 2013 at 05:14:06PM +0200, Arnd Bergmann wrote: On Tuesday 23 April 2013, Lee Jones wrote: +Required properties: + - compatible : Should be stericsson,db8500-musb + - reg: Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - mode : One of; host, otg, or peripheral I think we don't have any precedent for this combination of mode property and contents. You could either try to match ehci-omap.txt and do there is dr_mode which other folks are using. Let's use the same thing. On that topic, should we support the same property in am35x.c and musbhsdma.c? They currently use an integer rather than a string. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: allmodconfig regressions in linux-next
Hi everyone, These are a couple of simple patches to fix bugs that break allyesconfig and that are only present in linux-next at the moment. Please apply to the appropriate trees or provide feedback! Arnd Bergmann (5): mfd: ab8500: remove broken ab8500_debug_register_interrupt logic usb: phy: phy core cannot yet be a module ASoC: don't call of_dma_request_slave_channel directly hwrng: bcm2835: fix MODULE_LICENSE tag clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change drivers/char/hw_random/bcm2835-rng.c | 2 +- drivers/clocksource/bcm_kona_timer.c | 15 --- drivers/mfd/ab8500-debugfs.c | 10 -- drivers/usb/phy/Kconfig | 2 +- sound/soc/soc-generic-dmaengine-pcm.c | 9 + 5 files changed, 11 insertions(+), 27 deletions(-) Cc: Christian Daudt c...@broadcom.com Cc: Dom Cobley popcorn...@gmail.com Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Herbert Xu herb...@gondor.apana.org.au Cc: John Stultz john.stu...@linaro.org Cc: Jonas ABERG jonas.ab...@stericsson.com Cc: Lars-Peter Clausen l...@metafoo.de Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@stericsson.com Cc: Lubomir Rintel lkund...@v3.sk Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Matt Mackall m...@selenic.com Cc: Mattias WALLIN mattias.wal...@stericsson.com Cc: Per FORLIN per.for...@stericsson.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Shawn Guo shawn@linaro.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: alsa-de...@alsa-project.org Cc: linux-rpi-ker...@lists.infradead.org Cc: linux-usb@vger.kernel.org Cc: srinidhi kasagar srinidhi.kasa...@stericsson.com -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: phy core cannot yet be a module
A lot of platform code calls into the usb phy core at the moment, which does not work if it is built as a loadable module. This will hopefully change when those platforms are all converted to DT based probing, but for now, the easiest solution is to change it from tristate to bool. This solves at least these ARM allmodconfig build errors: arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create': arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create' arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' drivers/built-in.o: In function `ab8500_charger_probe': drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy' drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy' drivers/built-in.o: In function `ab8500_charger_remove': drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy' Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org --- drivers/usb/phy/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 21153d1..371d0e7 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -2,7 +2,7 @@ # Physical Layer USB driver configuration # menuconfig USB_PHY - tristate USB Physical Layer drivers + bool USB Physical Layer drivers help USB controllers (those which are host, device or DRD) need a device to handle the physical layer signalling, commonly called -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
