Skip to contentSkip to conversation

musb_hdrc, remove MGC_{Read,Write}Csr{8,16}

PATCH In review David Brownell 2 participants 7 messages Jan 18, 2007 – Jan 22, 2007

Subsystems (2)
USB MUSB multipoint high speed dual-role controller
lore
Share & tools
lore

David Brownell

author
#0 lore raw

cover musb_hdrc, remove MGC_{Read,Write}Csr{8,16}

Folowing this are three patches removing those annoying CaMeLcAsE macros cluttering up the sources ... this is the last significant such fix that's needed IMO, although certainly struct members, variables, and function/procedure parameters can be cleaned up.

Given that, issues I know about on the musb_hdrc code in GIT right now, observed on tusb6010 but not tested on DaVinci, include:

- Hmm, host side was not enumerating ... new failure
- DMA wierdness of various types
- Various issues with suspend states and remote wakeup

That list is just so anyone running into them needn't be too surprised.

- Dave

#1 lore raw
Quoted 9 lines · David Brownell

Folowing this are three patches removing those annoying CaMeLcAsE macros cluttering up the sources ... this is the last significant such fix that's needed IMO, although certainly struct members, variables, and function/procedure parameters can be cleaned up.

Given that, issues I know about on the musb_hdrc code in GIT right now, observed on tusb6010 but not tested on DaVinci, include:

- Hmm, host side was not enumerating ... new failure

I've noticed that too, I'm getting this after plugging in a powered hub and a mouse in OTG mode:

tusb_interrupt 525: TUSB IRQ 0000a000
tusb_interrupt 556: wake active 06
tusb_otg_ints 435: vbus change, b_idle, otg 171
tusb_interrupt 525: TUSB IRQ 00004000
tusb_otg_ints 404: Default-A
tusb_set_vbus 384: VBUS a_wait_vrise, devctl 99 otg 171 conf c0010000 prcm 00a800 tusb_interrupt 525: TUSB IRQ 00010000
tusb_otg_ints 467: a_wait_vrise timer, 171
tusb_interrupt 525: TUSB IRQ 00000010
musb_interrupt 1351: ** IRQ host usb0010 tx0000 rx0000 musb_stage0_irq 310: <== Power=e0, DevCtl=5d, bIntrUSB=0x10 musb_stage0_irq 515: CONNECT (a_host) devctl 5d

Are you getting same results on h4?

Quoted 5 lines

- DMA wierdness of various types
- Various issues with suspend states and remote wakeup

That list is just so anyone running into them needn't be too surprised.

Pushed all.

Tony

author
#2 lore raw
Quoted 20 lines · Tony Lindgren
Quoted 1 line · David Brownell

- Hmm, host side was not enumerating ... new failure

I've noticed that too, I'm getting this after plugging in a powered hub and a mouse in OTG mode:

tusb_interrupt 525: TUSB IRQ 0000a000
tusb_interrupt 556: wake active 06
tusb_otg_ints 435: vbus change, b_idle, otg 171
tusb_interrupt 525: TUSB IRQ 00004000
tusb_otg_ints 404: Default-A
tusb_set_vbus 384: VBUS a_wait_vrise, devctl 99 otg 171 conf c0010000 prcm 00a800 tusb_interrupt 525: TUSB IRQ 00010000
tusb_otg_ints 467: a_wait_vrise timer, 171
tusb_interrupt 525: TUSB IRQ 00000010
musb_interrupt 1351: ** IRQ host usb0010 tx0000 rx0000 musb_stage0_irq 310: <== Power=e0, DevCtl=5d, bIntrUSB=0x10 musb_stage0_irq 515: CONNECT (a_host) devctl 5d

Quoted 1 line

Are you getting same results on h4?

Modulo me using a different debug level, yes.

author
#3 lore raw
Quoted 10 lines · David Brownell
Quoted 7 lines · Tony Lindgren
Quoted 1 line · David Brownell

