Skip to contentSkip to conversation

DM644x EVM: register MUSB device earlier

PATCH New Sergei Shtylyov 6 participants 12 messages Mar 13, 2011 – Mar 16, 2011

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

The MUSB driver doesn't see its platform device on DM644x EVM board anymore since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci to its own platform_driver) because the new probe is called as subsys_initcall() now, and the device is registered later than that by the board code. Move the registration to davinci_evm_init() -- it's safe to do so because the MUSB core device still gets initialized as fs_initcall() -- which is late enough for the I2C GPIO expander (which controls VBUS) to be initialized.

---
The patch is against the recent DaVinci tree.
It fixes post 2.6.38-rc1 regression, so should be applied immediately!

 arch/arm/mach-davinci/board-dm644x-evm.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
arch/arm/mach-davinci/board-dm644x-evm.c +3 -5
Index: linux-davinci/arch/arm/mach-davinci/board-dm644x-evm.c
===================================================================
@@ -440,11 +440,6 @@ evm_u35_setup(struct i2c_client *client,
 	gpio_request(gpio + 7, "nCF_SEL");
 	gpio_direction_output(gpio + 7, 1);
 
-	/* irlml6401 switches over 1A, in under 8 msec;
-	 * now it can be managed by nDRV_VBUS ...
-	 */
-	davinci_setup_usb(1000, 8);
-
 	return 0;
 }
 
@@ -705,6 +700,9 @@ static __init void davinci_evm_init(void
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_evm_snd_data);
 
+	/* irlml6401 switches over 1A, in under 8 msec */
+	davinci_setup_usb(1000, 8);
+
 	soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID;
 	/* Register the fixup for PHY on DaVinci */
 	phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
#1 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 9 lines · Sergei Shtylyov

The MUSB driver doesn't see its platform device on DM644x EVM board anymore since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci to its own platform_driver) because the new probe is called as subsys_initcall() now, and the device is registered later than that by the board code. Move the registration to davinci_evm_init() -- it's safe to do so because the MUSB core device still gets initialized as fs_initcall() -- which is late enough for the I2C GPIO expander (which controls VBUS) to be initialized.

Kevin feel free to take this into your tree:

Quoted 3 lines

---
The patch is against the recent DaVinci tree.
It fixes post 2.6.38-rc1 regression, so should be applied immediately!

I wonder how noone has noticed that from -rc1 until now.

Signature · 1 line
balbi
#3 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 11 lines · Kevin

Felipe Balbi <[email protected]> writes:

[...]

Quoted 5 lines

Kevin feel free to take this into your tree:

OK, will queue for 2.6.39.

This will need to make into 2.6.38.

Hi Russell,

Without this fix, USB will remain broken on 2.6.38 on DM644x EVM. Any chance of this making into 2.6.38?

Shall I check this into your patch system?

Thanks,
Sekhar

#4 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 13 lines · Sekhar
Quoted 11 lines · Kevin

Felipe Balbi <[email protected]> writes:

[...]

Quoted 5 lines

Kevin feel free to take this into your tree:

OK, will queue for 2.6.39.

Quoted 8 lines

This will need to make into 2.6.38.

Hi Russell,

Without this fix, USB will remain broken on 2.6.38 on DM644x EVM. Any chance of this making into 2.6.38?

Shall I check this into your patch system?

The answer to that is in Kevin's reply. Kevin is handling the patch as current maintainer of Davinci.

#5 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Sekhar
Quoted 11 lines · Kevin

Felipe Balbi <[email protected]> writes:

[...]

Quoted 5 lines

Kevin feel free to take this into your tree:

OK, will queue for 2.6.39.

This will need to make into 2.6.38.

Hi Russell,

Quoted 7 lines
Quoted 4 lines

Without this fix, USB will remain broken on 2.6.38 on DM644x EVM. Any chance of this making into 2.6.38?

Shall I check this into your patch system?

