Smattering of musb patches for 2.6.29-omap-pm

I pulled a bunch of patches related to MUSB from the linux-usb mailing
list. I applied them to omap/pm 2.6.29 and MUSB gadget works most of the
time. I've had a panic at boot, and I haven't been able to get host
working, but the patches are a lot easier to work with once they are in
git rather than scattered on a mailing list so I thought they might be
of use to someone.

Except on DaVinci, VBUS is now switched off as part of idling the
USB link (after a_wait_bcon) whenever a device is disconnected
from host. This is correct for OTG hosts, where either SRP or
an ID interrupt could turn VBUS on again.

However, for non-OTG hosts there's no way to turn VBUS on again,
so the host becomes unusable. And the procfs entry which once
allowed a manual workaround for this is now gone.

This patch adds an is_otg_enabled() check before scheduling the
switch-off timer in disconnect path, supporting a "classic host"
mode where SRP is unavailable.

[ tweak patch description ]

Signed-off-by: Ajay Kumar Gupta <>
Signed-off-by: David Brownell <>
Signed-off-by: Greg Kroah-Hartman <>

Avoid the following INFO from lock debugging:

[ 369.126112] =================================
[ 369.132063] [ INFO: inconsistent lock state ]
[ 369.136457] 2.6.28-maemo1 #1
[ 369.139387] ---------------------------------
[ 369.143782] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[ 369.149855] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 369.154890] (&cdev->lock){+-..}, at: [<bf1979f0>] composite_disconnect+0x1c/0]
[ 369.163404] {hardirq-on-W} state was registered at:
[ 369.168348] [<c00788a8>] __lock_acquire+0x5d0/0x7d8
[ 369.173506] [<c0078b14>] lock_acquire+0x64/0x78
[ 369.178266] [<c0263a34>] _spin_lock+0x4c/0x80
[ 369.182905] [<bf19597c>] usb_function_deactivate+0x20/0x70 [g_nokia]
[ 369.189527] [<bf1a0a88>] 0xbf1a0a88
[ 369.193281] [<bf19f450>] 0xbf19f450
[ 369.197004] [<bf19fa3c>] 0xbf19fa3c
[ 369.200758] [<bf1a03a0>] 0xbf1a03a0
[ 369.204481] [<bf19f254>] 0xbf19f254
[ 369.208204] [<bf1a0158>] 0xbf1a0158
[ 369.211927] [<bf1a130c>] 0xbf1a130c
[ 369.215650] [<c01c21f0>] usb_gadget_register_driver+0x12c/0x28c
[ 369.221846] [<bf1a06bc>] 0xbf1a06bc
[ 369.225569] [<bf1a06e8>] 0xbf1a06e8
[ 369.229322] [<c002c2dc>] __exception_text_end+0x64/0x19c
[ 369.234877] [<c0081628>] sys_init_module+0x9c/0x194
[ 369.240004] [<c002c8e0>] ret_fast_syscall+0x0/0x2c
[ 369.245039] [<ffffffff>] 0xffffffff
[ 369.248793] irq event stamp: 218356
[ 369.252302] hardirqs last enabled at (218355): [<c003a77c>] omap3_enter_idle+8
[ 369.260420] hardirqs last disabled at (218356): [<c0264774>] __irq_svc+0x34/0x0
[ 369.267927] softirqs last enabled at (218348): [<c00585a4>] __do_softirq+0x134
[ 369.275892] softirqs last disabled at (218335): [<c005899c>] irq_exit+0x60/0xb0
[ 369.283308]
[ 369.283308] other info that might help us debug this:
[ 369.289930] no locks held by swapper/0.

Signed-off-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>

Fixes endpoint starvation issue when more than one bulk QH is
multiplexed on the reserved bulk RX endpoint, which is normal
for cases like serial and ethernet adapters.

This patch sets the NAK timeout interval for such QHs, and when
a timeout triggers the next QH will be scheduled. (This resembles
the bulk scheduling done in hardware by EHCI, OHCI, and UHCI.)

