kernel.git/drivers/usb/musb, branch linux-2.6.30.y

USB: musb: fix build when !CONFIG_PM

2009-04-23T21:15:27Z

Fix this build error when CONFIG_PM is not set: drivers/usb/musb/musb_core.c:2232: error: 'musb_resume_early' undeclared here Signed-off-by: Alexander Beregalov Signed-off-by: Greg Kroah-Hartman

USB: musb: Remove my email address from few musb related drivers

2009-04-23T21:15:27Z

This email address is going to expire soon and my contribution to musb is next to zero so remove it. Signed-off-by: Jarkko Nikula Cc: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

USB: musb: fix possible panic while resuming

2009-04-17T17:50:26Z

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 Signed-off-by: Greg Kroah-Hartman

USB: musb: fix isochronous TXDMA (take 2)

2009-04-17T17:50:26Z

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.) [ dbrownell@users.sourceforge.net: 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 Signed-off-by: Greg Kroah-Hartman

USB: musb: sanitize clearing TXCSR DMA bits (take 2)

2009-04-17T17:50:25Z

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. [dbrownell@users.sourceforge.net: don't introduce CamelCase, shrink diff] Signed-off-by: Sergei Shtylyov Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman

USB: musb: bugfixes for multi-packet TXDMA support

2009-04-17T17:50:25Z

We really want to use DMA mode 1 for all multi-packet transfers; that's one IRQ on DMA completion, instead of one per packet. There is an important issue with such transfers, especially on the host side: when such transfers end with a full-size packet, we must defer musb_dma_completion() calls until the FIFO empties. Else we report URB completions too soon, and may clobber data in the FIFO fifo when writing the next packet (losing data). The Inventra DMA support uses DMA mode 1, but it ignores that issue. The CPPI DMA support uses mode 0, but doesn't handle its TXPKTRDY interrupts quite right either; it can get stale "packet ready" interrupts, and report transfer completion too early using slightly different code paths, also losing data. So I'm solving it in a generic way -- by adding a sort of the "interrupt filter" into musb_host_tx(), catching these cases where a DMA completion IRQ doesn't suffice and removing some needlessly controller-specific logic. When a TXDMA interrupt happens and DMA request mode 1 is active, that filter resets to mode 0 and defers URB completion processing until TXPKTRDY, unless the FIFO is already empty. Related filtering logic in Inventra and CPPI code gets removed. Since it should be competely safe now to use the DMA request mode 1 for host side transfers with the CPPI DMA controller, set it in musb_h_tx_dma_start() ... now renamed (and shared). [ dbrownell@users.sourceforge.net: don't introduce more CamElCase; use more concise explanations ] Signed-off-by: Sergei Shtylyov Cc: Felipe Balbi Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman

USB: musb_host, fix ep0 fifo flushing

2009-04-17T17:50:25Z

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 Signed-off-by: Greg Kroah-Hartman

USB: musb_host, minor enqueue locking fix (v2)

2009-04-17T17:50:25Z

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 Signed-off-by: Greg Kroah-Hartman

USB: musb: partial DaVinci dm355 support

2009-03-24T23:20:36Z

Partial support for DaVinci DM355, on the EVM board; peripheral mode should work, once mainline merges DM355 support. Missing: (a) renumbering the GPIO for DRVVBUS on the DM6446 EVM, when DAVINCI_N_GPIO increases; (b) disabling DM355_DEEPSLEEP.DRVVBUS_OVERRIDE so VBUS is driven according to the ID signal, if cpu_is_..._dm355() The new PHY control bits are ignored on DM6446. Signed-off-by: David Brownell Cc: Kevin Hilman Signed-off-by: Greg Kroah-Hartman

USB: musb: only turn off vbus in OTG hosts

2009-03-24T23:20:36Z

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. [ dbrownell@users.sourceforge.net: tweak patch description ] Signed-off-by: Ajay Kumar Gupta Signed-off-by: David Brownell Signed-off-by: Greg Kroah-Hartman