The answer to that is in Kevin's reply. Kevin is handling the patch as current maintainer of Davinci.

Okay. Linus has already released 2.6.38; will queue this for Kevin to send for 2.6.39.

Thanks,
Sekhar

#6 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Hello.

Quoted 16 lines · Sekhar
Quoted 15 lines
Quoted 15 lines
Quoted 9 lines

Felipe Balbi <[email protected]> writes:

[...]

Quoted 3 lines

Kevin feel free to take this into your tree:

OK, will queue for 2.6.39.

This will need to make into 2.6.38.

Hi Russell,

Without this fix, USB will remain broken on 2.6.38 on DM644x EVM. Any chance of this making into 2.6.38?

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

Shall I check this into your patch system?

The answer to that is in Kevin's reply. Kevin is handling the patch as current maintainer of Davinci.

Okay. Linus has already released 2.6.38; will queue this for Kevin to send for 2.6.39.

Could you add "Cc: stable at kernel.org" to the patch as 2.6.38 have now been
missed (damn that virus I've caught :-)?

WBR, Sergei

#7 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

In reply to Felipe Balbi

Hello.

Quoted 8 lines · Felipe Balbi
Quoted 7 lines

The MUSB driver doesn't see its platform device on DM644x EVM board anymore since commit 73b089b052a69020b953312a624a6e1eb5b81fab (usb: musb: split davinci to its own platform_driver) because the new probe is called as subsys_initcall() now, and the device is registered later than that by the board code. Move the registration to davinci_evm_init() -- it's safe to do so because the MUSB core device still gets initialized as fs_initcall() -- which is late enough for the I2C GPIO expander (which controls VBUS) to be initialized.

Quoted 5 lines
Quoted 1 line

Kevin feel free to take this into your tree:

Thanks.

Quoted 5 lines
Quoted 3 lines

---
The patch is against the recent DaVinci tree.
It fixes post 2.6.38-rc1 regression, so should be applied immediately!

I wonder how noone has noticed that from -rc1 until now.

I don't think many people run the most current DaVinci kernel. Most people
probably use the Arago project kernels or even older MV-based TI's stuff...

WBR, Sergei

#8 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Hi,

Quoted 5 lines · Sergei Shtylyov
Quoted 1 line

I wonder how noone has noticed that from -rc1 until now.

I don't think many people run the most current DaVinci kernel.
Most people probably use the Arago project kernels or even older MV-based TI's stuff...

that's nasty :-p All those hacks on a 2.6.18 kernel... Oh well, thanks for noticing and sending a patch :-)

Signature · 1 line
balbi
#9 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Hello.

Quoted 7 lines · Felipe Balbi
Quoted 5 lines
Quoted 1 line

I wonder how noone has noticed that from -rc1 until now.

I don't think many people run the most current DaVinci kernel.
Most people probably use the Arago project kernels or even older MV-based TI's stuff...

that's nasty :-p All those hacks on a 2.6.18 kernel...

    If not 2.6.10... :-)
Quoted 1 line

Oh well, thanks for noticing and sending a patch :-)

I have noticed that back when testing your patch series, if you remember.
And I really should have fixed it earlier, so that it could get into 2.6.38 (damn my illness that caused a week delay). BTW, you haven't done anything about the broken MUSB modules, have you?

WBR, Sergei

#10 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 12 lines · Sergei Shtylyov

Hello.

Quoted 7 lines · Felipe Balbi
Quoted 5 lines
Quoted 1 line

I wonder how noone has noticed that from -rc1 until now.

I don't think many people run the most current DaVinci kernel.
Most people probably use the Arago project kernels or even older MV-based TI's stuff...

that's nasty :-p All those hacks on a 2.6.18 kernel...

Quoted 8 lines
   If not 2.6.10... :-)
Quoted 1 line

Oh well, thanks for noticing and sending a patch :-)