- Hmm, host side was not enumerating ... new failure

I've noticed that too, ...

Are you getting same results on h4?

Modulo me using a different debug level, yes.

I looked a bit at this, it looks like a usbcore change broke things. The musb_hdrc driver tells usbcore to probe that root hub, but usbcore does nothing ... seemingly it now expects to be told to wake up the root hub first, which makes no sense for this particular hardware.

- Dave

#4 lore raw
Quoted 10 lines · David Brownell
Quoted 9 lines · David Brownell
Quoted 7 lines · Tony Lindgren
Quoted 1 line · David Brownell

- Hmm, host side was not enumerating ... new failure

I've noticed that too, ...

Are you getting same results on h4?

Quoted 7 lines
Quoted 1 line

Modulo me using a different debug level, yes.

I looked a bit at this, it looks like a usbcore change broke things. The musb_hdrc driver tells usbcore to probe that root hub, but usbcore does nothing ... seemingly it now expects to be told to wake up the root hub first, which makes no sense for this particular hardware.

OK, BTW looks like I'm not getting any VBUS on N800. If I ground ID pin and feed back VBUS from hub to N800, then it enumerates. (This is with maemo.org 2.6.18 tree)

Regards,

Tony

author
#5 lore raw
Quoted 3 lines · Tony Lindgren

OK, BTW looks like I'm not getting any VBUS on N800. If I ground ID pin and feed back VBUS from hub to N800, then it enumerates. (This is with maemo.org 2.6.18 tree)

Hmm, maybe they didn't populate the caps for the chargepump? If you ground it, VBUS should come automagically.

Here's a patch that addresses one issue I know about. But another couple issues joined recently ... not quit sure what's up with those yet.

- Dave

==============
Recent usbcore "autosuspend" changes redefined the interface for root hubs in an incompatible way. This patch makes CONNECT irqs work again.

Signed-off-by David Brownell <[email protected]>
drivers/usb/musb/plat_uds.c +7 -2
@@ -472,9 +472,11 @@ static irqreturn_t musb_stage0_irq(struc
 	}
 
 	if (bIntrUSB & MGC_M_INTR_CONNECT) {
+		struct usb_hcd *hcd = musb_to_hcd(pThis);
+
 		handled = IRQ_HANDLED;
 		pThis->is_active = 1;
-		set_bit(HCD_FLAG_SAW_IRQ, &musb_to_hcd(pThis)->flags);
+		set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
 
 		pThis->bEnd0Stage = MGC_END0_START;
 

@@ -496,7 +498,10 @@ static irqreturn_t musb_stage0_irq(struc
 		if (devctl & MGC_M_DEVCTL_LSDEV)
 			pThis->port1_status |= USB_PORT_STAT_LOW_SPEED;
 
-		usb_hcd_poll_rh_status(musb_to_hcd(pThis));
+		if (hcd->status_urb)
+			usb_hcd_poll_rh_status(hcd);
+		else
+			usb_hcd_resume_root_hub(hcd);
 
 		MUSB_HST_MODE(pThis);
#6 lore raw
Quoted 8 lines · David Brownell
Quoted 3 lines · Tony Lindgren

OK, BTW looks like I'm not getting any VBUS on N800. If I ground ID pin and feed back VBUS from hub to N800, then it enumerates. (This is with maemo.org 2.6.18 tree)

Hmm, maybe they didn't populate the caps for the chargepump? If you ground it, VBUS should come automagically.

Well it seems to work if I force VBUS on once before connecting the host cable.

Otherwise VBUS does not seem to reach 5V but is somewhere below 5V, and then "vbus too slow" kills it off.

Plugging the cable in 2 - 3 times fast makes it work too, then VBUS seems to reach 5V.

Quoted 3 lines

Here's a patch that addresses one issue I know about. But another couple issues joined recently ... not quit sure what's up with those yet.

Pushed it.

Tony