Re: Queueing b0a688ddcc50 "usb: musb: cppi41: allow it to work again" for -stable
On 2 October 2015 at 13:09, Felipe Balbi <ba...@ti.com> wrote: > On Fri, Oct 02, 2015 at 02:23:45AM -0300, Ezequiel Garcia wrote: >> Hello, >> >> Commit b0a688ddcc50 "usb: musb: cppi41: allow it to work again" seems >> to fix a regression. It applies cleanly on v4.1 and removes the >> "musb-hdrc musb-hdrc.1.auto: Need DT for the DMA engine." error. >> >> Any chance you can queue it for -stable? > > Have a look at Documentation/stable_kernel_rules.txt, you can do a proper > request for Greg and he will make sure it gets there. > Sure, I will. Maybe next time you could add a Cc: stable to these kinds of fixes, along with a proper Fixes tag, so the -stable folks can pick them automatically. Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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
Queueing b0a688ddcc50 "usb: musb: cppi41: allow it to work again" for -stable
Hello, Commit b0a688ddcc50 "usb: musb: cppi41: allow it to work again" seems to fix a regression. It applies cleanly on v4.1 and removes the "musb-hdrc musb-hdrc.1.auto: Need DT for the DMA engine." error. Any chance you can queue it for -stable? Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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/9] usb: musb: several bugfixes for the musb driver
On 21 Jul 10:11 AM, Felipe Balbi wrote: On Mon, Jul 21, 2014 at 09:34:30AM +0200, Lothar Waßmann wrote: Hi, Felipe Balbi wrote: Hi, On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote: Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! I don't that's a good fix. The problem is that even after am335x removing all its child, someone else tried to release the PHY. That ordering is the one that needs to be fixed. Doing a module_get on the parent device looks like a hack to me. No. It guarantees that the module cannot be unloaded when its resources are still in use! it's still a hack. You have a child incrementing the usage count on its parent just because a sibbling isn't doing the right thing. How about having the musb_am335x (glue driver) call request_module and module_get on the phy-am335x? Wouldn't this be a cleaner approach? I haven't checked if this possible, though. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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/9] usb: musb: several bugfixes for the musb driver
Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: musb: Fix panic upon musb_am335x module removal
) from [bf05900c]
(of_remove_populated_child+0xc/0x14 [musb_am335x])
[bf05900c] (of_remove_populated_child [musb_am335x]) from [c02c5c48]
(device_for_each_child+0x44/0x70)
[c02c5c48] (device_for_each_child) from [bf05902c]
(am335x_child_remove+0x18/0x30 [musb_am335x])
[bf05902c] (am335x_child_remove [musb_am335x]) from [c02ca37c]
(platform_drv_remove+0x18/0x1c)
[c02ca37c] (platform_drv_remove) from [c02c8db0]
(__device_release_driver+0x70/0xc8)
[c02c8db0] (__device_release_driver) from [c02c94c8]
(driver_detach+0xb4/0xb8)
[c02c94c8] (driver_detach) from [c02c8ab4] (bus_remove_driver+0x4c/0xa0)
[c02c8ab4] (bus_remove_driver) from [c007fc40]
(SyS_delete_module+0x128/0x1cc)
[c007fc40] (SyS_delete_module) from [c000e500] (ret_fast_syscall+0x0/0x48)
Fixes: 97238b35d5bb (usb: musb: dsps: use proper child nodes)
Cc: sta...@vger.kernel.org # v3.12+
Acked-by: George Cherian george.cher...@ti.com
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
drivers/usb/musb/musb_am335x.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
index d235378..1e58ed2 100644
--- a/drivers/usb/musb/musb_am335x.c
+++ b/drivers/usb/musb/musb_am335x.c
@@ -19,21 +19,6 @@ err:
return ret;
}
-static int of_remove_populated_child(struct device *dev, void *d)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- of_device_unregister(pdev);
- return 0;
-}
-
-static int am335x_child_remove(struct platform_device *pdev)
-{
- device_for_each_child(pdev-dev, NULL, of_remove_populated_child);
- pm_runtime_disable(pdev-dev);
- return 0;
-}
-
static const struct of_device_id am335x_child_of_match[] = {
{ .compatible = ti,am33xx-usb },
{ },
@@ -42,13 +27,17 @@ MODULE_DEVICE_TABLE(of, am335x_child_of_match);
static struct platform_driver am335x_child_driver = {
.probe = am335x_child_probe,
- .remove = am335x_child_remove,
.driver = {
.name = am335x-usb-childs,
.of_match_table = am335x_child_of_match,
},
};
-module_platform_driver(am335x_child_driver);
+static int __init am335x_child_init(void)
+{
+ return platform_driver_register(am335x_child_driver);
+}
+module_init(am335x_child_init);
+
MODULE_DESCRIPTION(AM33xx child devices);
MODULE_LICENSE(GPL v2);
--
1.9.1
--
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] usb: musb: Prevent musb_am335x from being removed
On 12 May 10:29 AM, George Cherian wrote: On 5/8/2014 10:57 PM, Ezequiel Garcia wrote: At probe time, the musb_am335x driver registers its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child in the musb_am335x driver device struct. However, when musb_dsps is loaded, its devices are attached to the musb_am335x driver device struct as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the struct device hierarchy are not the same as the childs in the devicetree hierarchy. Ideally, we should be enforcing the removal of the devices registered by musb_am335x *only*, instead of all the child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. Just for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 008c pgd = de11c000 [008c] *pgd=9e174831, *pte=, *ppte= Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-1-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [c0327798]lr : [c0327794]psr: a013 sp : de123df8 ip : 0004 fp : 00028f00 r10: r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : r1 : 0001 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 0015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 6013 bf043650 12fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: bf059000 a013 c02c5bc0 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 3f40: 0800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 0001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 0081 6010 00028e70 00028e70 00028ea4 3fa0: 0081 c000e500 00028e70 00028e70 00028ea4 0800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 0081 0001 0001 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 6010 00028ea4 [c0327798] (am335x_shutdown) from [bf054488] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [bf054488] (dsps_musb_exit [musb_dsps]) from [bf043650] (musb_shutdown+0x80/0x90 [musb_hdrc]) [bf043650] (musb_shutdown [musb_hdrc]) from [bf043a20] (musb_remove+0x24/0x68 [musb_hdrc]) [bf043a20] (musb_remove [musb_hdrc]) from [c02ca37c] (platform_drv_remove+0x18/0x1c) [c02ca37c] (platform_drv_remove) from [c02c8db0] (__device_release_driver+0x70/0xc8) [c02c8db0] (__device_release_driver) from [c02c8e28] (device_release_driver+0x20/0x2c) [c02c8e28] (device_release_driver) from [c02c884c] (bus_remove_device+0xdc/0x10c) [c02c884c] (bus_remove_device) from [c02c5b20] (device_del+0x104/0x198) [c02c5b20] (device_del) from [c02ca838] (platform_device_del+0x14/0x9c) [c02ca838] (platform_device_del) from [c02ca8cc] (platform_device_unregister+0xc/0x20) [c02ca8cc] (platform_device_unregister) from [bf054194] (dsps_remove+0x18/0x38 [musb_dsps]) [bf054194] (dsps_remove [musb_dsps]) from [c02ca37c] (platform_drv_remove+0x18/0x1c) [c02ca37c] (platform_drv_remove) from [c02c8db0] (__device_release_driver+0x70/0xc8) [c02c8db0] (__device_release_driver) from [c02c8e28] (device_release_driver+0x20/0x2c) [c02c8e28] (device_release_driver) from [c02c884c] (bus_remove_device+0xdc/0x10c) [c02c884c] (bus_remove_device) from [c02c5b20] (device_del+0x104/0x198
[RFC/PATCH] usb: musb: Prevent musb_am335x from being removed
] (of_remove_populated_child [musb_am335x]) from [c02c5c48]
(device_for_each_child+0x44/0x70)
[c02c5c48] (device_for_each_child) from [bf05902c]
(am335x_child_remove+0x18/0x30 [musb_am335x])
[bf05902c] (am335x_child_remove [musb_am335x]) from [c02ca37c]
(platform_drv_remove+0x18/0x1c)
[c02ca37c] (platform_drv_remove) from [c02c8db0]
(__device_release_driver+0x70/0xc8)
[c02c8db0] (__device_release_driver) from [c02c94c8]
(driver_detach+0xb4/0xb8)
[c02c94c8] (driver_detach) from [c02c8ab4] (bus_remove_driver+0x4c/0xa0)
[c02c8ab4] (bus_remove_driver) from [c007fc40]
(SyS_delete_module+0x128/0x1cc)
[c007fc40] (SyS_delete_module) from [c000e500] (ret_fast_syscall+0x0/0x48)
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
Given I'm not 100% sure my analisys is correct, I've marked this as RFC
and not Cced stable. Feel free to provide a better patch to fix this issue,
instead of disabling the removal.
drivers/usb/musb/musb_am335x.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
index d235378..1e58ed2 100644
--- a/drivers/usb/musb/musb_am335x.c
+++ b/drivers/usb/musb/musb_am335x.c
@@ -19,21 +19,6 @@ err:
return ret;
}
-static int of_remove_populated_child(struct device *dev, void *d)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- of_device_unregister(pdev);
- return 0;
-}
-
-static int am335x_child_remove(struct platform_device *pdev)
-{
- device_for_each_child(pdev-dev, NULL, of_remove_populated_child);
- pm_runtime_disable(pdev-dev);
- return 0;
-}
-
static const struct of_device_id am335x_child_of_match[] = {
{ .compatible = ti,am33xx-usb },
{ },
@@ -42,13 +27,17 @@ MODULE_DEVICE_TABLE(of, am335x_child_of_match);
static struct platform_driver am335x_child_driver = {
.probe = am335x_child_probe,
- .remove = am335x_child_remove,
.driver = {
.name = am335x-usb-childs,
.of_match_table = am335x_child_of_match,
},
};
-module_platform_driver(am335x_child_driver);
+static int __init am335x_child_init(void)
+{
+ return platform_driver_register(am335x_child_driver);
+}
+module_init(am335x_child_init);
+
MODULE_DESCRIPTION(AM33xx child devices);
MODULE_LICENSE(GPL v2);
--
1.9.1
--
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 17/20] phy: Add support for USB cluster on the Armada 375 SoC
Hi Greg,
On 06 May 02:14 AM, Gregory CLEMENT wrote:
+
+#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
+
I still think it's more readable to use USB2_PHY_CONFIG_DISABLE.
It's just a nitpick, though.
+static int armada375_usb_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct phy *phy;
+ struct device_node *np = dev-of_node;
+ struct phy_provider *phy_provider;
+ void __iomem *usb_cluster_base;
+ struct device_node *xhci_node;
+ int i;
+
+ usb_cluster_base = of_iomap(np, 0);
+ BUG_ON(!usb_cluster_base);
+
Isn't a bit extreme to call BUG_ON (and thus bring down the whole system)
in a phy driver?
+ for (i = 0; i NB_PHY; i++) {
+ phy = devm_phy_create(dev, armada375_usb_phy_ops, NULL);
+ if (IS_ERR(phy))
+ dev_err(dev, failed to create PHY n%d\n, i);
+
I think you're missing a continue/break here.
+ usb_cluster_phy[i].phy = phy;
+ usb_cluster_phy[i].reg = usb_cluster_base;
+ usb_cluster_phy[i].enable = false;
+ phy_set_drvdata(phy, usb_cluster_phy[i]);
+ }
+
+ usb_cluster_phy[PHY_USB2].use_usb3 = false;
+ usb_cluster_phy[PHY_USB3].use_usb3 = true;
+
[..]
+
+MODULE_DESCRIPTION(Armada 375 USB cluster driver);
+MODULE_AUTHOR(Gregory CLEMENT gregory.clem...@free-electrons.com);
+MODULE_LICENSE(GPL);
GPL v2 ?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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
Re: [PATCH v2 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC
On Apr 25, Gregory CLEMENT wrote:
The Armada 375 SoC comes with an USB2 host and device controller and
an USB3 controller. The USB cluster control register allows to manage
common features of both USB controllers.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/usb-cluster.c | 96
+++
2 files changed, 97 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/usb-cluster.c
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index a63e43b6b451..dec05e7e1802 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) :=
-I$(srctree)/$(src)/include \
AFLAGS_coherency_ll.o:= -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
-obj-$(CONFIG_MACH_MVEBU_V7) += board-v7.o
+obj-$(CONFIG_MACH_MVEBU_V7) += board-v7.o usb-cluster.o
obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_ARCH_MVEBU) += coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
diff --git a/arch/arm/mach-mvebu/usb-cluster.c
b/arch/arm/mach-mvebu/usb-cluster.c
new file mode 100644
index ..4c15d282db23
--- /dev/null
+++ b/arch/arm/mach-mvebu/usb-cluster.c
@@ -0,0 +1,96 @@
+/*
+ * USB cluster support for Armada 375 platform.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT gregory.clem...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Armada 375 comes with an USB2 host and device controller and an
+ * USB3 controller. The USB cluster control register allows to manage
+ * common features of both USB controller.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/slab.h
+
+#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
+
If it's active low, maybe you can simply call this USB2_PHY_DISABLE?
+static struct of_device_id of_usb_cluster_table[] = {
+ { .compatible = marvell,armada-375-usb-cluster, },
+ { /* end of list */ },
+};
+
+static int __init mvebu_usb_cluster_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, of_usb_cluster_table);
+ if (np) {
I think that writing:
if (!np)
return 0;
Will allow to write the rest with less indentation, which is usually cleaner.
+ void __iomem *usb_cluster_base;
+ u32 reg;
+ struct device_node *ehci_node, *xhci_node;
+ struct property *ehci_status;
+ bool use_usb3 = false;
+
+ usb_cluster_base = of_iomap(np, 0);
+ BUG_ON(!usb_cluster_base);
+
+ xhci_node = of_find_compatible_node(NULL, NULL,
+ marvell,armada-375-xhci);
+
+ if (xhci_node of_device_is_available(xhci_node))
+ use_usb3 = true;
+
+ ehci_node = of_find_compatible_node(NULL, NULL,
+ marvell,orion-ehci);
+
+ if (ehci_node of_device_is_available(ehci_node)
+ use_usb3) {
+ /*
+ * We can't use usb2 and usb3 in the same time, so let's
+ * disbale usb2 and complain about it to the user askinf
typos: disable, asking
+ * to fix the device tree.
+ */
+
+ ehci_status = kzalloc(sizeof(struct property),
+ GFP_KERNEL);
+ WARN_ON(!ehci_status);
+
+ ehci_status-value = kstrdup(disabled, GFP_KERNEL);
Unless I'm missing something, warning about allocation error but then still
using the pointer will cause very nasty problems. Maybe you can simply
bail out?
+ WARN_ON(!ehci_status-value);
+
+ ehci_status-length = 8;
+ ehci_status-name = kstrdup(status, GFP_KERNEL);
+ WARN_ON(!ehci_status-name);
+
+ of_update_property(ehci_node, ehci_status);
+ pr_err(%s: armada-375-xhci and orion-ehci are
incompatible for this SoC.\n,
+ __func__);
+ pr_err(Please fix your dts!\n);
+ pr_err(orion-ehci have been disabled by default...\n);
+
We've been using a WARN(1, FW_BUG ) to notify the user of a broken DT.
Arnd suggested to use WARN() to really catch the user's attention.
+ }
+
+ reg = readl(usb_cluster_base);
+
Re: [PATCH] USB: musb: dsps: move debugfs_remove_recursive()
Felipe, On Apr 22, Greg KH wrote: On Tue, Apr 22, 2014 at 10:26:13AM -0500, Felipe Balbi wrote: On Tue, Apr 22, 2014 at 12:19:16PM -0300, Ezequiel Garcia wrote: That way silly grass-hoppers like me won't have to go through the find-bisect-fix bug cycle, only to discover someone else already fixed it but the patch is floating around :-) yeah, maybe.. I don't want to merge my fixes into next though. Maybe Stephen could just merge both my branches on next. Greg, are you merging your usb-linus into linux-next ? Yes, both of my branches get merged into linux-next. Well, if it's not too much trouble, I'd really appreciate that you can find a way to include these -rc fixes in the branches that get merged in -next. Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On Apr 23, Sebastian Andrzej Siewior wrote: On 04/22/2014 04:19 PM, Ezequiel Garcia wrote: The DMA controller is needed for the USB controller to be correctly registered. Therefore, if the DMA node is located at the end an unecessary probe deferral is produced systematically. This is easily fixed by moving the node at the beggining of the child list, so it's probed first. So you do not change anything except for the order of child nodes. So this should be fine and without a compatibility problem. I added them according to the memory offset so you might want to add a comment why you moved this because Mr. Structured Organized might noticed this one day and move it back. Yes, good catch. I'll prepare a v2. Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar --- Felipe, Sebastian: I cannot see why the cppi41dma node must be placed inside the ti,am33xx-usb compatible node. Tried to move it out so it's probed just like the edma engine, but the USB doesn't work properly in that case. Can you enlighten me? So If I remember correctly it was a big bag of crap. If you look at the parent node, you notice that it has a ti,hwmods member while the other do not have such a property. According to the manual only the whole IP block as-it has this. It has to be activated if you use one of those devices this includes the two USB-IP cores and the DMA-IP core. I didn't manage to come up with something else except to make one parent node which creates the childs to have a proper relation here. Ah, this could be... There was also something with parent - child relation in the way musb expected it. I think this was only glue code + musb child node and had nothing to do with the DMA engine. But I am not 100% sure… Well, from my poor and unexperienced code inspection, I could not see anything relating the parent of the DMA controller node to the node itself, and so that's why it seemed possible to move it out. Once the dma-controller is moved out of the USB devicetree node block, the dmaengine driver is registered correctly (apparently), and so does the USB driver. However, upon connection of some USB storage device, detection begins but then things don't go well, although I don't have the exact error here, I remember this warning was hitted on dma/cppi41.c at line 602: WARN_ON(!c-td_retry); Just in case someone want to debug this further. Thanks a lot for the feedback! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
The DMA controller is needed for the USB controller to be correctly
registered. Therefore, if the DMA node is located at the end an unecessary
probe deferral is produced systematically.
This is easily fixed by moving the node at the beggining of the child list,
so it's probed first.
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
Felipe, Sebastian:
I cannot see why the cppi41dma node must be placed inside the
ti,am33xx-usb compatible node. Tried to move it out
so it's probed just like the edma engine, but the USB doesn't work
properly in that case.
Can you enlighten me?
In any case, this change is good enough to remove the deferral probe.
Thanks!
arch/arm/boot/dts/am33xx.dtsi | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9770e35..c673be4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -453,6 +453,21 @@
ti,hwmods = usb_otg_hs;
status = disabled;
+ cppi41dma: dma-controller@47402000 {
+ compatible = ti,am3359-cppi41;
+ reg = 0x4740 0x1000
+ 0x47402000 0x1000
+ 0x47403000 0x1000
+ 0x47404000 0x4000;
+ reg-names = glue, controller, scheduler,
queuemgr;
+ interrupts = 17;
+ interrupt-names = glue;
+ #dma-cells = 2;
+ #dma-channels = 30;
+ #dma-requests = 256;
+ status = disabled;
+ };
+
usb_ctrl_mod: control@44e10620 {
compatible = ti,am335x-usb-ctrl-module;
reg = 0x44e10620 0x10
@@ -556,20 +571,6 @@
tx14, tx15;
};
- cppi41dma: dma-controller@47402000 {
- compatible = ti,am3359-cppi41;
- reg = 0x4740 0x1000
- 0x47402000 0x1000
- 0x47403000 0x1000
- 0x47404000 0x4000;
- reg-names = glue, controller, scheduler,
queuemgr;
- interrupts = 17;
- interrupt-names = glue;
- #dma-cells = 2;
- #dma-channels = 30;
- #dma-requests = 256;
- status = disabled;
- };
};
epwmss0: epwmss@4830 {
--
1.9.1
--
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: stk1160 / ehci-pci 0000:00:0a.0: DMA-API: device driver maps memory fromstack [addr=ffff88003d0b56bf]
On Apr 13, Alan Stern wrote: On Sun, 13 Apr 2014, Sander Eikelenboom wrote: Hi, I'm hitting this warning on boot with a syntek usb video grabber, it's not clear to me if it's a driver issue of the stk1160 or a generic ehci issue. It is a bug in the stk1160 driver. Thanks for pointing this out, I'm on it. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: stk1160 / ehci-pci 0000:00:0a.0: DMA-API: device driver maps memory fromstack [addr=ffff88003d0b56bf]
On Apr 13, Sander Eikelenboom wrote:
I'm hitting this warning on boot with a syntek usb video grabber, it's not
clear
to me if it's a driver issue of the stk1160 or a generic ehci issue.
Can't reproduce the same warning easily here. Could you test the following
patch?
diff --git a/drivers/media/usb/stk1160/stk1160-core.c
b/drivers/media/usb/stk1160/stk1160-core.c
index 34a26e0..304fdb3 100644
--- a/drivers/media/usb/stk1160/stk1160-core.c
+++ b/drivers/media/usb/stk1160/stk1160-core.c
@@ -71,13 +71,14 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8
*value)
*value = 0;
ret = usb_control_msg(dev-udev, pipe, 0x00,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- 0x00, reg, value, sizeof(u8), HZ);
+ 0x00, reg, dev-urb_buf, sizeof(u8), HZ);
if (ret 0) {
stk1160_err(read failed on reg 0x%x (%d)\n,
reg, ret);
return ret;
}
+ *value = dev-urb_buf[0];
return 0;
}
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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
Re: AM335x USB DMA seems broken on ISOC URBs
On Mon, Jan 20, 2014 at 12:15:40PM +0100, Daniel Mack wrote: On 01/18/2014 04:12 PM, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. [...] Let me know if you find anything - I hope to find some time to do similar tests on AM33xx based hardware. I tried using an USB headset connected to a AM33xx based board, using kernel v3.13. The good news is that aplay gives me sound, so there's nothing generally wrong with isochronous streams on musb_dsps/cppi41. Hm.. interesting. I wonder what's the difference between those URBs and the video URBs involved in stk1160 operation. Maybe the size of each buffer transfered? Can anybody bring some light on this? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: AM335x USB DMA seems broken on ISOC URBs
Hi Daniel, On Sat, Jan 18, 2014 at 04:12:24PM +0100, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: [..] Did you try this with a different type of peripheral hardware, a USB audio device for example? [..] Finally I found some time to setup the board and do some new tests using an UVC webcam (which might behave better given it should transfer smaller buffers). The result is not encouraging! Device is detected regularly, but then I get some ugly messages on the first command: # yavta /dev/video0 -l [ 21.279722] BUG: spinlock cpu recursion on CPU#0, kworker/0:2/46 [ 21.286041] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 21.293800] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 21.302571] Workqueue: events musb_host_finish_resume [ 21.307899] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 21.315844] [c000e8db] (show_stack) from [c003f981] (do_raw_spin_lock+0xc5/0xe8) [ 21.323969] [c003f981] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 21.333094] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 21.342860] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 21.352258] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 21.360750] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 21.368325] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) [ 27.352780] BUG: spinlock lockup suspected on CPU#0, kworker/0:2/46 [ 27.359350] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 27.367104] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 27.375860] Workqueue: events musb_host_finish_resume [ 27.381162] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 27.389103] [c000e8db] (show_stack) from [c003f971] (do_raw_spin_lock+0xb5/0xe8) [ 27.397224] [c003f971] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 27.406348] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 27.416109] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 27.425506] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 27.433991] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 27.441566] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) Any ideas from the maintainers? PS: As expected TI's PSP v3.2 driver works just fine :P -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: AM335x USB DMA seems broken on ISOC URBs
On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: Hello, While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the bandwidth requirements are too large for PIO (it's a raw video device) and the video can't get captured. Interesting enough, using an old backported for v3.2 stk1160 driver, this same setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in either the cppi41 dmaengine or the musb. I tried to compare the PSP to the mainline drivers but they seems *very* different and really beyond my understanding. Any ideas on how can I help debugging this? Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver works fine so at least that's a starting point... -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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 2/2] usb: musb: Rework USB and USB_GADGET dependency
This USB controller can work in as host-only, gadget-only or dual-role modes. Rework the dependency on the USB and USB_GADGET configs in order to allow building the driver when !USB or !USG_GADGET. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- This is just a resend of a recently sent, standalone patch. drivers/usb/Kconfig | 4 ++-- drivers/usb/musb/Kconfig | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 2642b8a..a34fb98 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -94,8 +94,6 @@ source drivers/usb/wusbcore/Kconfig source drivers/usb/host/Kconfig -source drivers/usb/musb/Kconfig - source drivers/usb/renesas_usbhs/Kconfig source drivers/usb/class/Kconfig @@ -106,6 +104,8 @@ source drivers/usb/image/Kconfig endif +source drivers/usb/musb/Kconfig + source drivers/usb/dwc3/Kconfig source drivers/usb/chipidea/Kconfig diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 57dfc0c..a1d805f 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,7 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on USB_GADGET + depends on (USB || USB_GADGET) help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then @@ -35,21 +35,21 @@ choice config USB_MUSB_HOST bool Host only mode - depends on USB + depends on USB=y || USB=USB_MUSB_HDRC help Select this when you want to use MUSB in host mode only, thereby the gadget feature will be regressed. config USB_MUSB_GADGET bool Gadget only mode - depends on USB_GADGET + depends on USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC help Select this when you want to use MUSB in gadget mode only, thereby the host feature will be regressed. config USB_MUSB_DUAL_ROLE bool Dual Role mode - depends on (USB USB_GADGET) + depends on ((USB=y || USB=USB_MUSB_HDRC) (USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC)) help This is the default mode of working of MUSB controller where both host and gadget features are enabled. -- 1.8.1.5 -- 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 0/2] musb: Rework USB and USB_GADGET config
I'm resending this configuration rework to include one more patch in the series, prior to the config change. The first patch removes the usb_disable() usage, allowing the build the module for gadget-only mode usage. Without the first patch, the build breaks when building for !USB USB_GADGET. Hope it looks better now. Ezequiel Garcia (2): usb: musb: Remove usb_disable() check in module_init() usb: musb: Rework USB and USB_GADGET dependency drivers/usb/Kconfig | 4 ++-- drivers/usb/musb/Kconfig | 8 drivers/usb/musb/musb_core.c | 17 + 3 files changed, 7 insertions(+), 22 deletions(-) -- 1.8.1.5 -- 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 1/2] usb: musb: Remove usb_disable() check in module_init()
Removing the check to usb_disable() before registering the platform
driver allows to build this driver when !USB USB_GADGET, to be
used in gadget-only mode.
Also, use module_platform_driver() to register the platform driver.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/usb/musb/musb_core.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 4d4499b..74d547a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2283,19 +2283,4 @@ static struct platform_driver musb_driver = {
.shutdown = musb_shutdown,
};
-/*-*/
-
-static int __init musb_init(void)
-{
- if (usb_disabled())
- return 0;
-
- return platform_driver_register(musb_driver);
-}
-module_init(musb_init);
-
-static void __exit musb_cleanup(void)
-{
- platform_driver_unregister(musb_driver);
-}
-module_exit(musb_cleanup);
+module_platform_driver(musb_driver);
--
1.8.1.5
--
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: musb: Rework USB and USB_GADGET dependency
This USB controller can work in as host-only, gadget-only or dual-role modes. Rework the dependency on the USB and USB_GADGET configs in order to allow building the driver when !USB or !USG_GADGET. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Changes from v1: Remove unneeded parenthesis drivers/usb/Kconfig | 4 ++-- drivers/usb/musb/Kconfig | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 2642b8a..a34fb98 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -94,8 +94,6 @@ source drivers/usb/wusbcore/Kconfig source drivers/usb/host/Kconfig -source drivers/usb/musb/Kconfig - source drivers/usb/renesas_usbhs/Kconfig source drivers/usb/class/Kconfig @@ -106,6 +104,8 @@ source drivers/usb/image/Kconfig endif +source drivers/usb/musb/Kconfig + source drivers/usb/dwc3/Kconfig source drivers/usb/chipidea/Kconfig diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 57dfc0c..fff30b9 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,7 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on USB_GADGET + depends on USB || USB_GADGET help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then @@ -35,21 +35,21 @@ choice config USB_MUSB_HOST bool Host only mode - depends on USB + depends on USB=y || USB=USB_MUSB_HDRC help Select this when you want to use MUSB in host mode only, thereby the gadget feature will be regressed. config USB_MUSB_GADGET bool Gadget only mode - depends on USB_GADGET + depends on USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC help Select this when you want to use MUSB in gadget mode only, thereby the host feature will be regressed. config USB_MUSB_DUAL_ROLE bool Dual Role mode - depends on (USB USB_GADGET) + depends on (USB=y || USB=USB_MUSB_HDRC) (USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC) help This is the default mode of working of MUSB controller where both host and gadget features are enabled. -- 1.8.1.5 -- 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: musb: Rework USB and USB_GADGET dependency
This USB controller can work in as host-only, gadget-only or dual-role modes. Rework the dependency on the USB and USB_GADGET configs in order to allow building the driver when !USB or !USG_GADGET. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Changes from v1: * Rework the dependency, as per Felipe's suggestion, to allow building the driver in either !USB or !USB_GADGET. This has been done following dwc3, which seems to be doing the Right Thing. drivers/usb/Kconfig | 4 ++-- drivers/usb/musb/Kconfig | 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 2642b8a..a34fb98 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -94,8 +94,6 @@ source drivers/usb/wusbcore/Kconfig source drivers/usb/host/Kconfig -source drivers/usb/musb/Kconfig - source drivers/usb/renesas_usbhs/Kconfig source drivers/usb/class/Kconfig @@ -106,6 +104,8 @@ source drivers/usb/image/Kconfig endif +source drivers/usb/musb/Kconfig + source drivers/usb/dwc3/Kconfig source drivers/usb/chipidea/Kconfig diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 57dfc0c..a1d805f 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,7 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on USB_GADGET + depends on (USB || USB_GADGET) help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then @@ -35,21 +35,21 @@ choice config USB_MUSB_HOST bool Host only mode - depends on USB + depends on USB=y || USB=USB_MUSB_HDRC help Select this when you want to use MUSB in host mode only, thereby the gadget feature will be regressed. config USB_MUSB_GADGET bool Gadget only mode - depends on USB_GADGET + depends on USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC help Select this when you want to use MUSB in gadget mode only, thereby the host feature will be regressed. config USB_MUSB_DUAL_ROLE bool Dual Role mode - depends on (USB USB_GADGET) + depends on ((USB=y || USB=USB_MUSB_HDRC) (USB_GADGET=y || USB_GADGET=USB_MUSB_HDRC)) help This is the default mode of working of MUSB controller where both host and gadget features are enabled. -- 1.8.1.5 -- 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
AM335x USB DMA seems broken on ISOC URBs
Hello, While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the bandwidth requirements are too large for PIO (it's a raw video device) and the video can't get captured. Interesting enough, using an old backported for v3.2 stk1160 driver, this same setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in either the cppi41 dmaengine or the musb. I tried to compare the PSP to the mainline drivers but they seems *very* different and really beyond my understanding. Any ideas on how can I help debugging this? Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH] usb: musb: Remove USB_GADGET driver dependency
On Fri, Dec 20, 2013 at 09:49:58AM -0600, Felipe Balbi wrote: On Thu, Dec 19, 2013 at 10:20:48PM -0300, Ezequiel Garcia wrote: This USB controller is dual-role, but can also work in host-only mode. There's no reason to condition the entire driver to USB_GADGET. Fix this by removing the dependency. Tested on a Beaglebone black (AM335x) using a regular USB mass storage device. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/usb/musb/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 57dfc0c..2119370 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,6 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on USB_GADGET the correct patch would be to turn this into (USB || USB_GADGET) and fix the mode selection just like dwc3 is doing. Ah, I see now. Let me prepare a v2 then. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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] usb: musb: Remove USB_GADGET driver dependency
This USB controller is dual-role, but can also work in host-only mode. There's no reason to condition the entire driver to USB_GADGET. Fix this by removing the dependency. Tested on a Beaglebone black (AM335x) using a regular USB mass storage device. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/usb/musb/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 57dfc0c..2119370 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -6,7 +6,6 @@ # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' - depends on USB_GADGET help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then -- 1.8.1.5 -- 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: phy: am335x: Prevent GPIO reset line request
On Fri, Dec 06, 2013 at 02:16:23PM -0600, Felipe Balbi wrote: On Sat, Nov 30, 2013 at 07:45:05PM -0300, Ezequiel Garcia wrote: On Thu, Nov 21, 2013 at 07:01:55AM -0600, Felipe Balbi wrote: On Thu, Nov 21, 2013 at 08:55:20AM -0300, Ezequiel Garcia wrote: On Thu, Nov 21, 2013 at 12:44:51PM +0100, Sebastian Andrzej Siewior wrote: On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: Ah, good to know. That patch should be picked ASAP, without it the USB in AM335x is broken. Is it already too late to -rc1? Yes. Who is supposed to merge that? Greg? Felipe will start collecting fixes once -rc1 is out [0] so it should be part of -rc2. OK, fine by me. Please note that Felipe's commit is a much bigger (and nicer) rework of the code, and that it doesn't clearly state it fixes the current code. Felipe: Maybe you should add some message stating it fixes a regression? sure, makes sense. Sebastian had already mentioned it sounded too nice of a commit log ;-) I'm looking at -rc2 and it seems the fix was never pushed, so my board is probably still broken :-( Can anybody _please_please_ fix the issue by merging some fix so we can use USB with mainline? it's in Greg's tree Yeah, I just saw the pull. Thanks for the notice! I'll re-test in -rc4 and let you know if I find any more problems. FWIW, I'm not entirely happy with the solution. Probably being a bit paranoid, but it seemed to me the fix could be smaller (and fix only the problem) and then pospone your refactoring until v3.14. Just my two cents and thanks again for the notice. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH] usb: phy: am335x: Prevent GPIO reset line request
On Thu, Nov 21, 2013 at 07:01:55AM -0600, Felipe Balbi wrote: On Thu, Nov 21, 2013 at 08:55:20AM -0300, Ezequiel Garcia wrote: On Thu, Nov 21, 2013 at 12:44:51PM +0100, Sebastian Andrzej Siewior wrote: On 11/21/2013 12:30 PM, Ezequiel Garcia wrote: Ah, good to know. That patch should be picked ASAP, without it the USB in AM335x is broken. Is it already too late to -rc1? Yes. Who is supposed to merge that? Greg? Felipe will start collecting fixes once -rc1 is out [0] so it should be part of -rc2. OK, fine by me. Please note that Felipe's commit is a much bigger (and nicer) rework of the code, and that it doesn't clearly state it fixes the current code. Felipe: Maybe you should add some message stating it fixes a regression? sure, makes sense. Sebastian had already mentioned it sounded too nice of a commit log ;-) I'm looking at -rc2 and it seems the fix was never pushed, so my board is probably still broken :-( Can anybody _please_please_ fix the issue by merging some fix so we can use USB with mainline? (FWIW, the fix from Felipe (pointed out by Sebastian) is sitting at linux-next). Thanks a lot! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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] usb: phy: am335x: Prevent GPIO reset line request
The 'gpio_reset' field was implicitly set to zero, which is a valid GPIO line and results in the NOP PHY layer trying to request it. Instead, the AM335x SoC need special USB PHY reset handling so let's set 'gpio_reset' to EINVAL and prevent the NOP PHY from messing with it. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Commit bd27fa44e13830d2baa278d5702e766380659cb3 (usb: phy: generic: Don't use regulator framework for RESET line) introduced this. drivers/usb/phy/phy-am335x.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c index 6370e50..7fff9f3 100644 --- a/drivers/usb/phy/phy-am335x.c +++ b/drivers/usb/phy/phy-am335x.c @@ -43,6 +43,9 @@ static int am335x_phy_probe(struct platform_device *pdev) if (!am_phy) return -ENOMEM; + /* Prevent GPIO Reset from the Generic PHY */ + am_phy-usb_phy_gen.gpio_reset = -EINVAL; + am_phy-phy_ctrl = am335x_get_phy_control(dev); if (!am_phy-phy_ctrl) return -EPROBE_DEFER; -- 1.8.1.5 -- 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: phy: am335x: Prevent GPIO reset line request
(Forgot to Cc OMAP people) On Wed, Nov 20, 2013 at 06:58:34PM -0300, Ezequiel Garcia wrote: The 'gpio_reset' field was implicitly set to zero, which is a valid GPIO line and results in the NOP PHY layer trying to request it. Instead, the AM335x SoC need special USB PHY reset handling so let's set 'gpio_reset' to EINVAL and prevent the NOP PHY from messing with it. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Commit bd27fa44e13830d2baa278d5702e766380659cb3 (usb: phy: generic: Don't use regulator framework for RESET line) introduced this. drivers/usb/phy/phy-am335x.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c index 6370e50..7fff9f3 100644 --- a/drivers/usb/phy/phy-am335x.c +++ b/drivers/usb/phy/phy-am335x.c @@ -43,6 +43,9 @@ static int am335x_phy_probe(struct platform_device *pdev) if (!am_phy) return -ENOMEM; + /* Prevent GPIO Reset from the Generic PHY */ + am_phy-usb_phy_gen.gpio_reset = -EINVAL; + am_phy-phy_ctrl = am335x_get_phy_control(dev); if (!am_phy-phy_ctrl) return -EPROBE_DEFER; -- 1.8.1.5 -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH v2 0/4] Add phy support for AM335X platform using Generic PHy framework
On Fri, Jul 19, 2013 at 06:04:33PM +0530, George Cherian wrote: This patch series adds phy support for AM335X platform. This patch series is based on Generic PHY framework [1]. This series has - adds dual musb instances support for am335x platform - adds phy-am-usb driver used in AM platforms - adds OTG callbacks - adds PHY wakeup enable/disable - adds dt bindings for the phys - removes usb-phy and replaced with generic phy apis in glue layer All these changes are avilable at [2] [1] - http://marc.info/?l=linux-usbm=137224750928570w=2 [2] - git://git.ti.com/~georgecherian/ti-linux-kernel/georgec-connectivity-linux-feature-tree.git am335x-phy-driver-v2 George Cherian (4): usb: phy: phy-omap-control: Add API to power and wakeup phy: phy-am-usb: Add PHY driver for am platform arm: dts: Add USB phy nodes for AM33XX Is there any reason why there's no DT binding patch to this series? (aka Documentation/devicetree/... + sent to devicetree list) (sorry if this has been already explained somewhere...) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: musb: dsps: make it work with two instances
Hi Sebastian, On Wed, Jul 17, 2013 at 07:12:29PM +0200, Sebastian Andrzej Siewior wrote: After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? Beaglebone black it is. But I'm almost sure I just used the ambone.dts file that's mainlined. I just changed the mode or something like that, very minor tweaking indeed, altough right now I don't remember exactly which changes. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Mmmm... okey. Interesting insight, thanks! Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? No, of course not. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
Hi, On Mon, Jul 08, 2013 at 09:44:33PM +0200, Sebastian Andrzej Siewior wrote: We need two nodes each one with a glue layer and a musb child node. The instances crap in kernel has to vanish. Also that means your phy nodes are wrong. This is not musb with two ports but two musb instances each with one port. I agree completely. The current DT representation looks definitely odd, and we should be looking at improving it. I wonder if this is now possible, given the DT is supposed to be stable ABI. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: musb: dsps: make it work with two instances
Hi Sebastian, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. Nice job! -- Ezequiel -- 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
Hi Arnd, On Fri, Feb 15, 2013 at 11:12:29PM +0100, Arnd Bergmann wrote: 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. s/Morvell/Marvell Just this tiny nitpick. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [V2 0/8] usb: ehci: more bus glues as separate modules
Hi Manjunath, Nice job! On Fri, Feb 15, 2013 at 03:54:05PM +0530, 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 If at all possible, I'd still like to see a better commit message explaining why we need this at all, as it has been previously requested. I guess there has been some discussion about this rework somewhere. It would be nice to add a link to that discussion in the commit message or in the cover letter so reviewers can have better context. Manjunath Goudar (8): USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-mv as separate static driver USB: EHCI: make ehci-vt8500 a separate driver USB: EHCI: make ehci-msm a separate driver USB: EHCI: make ehci-w90X900 a separate driver USB: EHCI: make ehci-orion a separate driver drivers/usb/host/Kconfig| 40 +++-- drivers/usb/host/Makefile |9 +++- drivers/usb/host/ehci-atmel.c | 76 drivers/usb/host/ehci-hcd.c | 52 +- drivers/usb/host/ehci-msm.c | 85 drivers/usb/host/ehci-mv.c | 78 +++-- drivers/usb/host/ehci-orion.c | 90 ++ drivers/usb/host/ehci-s5p.c | 67 +++- drivers/usb/host/ehci-spear.c | 77 + drivers/usb/host/ehci-vt8500.c | 73 ++- drivers/usb/host/ehci-w90x900.c | 91 +-- drivers/usb/host/ehci.h |2 +- 12 files changed, 358 insertions(+), 382 deletions(-) -- 1.7.9.5 Thanks a lot, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH 00/10] usb: ehci: more bus glues as separate modules
Hi Manjunath, Nice work. On Thu, Feb 07, 2013 at 11:03:57PM +0530, 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. Perhaps you could add a few lines explaining why you're doing this. Manjunath Goudar (10): USB:Changed omap2plus_defconfig to support OMAP USB static driver USB: EHCI: make ehci-omap a separate driver USB: EHCI: make ehci-spear a separate driver USB: EHCI: make ehci-orion a separate driver USB: EHCI: make ehci-atmel a separate driver USB: EHCI: make ehci-s5p a separate driver USB: EHCI: make ehci-mv a separate driver USB: EHCI: make ehci-vt8500 a separate driver USB: EHCI: make ehci-msm a separate driver USB: EHCI: make ehci-w90X900 a separate driver arch/arm/configs/omap2plus_defconfig |4 ++ drivers/usb/host/Kconfig | 43 --- drivers/usb/host/Makefile| 10 +++- drivers/usb/host/ehci-atmel.c| 78 ++- drivers/usb/host/ehci-hcd.c | 75 +++--- drivers/usb/host/ehci-msm.c | 84 + drivers/usb/host/ehci-mv.c | 81 +--- drivers/usb/host/ehci-omap.c | 69 ++-- drivers/usb/host/ehci-orion.c| 98 +- drivers/usb/host/ehci-s5p.c | 69 +--- drivers/usb/host/ehci-spear.c| 77 +- drivers/usb/host/ehci-vt8500.c | 73 - drivers/usb/host/ehci-w90x900.c | 90 ++- 13 files changed, 415 insertions(+), 436 deletions(-) -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
Hi Jason, On Wed, Jan 23, 2013 at 2:40 PM, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote: Jason, On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: The Armada 370 and Armada XP SoC has an Orion EHCI USB controller. This patch adds support for this controller in Armada 370 and Armada XP SoC common device tree files. Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org Tested-by: Florian Fainelli flor...@openwrt.org Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Changes from v1: * Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian. arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++ arch/arm/boot/dts/armada-370.dtsi|9 + arch/arm/boot/dts/armada-xp.dtsi | 17 + 3 files changed, 41 insertions(+), 0 deletions(-) Do you think we're still in time to get this series into v3.9 (given we decide soon on the OpenBlocks issue)? That shouldn't be a problem. Do you think we can take this series for v3.9 as it is? I have no problems making any changes if they are needed but I can't move forward with the OpenBlocks issue since I don't have access to the hardware. I think we can sanely merge this as it is, since it has been tested in every platform. If there's anything to change we can do it later, when I have more information about the OpenBlocks hardware. Thanks, -- Ezequiel -- 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 3/3] arm: mvebu: Update defconfig to select USB support
Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Gregory CLEMENT gregory.clem...@free-electrons.com Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org Tested-by: Florian Fainelli flor...@openwrt.org Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index c3c6326..f8d0183 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -42,7 +42,10 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y -# CONFIG_USB_SUPPORT is not set +CONFIG_USB_SUPPORT=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_RTC_CLASS=y -- 1.7.8.6 -- 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 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
This patch activates every USB port provided by each SoC.
Except for Armada XP Openblocks AX3-4 board,
where we enable only the first two USB ports
until we have more information on the third one usage.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Squashed separate per-board patches into this one,
as suggested by Arnd.
* Remove usb@d0052000 activation in OpenBlocks AX3-4
until we have more information about it.
arch/arm/boot/dts/armada-370-db.dts |8
arch/arm/boot/dts/armada-370-mirabox.dts |8
arch/arm/boot/dts/armada-xp-db.dts | 12
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |6 ++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 1864820..dd0c57d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -62,5 +62,13 @@
* Wifi/Bluetooth chip
*/
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
+
+ usb@d0052000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index ec36864..3818a82 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -133,5 +133,11 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
--
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 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Hi Nobuhiro,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
This patch activates every USB port provided by each SoC.
Except for Armada XP Openblocks AX3-4 board,
where we enable only the first two USB ports
until we have more information on the third one usage.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Squashed separate per-board patches into this one,
as suggested by Arnd.
* Remove usb@d0052000 activation in OpenBlocks AX3-4
until we have more information about it.
arch/arm/boot/dts/armada-370-db.dts |8
arch/arm/boot/dts/armada-370-mirabox.dts |8
arch/arm/boot/dts/armada-xp-db.dts | 12
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |6 ++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 1864820..dd0c57d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -62,5 +62,13 @@
* Wifi/Bluetooth chip
*/
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
+
+ usb@d0052000 {
+ status = okay;
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index ec36864..3818a82 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -133,5 +133,11 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
I'd like to bring this patch to your attention.
As you can see, I've removed the
usb@d0052000 {
status = okay;
};
from the OpenBlocks AX3-4 board dts file, since you mentioned this
board uses that USB
port for a PCIe connector -- if I understood correctly.
It's interesting to note that Mirabox board doesn't provide direct
access to its USB ports either,
but instead they are used to connect a GL827L MMC card reader.
However, we activate USB ports anyway, since it's needed for that to work fine.
So, IMHO, if OpenBlocks uses third USB port to connect some PCIe controller,
we should activate it in the dts file.
What do you think?
--
Ezequiel
--
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/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
Jason,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Tested-by: Florian Fainelli flor...@openwrt.org
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian.
arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++
arch/arm/boot/dts/armada-370.dtsi|9 +
arch/arm/boot/dts/armada-xp.dtsi | 17 +
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 28276fe..fa025c4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -145,6 +145,21 @@
clocks = gateclk 17;
status = disabled;
};
+
+ usb@d005 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd005 0x500;
+ interrupts = 45;
+ status = disabled;
+ };
+
+ usb@d0051000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0051000 0x500;
+ interrupts = 46;
+ status = disabled;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 88f9bab..8188d13 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -144,5 +144,14 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = coreclk 0;
+ };
+
+ usb@d0051000 {
+ clocks = coreclk 0;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi
b/arch/arm/boot/dts/armada-xp.dtsi
index 2e37ef1..c22a0c8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,5 +134,22 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = gateclk 18;
+ };
+
+ usb@d0051000 {
+ clocks = gateclk 19;
+ };
+
+ usb@d0052000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0052000 0x500;
+ interrupts = 47;
+ clocks = gateclk 20;
+ status = disabled;
+ };
+
};
};
--
1.7.8.6
Do you think we're still in time to get this series into v3.9 (given
we decide soon on the OpenBlocks issue)?
Thanks,
--
Ezequiel
--
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 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
Hi Thomas, On Wed, Jan 23, 2013 at 3:03 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote: from the OpenBlocks AX3-4 board dts file, since you mentioned this board uses that USB port for a PCIe connector -- if I understood correctly. No. The OpenBlocks has a different USB controller that sits on the PCIe bus. There is nothing like a PCIe port that uses a USB port, that doesn't make sense. Mmm... indeed, I got it completely wrong. So, IMHO, if OpenBlocks uses third USB port to connect some PCIe controller, we should activate it in the dts file. What do you think? No, see above. So, what do you think about the patch series to be pushed as it is? -- Ezequiel -- 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 5/6] arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
Hi Nobuhiro,
On Tue, Jan 15, 2013 at 9:01 PM, Nobuhiro Iwamatsu iwama...@nigauri.org wrote:
Hi,
On Tue, Jan 15, 2013 at 6:54 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index b24644f..55f5b6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -127,5 +127,14 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
+ usb@d0052000 {
+ status = okay;
+ };
USB2 of openblocks-ax3-4 is used as Mini-PCIE.
I think this is unnecessary.
Mmm... could you explain this with some more detail.
Unfortunately, I don't have access to an Openblocks board to check on this,
so I'd appreciate any clarification.
Is there any Openblocks datasheet or hardware schematics publicly
available for me to look at?
Thanks a lot,
--
Ezequiel
--
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/6] arm: mvebu: Enable USB controllers on Armada 370 evaluation board
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = disabled;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
--
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 4/6] arm: mvebu: Enable USB controllers on Armada XP evaluation board
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-db.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = okay;
/* No CD or WP GPIOs */
};
+
+ usb@d005 {
+ status = okay;
+ };
+
+ usb@d0051000 {
+ status = okay;
+ };
+
+ usb@d0052000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
--
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 5/6] arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index b24644f..55f5b6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -127,5 +127,14 @@
nr-ports = 2;
status = okay;
};
+ usb@d005 {
+ status = okay;
+ };
+ usb@d0051000 {
+ status = okay;
+ };
+ usb@d0052000 {
+ status = okay;
+ };
};
};
--
1.7.8.6
--
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 1/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP
The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Cc: Lior Amsalem al...@marvell.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++
arch/arm/boot/dts/armada-370.dtsi|9 +
arch/arm/boot/dts/armada-xp.dtsi | 17 +
arch/arm/mach-mvebu/Kconfig |1 +
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 28276fe..fa025c4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -145,6 +145,21 @@
clocks = gateclk 17;
status = disabled;
};
+
+ usb@d005 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd005 0x500;
+ interrupts = 45;
+ status = disabled;
+ };
+
+ usb@d0051000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0051000 0x500;
+ interrupts = 46;
+ status = disabled;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 88f9bab..8188d13 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -144,5 +144,14 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = coreclk 0;
+ };
+
+ usb@d0051000 {
+ clocks = coreclk 0;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 390ba98..1443949 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,5 +134,22 @@
dmacap,memset;
};
};
+
+ usb@d005 {
+ clocks = gateclk 18;
+ };
+
+ usb@d0051000 {
+ clocks = gateclk 19;
+ };
+
+ usb@d0052000 {
+ compatible = marvell,orion-ehci;
+ reg = 0xd0052000 0x500;
+ interrupts = 47;
+ clocks = gateclk 20;
+ status = disabled;
+ };
+
};
};
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..5e4fcde 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP
select HAVE_SMP
select CACHE_L2X0
select CPU_PJ4B
+ select USB_ARCH_HAS_EHCI if USB_SUPPORT
config MACH_ARMADA_370
bool Marvell Armada 370 boards
--
1.7.8.6
--
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 6/6] arm: mvebu: Update defconfig to select USB support
Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Gregory CLEMENT gregory.clem...@free-electrons.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index c3c6326..f8d0183 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -42,7 +42,10 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y -# CONFIG_USB_SUPPORT is not set +CONFIG_USB_SUPPORT=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_RTC_CLASS=y -- 1.7.8.6 -- 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 0/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP
Hi, This small patch set enables USB support on Armada 370 and Armada XP platforms. It's based on Jason Cooper's mvebu/dt branch. Any comments or feedback are welcome. Ezequiel Garcia (6): arm: mvebu: Add support for USB host controllers in Armada 370/XP arm: mvebu: Enable USB controllers on Armada 370 evaluation board arm: mvebu: Enable USB controllers on Armada 370 Mirabox board arm: mvebu: Enable USB controllers on Armada XP evaluation board arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board arm: mvebu: Update defconfig to select USB support arch/arm/boot/dts/armada-370-db.dts |8 arch/arm/boot/dts/armada-370-mirabox.dts |8 arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++ arch/arm/boot/dts/armada-370.dtsi|9 + arch/arm/boot/dts/armada-xp-db.dts | 12 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 + arch/arm/boot/dts/armada-xp.dtsi | 17 + arch/arm/configs/mvebu_defconfig |5 - arch/arm/mach-mvebu/Kconfig |1 + 9 files changed, 83 insertions(+), 1 deletions(-) Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH 1/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP
Hi Florian, On 01/15/2013 07:23 AM, Florian Fainelli wrote: Le 01/15/13 10:54, Ezequiel Garcia a écrit : diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 440b13e..5e4fcde 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP select HAVE_SMP select CACHE_L2X0 select CPU_PJ4B +select USB_ARCH_HAS_EHCI if USB_SUPPORT I do not think this is actually required because ARCH_MVEBU selects PLAT_ORION and in drivers/usb/host/Kconfig, USB_ARCH_HAS_EHCI is default y if PLAT_ORION. Having USB_ARCH_HAS_EHCI without USB_SUPPORT enabled is pretty harmless. Yes, you're right, this is not needed. Nice catch and thanks for the review, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
Re: [PATCH 2/6] arm: mvebu: Enable USB controllers on Armada 370 evaluation board
Hi Arnd, On 01/15/2013 10:07 AM, Arnd Bergmann wrote: On Tuesday 15 January 2013, Ezequiel Garcia wrote: Cc: Lior Amsalem al...@marvell.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Gregory CLEMENT gregory.clem...@free-electrons.com Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com The patches look good, but when you have four trivial patches doing the same thing in different files, and you decide that it's not worth writing a changelog for them, they should probably go into a single patch. Mmm... maybe you're right and such splitting is excessive. It seemed tidier this way, enabling each board on a different patch. I can squash them on a v2, if you want me to. Thanks for reviewing! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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