I have noticed that back when testing your patch series, if you
remember. And I really should have fixed it earlier, so that it could get into 2.6.38 (damn my illness that caused a week delay). BTW, you haven't done anything about the broken MUSB modules, have you?

You mean building musb as module ? Patch is coming:

drivers/Makefile +1 -1
index b423bb1..15df745 100644
@@ -66,7 +66,7 @@ obj-$(CONFIG_TC)              += tc/
 obj-$(CONFIG_UWB)              += uwb/
 obj-$(CONFIG_USB_OTG_UTILS)    += usb/otg/
 obj-$(CONFIG_USB)              += usb/
-obj-$(CONFIG_USB_MUSB_HDRC)    += usb/musb/
+obj-$(CONFIG_USB_MUSB)         += usb/musb/
 obj-$(CONFIG_PCI)              += usb/
 obj-$(CONFIG_USB_GADGET)       += usb/gadget/
 obj-$(CONFIG_SERIO)            += input/serio/
drivers/usb/musb/Kconfig +4 -0
index 4cbb7e4..32136c4 100644
@@ -6,10 +6,14 @@
 comment "Enable Host or Gadget support to see Inventra options"
        depends on !USB && USB_GADGET=n
 
+config USB_MUSB
+       bool
+
 # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
 config USB_MUSB_HDRC
        depends on (USB || USB_GADGET)
        depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523))
+       select USB_MUSB
        select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN)
        select TWL4030_USB if MACH_OMAP_3430SDP
        select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA

compiling and testing a jiffy.

Signature · 1 line
balbi
#11 lore raw

PATCH 1/1 DM644x EVM: register MUSB device earlier

Quoted 57 lines · Felipe Balbi
Quoted 12 lines · Sergei Shtylyov

Hello.

Quoted 7 lines · Felipe Balbi
Quoted 5 lines
Quoted 1 line

I wonder how noone has noticed that from -rc1 until now.

I don't think many people run the most current DaVinci kernel.
Most people probably use the Arago project kernels or even older MV-based TI's stuff...

that's nasty :-p All those hacks on a 2.6.18 kernel...

Quoted 8 lines
   If not 2.6.10... :-)
Quoted 1 line

Oh well, thanks for noticing and sending a patch :-)

I have noticed that back when testing your patch series, if you
remember. And I really should have fixed it earlier, so that it could get into 2.6.38 (damn my illness that caused a week delay). BTW, you haven't done anything about the broken MUSB modules, have you?

You mean building musb as module ? Patch is coming:

drivers/Makefile +1 -1
index b423bb1..15df745 100644
@@ -66,7 +66,7 @@ obj-$(CONFIG_TC)              += tc/
 obj-$(CONFIG_UWB)              += uwb/
 obj-$(CONFIG_USB_OTG_UTILS)    += usb/otg/
 obj-$(CONFIG_USB)              += usb/
-obj-$(CONFIG_USB_MUSB_HDRC)    += usb/musb/
+obj-$(CONFIG_USB_MUSB)         += usb/musb/
 obj-$(CONFIG_PCI)              += usb/
 obj-$(CONFIG_USB_GADGET)       += usb/gadget/
 obj-$(CONFIG_SERIO)            += input/serio/
drivers/usb/musb/Kconfig +4 -0
index 4cbb7e4..32136c4 100644
@@ -6,10 +6,14 @@
 comment "Enable Host or Gadget support to see Inventra options"
        depends on !USB && USB_GADGET=n
 
+config USB_MUSB
+       bool
+
 # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
 config USB_MUSB_HDRC
        depends on (USB || USB_GADGET)
        depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523))
+       select USB_MUSB
        select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN)
        select TWL4030_USB if MACH_OMAP_3430SDP
        select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
Quoted 1 line

compiling and testing a jiffy.

aaaa, had forgotten. The debug part of musb needs rework too. I guess for now it's better to push a patch making musb bool and fix that for 2.6.40. A bigger re-work would be needed, so it's better to keep it working for now.

Signature · 1 line
balbi