Re: USB on Beaglebone black with mainline kernel
Hi George, On 2014-05-02 07:54, George Cherian wrote: Hi Leigh, Can you please try out 3.15.0-rc3 with the attached config. Thanks, that works (I can't believe it was that easy)! I'll use that as a known-good config and then try to tweak the config to how I like it. Regards, Leigh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB on Beaglebone black with mainline kernel
Hello,
I'm trying to run the mainline kernel on my Beaglebone Black and things
are working quite well, apart from USB. There have been a few patches
recently that have improved things, but right now I'm at the point where
I could do with a pointer in the right direction.
The main issue now is this :-
usb 2-1: new high-speed USB device number 2 using musb-hdrc
musb-hdrc musb-hdrc.1.auto: qh dc059c80 urb dc059b00 dev0 ep0out, hw_ep
0, dc2c5040/8
musb-hdrc musb-hdrc.1.auto: -- hw0 urb dc059b00 spd3 dev0 ep0out
h_addr00 h_port00 bytes 8
musb-hdrc musb-hdrc.1.auto: TX ep0 fifo e0eb2e00 count 8 buf dc2c5040
musb-hdrc musb-hdrc.1.auto: Start TX0 pio
musb-hdrc musb-hdrc.1.auto: usbintr (0) epintr(1)
musb-hdrc musb-hdrc.1.auto: ** IRQ host usb tx0001 rx
musb-hdrc musb-hdrc.1.auto: == csr0 0010, qh dc059c80, count 0, urb
dc059b00, stage 1
musb-hdrc musb-hdrc.1.auto: no response, csr0 0010
musb-hdrc musb-hdrc.1.auto: aborting
musb-hdrc musb-hdrc.1.auto: complete dc059b00
usb_api_blocking_completion+0x0/0x14 [usbcore] (-71), dev0 ep0in, 0/64
and my usb stick is not detected. The usb stick is detected fine with
the
linux-3.8.13-bone43-201405011132 kernel.
Complete dmesg and other interesting files are here (I've used #define
DEBUG 1 on relevant files) :-
http://www.solinno.co.uk/public/bbb/linux-3.15.0-rc3+-201405011446/
Same stuff for working kernel :-
http://www.solinno.co.uk/public/bbb/linux-3.8.13-bone43-201405011132/
I'd really appreciate any assistance - does anyone have a working config
for a recent mainline kernel?
Thanks,
Leigh.
Addendum - I've been tinkering without really knowing what I'm doing,
but nothing has helped so far.
I've tried is adding clock details into the am33xx.dtsi for the USB phys
:-
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index cb6811e..027d7fb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -467,6 +467,8 @@
reg-names = phy;
status = disabled;
ti,ctrl_mod = usb_ctrl_mod;
+ clocks = usbotg_fck 0;
+ clock-names = main_clk;
};
usb0: usb@47401000 {
@@ -515,6 +517,8 @@
reg-names = phy;
status = disabled;
ti,ctrl_mod = usb_ctrl_mod;
+ clocks = usbotg_fck 0;
+ clock-names = main_clk;
};
usb1: usb@47401800 {
However it didn't seem to help. I also tried to force phy detection
using usb_bind_phy() :-
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-gen
index b8920b6..7218515 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/usb/phy.h
#include asm/mach/arch.h
@@ -40,6 +41,12 @@ static void __init omap_generic_init(void)
pdata_quirks_init(omap_dt_match_table);
omapdss_init_of();
+
+ if (of_machine_is_compatible(ti,am33xx)) {
+ pr_info(horrible hack: adding usb bindings for
am335x\n);
+ usb_bind_phy(musb-hdrc.0.auto, 0, 47401300.usb-phy);
+ usb_bind_phy(musb-hdrc.1.auto, 0, 47401b00.usb-phy);
+ }
}
#ifdef CONFIG_SOC_OMAP2420
This hasn't helped either.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] usb: phy: generic: allow multiples calls to usb_phy_generic_register()
On 2014-04-16 22:26, Felipe Balbi wrote:
it's now very easy to return a platform_device pointer
and have the caller pass it as argument when calling
usb_phy_generic_unregister().
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/am35x.c| 12 +---
drivers/usb/musb/blackfin.c | 10 --
drivers/usb/musb/da8xx.c| 14 +++---
drivers/usb/musb/tusb6010.c | 3 ++-
drivers/usb/phy/phy-generic.c | 19 +--
include/linux/usb/usb_phy_generic.h | 8
6 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 05459b5..0a34dd8 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -85,6 +85,7 @@
struct am35x_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
struct clk *phy_clk;
struct clk *clk;
};
@@ -503,7 +504,9 @@ static int am35x_probe(struct platform_device
*pdev)
pdata-platform_ops = am35x_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy))
+ goto err7;
platform_set_drvdata(pdev, glue);
pinfo = am35x_dev_info;
@@ -517,11 +520,14 @@ static int am35x_probe(struct platform_device
*pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err7;
+ goto err8;
}
return 0;
+err8:
+ usb_phy_generic_unregister(glue-phy);
+
err7:
clk_disable(clk);
@@ -546,7 +552,7 @@ static int am35x_remove(struct platform_device
*pdev)
struct am35x_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
clk_put(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 53acffe..d40d5f0 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -29,6 +29,7 @@
struct bfin_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -475,7 +476,9 @@ static int bfin_probe(struct platform_device *pdev)
pdata-platform_ops = bfin_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy))
+ goto err2;
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -513,6 +516,9 @@ static int bfin_probe(struct platform_device *pdev)
return 0;
err3:
+ usb_phy_generic_unregister(glue-phy);
+
+err2:
platform_device_put(musb);
err1:
@@ -527,7 +533,7 @@ static int bfin_remove(struct platform_device
*pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
kfree(glue);
return 0;
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 024751f..058775e 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -85,6 +85,7 @@
struct da8xx_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
struct clk *clk;
};
@@ -510,7 +511,11 @@ static int da8xx_probe(struct platform_device
*pdev)
pdata-platform_ops = da8xx_ops;
- usb_phy_generic_register();
+ glue-phy = usb_phy_generic_register();
+ if (IS_ERR(glue-phy)) {
+ ret = PTR_ERR(glue-phy);
+ goto err5;
+ }
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -537,11 +542,14 @@ static int da8xx_probe(struct platform_device
*pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
- goto err5;
+ goto err6;
}
return 0;
+err6:
+ usb_phy_generic_unregister(glue-phy);
+
err5:
clk_disable(clk);
@@ -560,7 +568,7 @@ static int da8xx_remove(struct platform_device
*pdev)
struct da8xx_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue-phy);
clk_disable(glue-clk);
clk_put(glue-clk);
kfree(glue);
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
Re: [PATCH 5/8] usb: phy: rename usb_nop_xceiv to usb_phy_generic
On 2014-04-16 22:26, Felipe Balbi wrote:
no functional changes, just renaming the function
in order to make it slightly clearer what it should
be used for, also matching the driver name.
Signed-off-by: Felipe Balbi ba...@ti.com
---
[...]
diff --git a/include/linux/usb/usb_phy_gen_xceiv.h
b/include/linux/usb/usb_phy_gen_xceiv.h
index cc8d818..c00176d 100644
--- a/include/linux/usb/usb_phy_gen_xceiv.h
+++ b/include/linux/usb/usb_phy_gen_xceiv.h
@@ -3,7 +3,7 @@
#include linux/usb/otg.h
-struct usb_phy_gen_xceiv_platform_data {
+struct usb_phy_generic_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
@@ -15,14 +15,14 @@ struct usb_phy_gen_xceiv_platform_data {
#if defined(CONFIG_NOP_USB_XCEIV) ||
(defined(CONFIG_NOP_USB_XCEIV_MODULE) defined(MODULE))
/* sometimes transceivers are accessed only through e.g. ULPI */
-extern void usb_nop_xceiv_register(void);
-extern void usb_nop_xceiv_unregister(void);
+extern void usb_phy_generic_register(void);
+extern void usb_phy_generic_unregister(void);
#else
-static inline void usb_nop_xceiv_register(void)
+static inline void usb_phy_generic_register(void)
{
}
-static inline void usb_nop_xceiv_unregister(void)
+static inline void usb_phy_generic_unregister(void)
{
}
#endif
I applied this against mainline and arch/arm/mach-omap2/usb-host.c also
needed to be fixed up.
Regards,
Leigh.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] ARM: dts: am335x: update USB DT references
In ARM: dts: am33xx: correcting dt node unit address for usb, the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses. However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.
This patch corrects the references for the affected dts files.
Signed-off-by: Leigh Brown le...@solinno.co.uk
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
arch/arm/boot/dts/am335x-evmsk.dts| 4 ++--
arch/arm/boot/dts/am335x-igep0033.dtsi| 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..2e7d932 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -183,7 +183,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -204,7 +204,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 28ae040..77df10d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -331,7 +331,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -352,7 +352,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ec08f6f..ab23885 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -364,7 +364,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -385,7 +385,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 7063311..5942e7d 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -202,7 +202,7 @@
usb {
status = okay;
- control@44e1 {
+ control@44e10620 {
status = okay;
};
@@ -223,7 +223,7 @@
dr_mode = host;
};
- dma-controller@07402000 {
+ dma-controller@47402000 {
status = okay;
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help running latest linux-omap kernel on Nokia N810
On 2014-02-27 07:19, Tomi Valkeinen wrote: On 26/02/14 23:29, Aaro Koskinen wrote: First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some It would've been a big effort to keep the panel driver compiling, as we moved to a new display driver architecture. And, as it wasn't working anyway, I deemed it simpler to just remove it. I have no objections to add it back, but it needs to be split into two separate drivers, blizzard encoder driver and the panel driver. The RFBI driver also probably needs some love. And, of course, DT support for all those. In theory, RFBI is relatively simple. If I recall right, the panel is also quite simple, although it still needs to be controlled via SPI. Blizzard was a bit more complex one, but perhaps most of its features can be just left out. But getting all those three working fine without being able to make any measurements between the components, well, one might needs some luck there =). I do have N800 and N810 (no serial mods), so I might be able to give some help there at some point, if I'm able to boot the board with usb gadget ethernet (which hasn't been working for me for omap3 for some time). Hi Tomi, In the following commit it states that you ported the old blizzard driver to the new omapdss driver: commit fdcb68884b3b0def9cc410d07adbafe7c3a9e537 Author: Tomi Valkeinen tomi.valkei...@ti.com Date: Tue May 10 17:31:20 2011 +0300 OMAPFB: remove old blizzard driver N8x0's blizzard driver has been ported to new omapdss driver, so we can now remove the old blizzard driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Did that driver work on the N810 at that point? If I look at the kernel tree at that point in time would all the components be there? It would make it easier if I had a starting point as I don't have any documentation so reading the old source code is the only way I can figure out how things work(ed). Regards, Leigh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] RETU meets Sparse IRQ
On Wed, 29 Jun 2011 14:46:49 +0300, Felipe Balbi wrote: now with Sparse IRQ numbering, we don't need to add a bunch of defines in plat/irqs.h Compile tested with omap2plus_defconfig (+cbus) and omap1_defconfig (+cbus). Felipe Balbi (2): cbus: retu: use sparse IRQ numbering cbus: retu: stop polluting plat/irqs.h arch/arm/mach-omap1/board-nokia770.c |2 -- arch/arm/mach-omap2/board-n8x0.c |2 -- arch/arm/plat-omap/include/plat/irqs.h | 10 +- drivers/cbus/retu.c| 25 - include/linux/platform_data/cbus.h |2 -- 5 files changed, 17 insertions(+), 24 deletions(-) Tested-by: Leigh Brown le...@solinno.co.uk Booted fine on my N810. Regards, Leigh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] input: keypad: lm8323: use level triggered interrupts
This patch, which should be applied on top of Felipe's
input: keypad: lm8323: convert to threaded IRQ patch, fixes the issue
of the Nokia N810 keypad stopping responding if multiple key events
occur
in quick succession.
Signed-off-by: Leigh Brown le...@solinno.co.uk
---
drivers/input/keyboard/lm8323.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c
b/drivers/input/keyboard/lm8323.c
index 3b21f42..ab0acaf 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -734,7 +734,7 @@ static int __devinit lm8323_probe(struct i2c_client
*client,
}
err = request_threaded_irq(client-irq, NULL, lm8323_irq,
- IRQF_TRIGGER_FALLING, lm8323, lm);
+ IRQF_TRIGGER_LOW|IRQF_ONESHOT, lm8323, lm);
if (err) {
dev_err(client-dev, could not get IRQ %d\n, client-irq);
goto fail4;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: keypad: lm8323: convert to threaded IRQ
Hi Felipe,
Many thanks for trying to assist me with my problem. To recap,
I'm seeing the keypad lock-up on my N810 using this driver,
when I type quickly.
I tried your patch, and it doesn't fix the issue. However, I've
read the datasheet for the lm8323 and it looks to me like the
interrupt should be level rather than edge triggered.
The following additional patch makes things work for me. I
couldn't tell you if it's the correct thing to do but I can no
longer cause the keypad to lock-up by typing too fast.
Regards,
Leigh.
--
diff --git a/drivers/input/keyboard/lm8323.c
b/drivers/input/keyboard/lm8323.c
index 3b21f42..ab0acaf 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -734,7 +734,7 @@ static int __devinit lm8323_probe(struct i2c_client
*client,
}
err = request_threaded_irq(client-irq, NULL, lm8323_irq,
- IRQF_TRIGGER_FALLING, lm8323, lm);
+ IRQF_TRIGGER_LOW|IRQF_ONESHOT, lm8323, lm);
if (err) {
dev_err(client-dev, could not get IRQ %d\n, client-irq);
goto fail4;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: keypad: lm8323: convert to threaded IRQ
On Sun, 19 Jun 2011 22:56:06 +0300, Felipe Balbi wrote: Hi, On Sun, Jun 19, 2011 at 07:00:13PM +, Leigh Brown wrote: Many thanks for trying to assist me with my problem. To recap, yeah, no problem ;-) I'm seeing the keypad lock-up on my N810 using this driver, when I type quickly. I tried your patch, and it doesn't fix the issue. However, I've read the datasheet for the lm8323 and it looks to me like the interrupt should be level rather than edge triggered. The following additional patch makes things work for me. I couldn't tell you if it's the correct thing to do but I can no longer cause the keypad to lock-up by typing too fast. good good. Looks like IRQF_ONESHOT is what did the trick. Did you check if IRQF_ONESHOT alone was enough ? I tried that first, but it didn't fix it, although it makes it a little bit harder to trigger. I've just tried again to be sure, but I got a lock-up quite easily. Regards, Leigh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