This scheme doesn't work for devices which are connected to a
high to full speed tree (transaction translator) as there is
no NAK timeout interrupt from the musb controller from such

Tested with PIO, Inventra DMA, CPPI DMA.

[ fold in start_urb() update;
  clarify only for bulk RX; don't accidentally clear WZC bits ]

Signed-off-by: Ajay Kumar Gupta <>
Signed-off-by: David Brownell <>
Signed-off-by: Greg Kroah-Hartman <>

The current MUSB host code doesn't make use of all the available
FIFOs in for periodic transfers since it wrongly assumes the RX
and TX sides of any given hw_ep always share one FIFO.

Change: use 'in_qh' and 'out_qh' fields of the 'struct musb_hw_ep'
to check the endpoint's business; get rid of the now-unused 'periodic'
array in the 'struct musb'. Also optimize a loop induction variable
in the endpoint lookup code.

(Based on a previous patch from Ajay Kumar Gupta <>)

[ clarify description and origin
  of this fix; whitespace ]

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>
Signed-off-by: Greg Kroah-Hartman <>

This patch disables USB regulators VUSB1V5, VUSB1V8, and VUSB3V1
when the USB cable is unplugged to reduce power consumption.
Added a depencency from twl4030 usb driver to TWL_REGULATOR.

Signed-off-by: Jouni Hogander <>
Signed-off-by: Kalle Jokiniemi <>
Signed-off-by: Greg Kroah-Hartman <>

Address one open question in the composite gadget framework:
Yes, we should have device-level suspend/resume callbacks
in addition to the function-level ones. We have at least one
scenario (with gadget zero in OTG test mode) that's awkward
to handle without it.

Signed-off-by: David Brownell <>
Signed-off-by: Greg Kroah-Hartman <>

The g_ether USB gadget driver currently decides whether or not there's a
link to report back for eth_get_link based on if the USB link speed is
set. The USB gadget speed is however often set even before the device is
enumerated. It seems more sensible to only report a "link" if we're
actually connected to a host that wants to talk to us. The patch below
does this for me - tested with the PXA27x UDC driver.

Signed-Off-By: Jonathan McDowell <>
Signed-off-by: David Brownell <>

Someone noted that the enqueue path used an unlocked access
for usb_host_endpoint->hcpriv ... fix that, by being safe
and always accessing it under spinlock protection.

Signed-off-by: David Brownell <>

The MUSB host side can't share generic TX FIFO flush logic
with EP0; the EP0 TX status register bits are different
from those for other entpoints.

Resolve this issue by providing a new EP0-specific routine
to flush and reset the FIFO, which pays careful attention to
restrictions listed in the latest programmer's guide. This
gets rid of an open issue whereby the usbtest control write
test (#14) failed.

Signed-off-by: David Brownell <>

The MUSB code clears TXCSR_DMAMODE incorrectly in several
places, either asserting that TXCSR_DMAENAB is clear (when
sometimes it isn't) or clearing both bits together. Recent
versions of the programmer's guide require DMAENAB to be
cleared first, although some older ones didn't.

Fix this and while at it:

- In musb_gadget::txstate(), stop clearing the AUTOSET
   and DMAMODE bits for the CPPI case since they never
   get set anyway (the former bit is reserved on DaVinci);
   but do clear the DMAENAB bit on the DMA error path.

- In musb_host::musb_ep_program(), remove the duplicate
   DMA controller specific code code clearing the TXCSR
   previous state, add the code to clear TXCSR DMA bits
   on the Inventra DMA error path, to replace such code
   (executed late) on the PIO path.

- In musbhsdma::dma_channel_abort()/dma_controller_irq(),
   add/use the 'offset' variable to avoid MUSB_EP_OFFSET()
   invocations on every RXCSR/TXCSR access.

[ don't introduce CamelCase,
shrink diff]

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

Multi-frame isochronous TX URBs transfers in DMA mode never
complete with CPPI DMA because musb_host_tx() doesn't restart
DMA on the second frame, only emitting a debug message.
With Inventra DMA they complete, but in PIO mode. To fix:

- Factor out programming of the DMA transfer from
   musb_ep_program() into musb_tx_dma_program();

- Reorder the code at the end of musb_host_tx() to
   facilitate the fallback to PIO iff DMA fails;

- Handle the buffer offset consistently for both
   PIO and DMA modes;

- Add an argument to musb_ep_program() for the same
   reason (it only worked correctly with non-zero
   offset of the first frame in PIO mode);

- Set the completed isochronous frame descriptor's
   'actual_length' and 'status' fields correctly in
   DMA mode.

Also, since CPPI reportedly doesn't like sending isochronous
packets in the RNDIS mode, change the criterion for this
mode to be used only for multi-packet transfers. (There's
no need for that mode in the single-packet case anyway.)

[ split comment paragraph
into bullet list, shrink patch delta, style tweaks ]

Signed-off-by: Pavel Kiryukhin <>
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

During driver resume processing, musb could cause a kernel panic.
Fix by enabling the clock earlier, with the resume_early method.

Signed-off-by: Kim Kyuwon <>
Signed-off-by: David Brownell <>

Refactor musb_save_toggle() as follows:

- replace 'struct musb_hw_ep *ep' parameter by 'struct
   musb_qh *qh' to avoid re-calculating this value

- move usb_settogle() call out of the *if* operator.

This is a net minor shrink of source and object code.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

Suppress "parasitic" endpoint interrupts in the DMA mode
when using CPPI DMA driver; they're caused by the MUSB gadget
driver using the DMA request mode 0 instead of the mode 1.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

The gadget EP0 code routinely ignores an interrupt at end of
the data phase because of musb_g_ep0_giveback() resetting the
state machine to "idle, waiting for SETUP" phase prematurely.

The driver also prematurely leaves the status phase on
receiving the SetupEnd interrupt.

As there were still unhandled endpoint 0 interrupts happening
from time to time after fixing these issues, there turned to
be yet another culprit: two distinct gadget states collapsed
into one.

The (missing) state that comes after STATUS IN/OUT states was
typically indiscernible from them since the corresponding
interrupts tend to happen within too little period of time
(due to only a zero-length status packet in between) and so
they got coalesced; yet this state is not the same as the next
one which is associated with the reception of a SETUP packet.

Adding this extra state seems to have fixed the rest of the
unhandled interrupts that generic_interrupt() and
davinci_interrupt() hid by faking their result and only
emitting a debug message -- so, stop doing that.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

Factor out the often used code to get/set the active 'qh'
pointer for the hardware endpoint. Change the way the case
of a shared FIFO is handled by setting *both* 'in_qh' and
'out_qh' fields of 'struct musb_hw_ep'. That seems more
consistent and makes getting to the current 'qh' easy when
the code knows the direction beforehand.

While at it, turn some assignments into intializers and
fix declaration style in the vicinity.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

As musb_advance_schedule() is now the only remaning
caller of musb_giveback() (and the only valid context
of such call), just fold the latter into the former
and then rename __musb_giveback() into musb_giveback().

This is a net minor shrink.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

As DaVinci DM646x has a dedicated CPPI DMA interrupt, replace
cppi_completion() (which has always been kind of layering
violation) by a complete CPPI interrupt handler.

[ only cppi_dma.c needs platform
device header, not cppi_dma.h ]

Signed-off-by: Dmitry Krivoschekov <>
Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>

The existance of the scheduling list shouldn't matter in
determining whether there's currectly an URB executing on a
hardware endpoint. What should actually matter is the 'in_qh'
or 'out_qh' fields of the 'struct musb_hw_ep' -- those are
set in musb_start_urb() and cleared in musb_giveback() when
the endpoint's URB list drains. Hence we should be able to
replace the big *switch* statements in musb_urb_dequeue()
and musb_h_disable() with mere musb_ep_get_qh() calls...

While at it, do some more changes:

- add 'is_in' variable to musb_urb_dequeue();

- remove the unnecessary 'epnum' variable from musb_h_disable();

- fix the comment style in the vicinity.

This is a minor shrink of source and object code.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Brownell <>