CPPI TX does not transmit ZLP for TX transfers which - transfer size is multiple of EP packet size, - and URB_ZERO_PACKET is set in urb->transfer_flags. The fix is transmitting the ZLP using PIO mode after the CPPI TX is done. Validated using the following usbtest write case in MUSB host mode. # testusb -t1 -c1 Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
The prefix suggests the number should be printed in hex, so use the %x specifier to do that. Found by using regex suggested by Joe Perches. Signed-off-by: Hans Wennborg <hans@hanshq.net> Signed-off-by: Felipe Balbi <balbi@ti.com>
Felipe writes: usb: patches for v3.17 merge window Surprisingly enough, while a big set of patches, the majority is composed of cleanups (using devm_*, fixing sparse errors, moving code around, adding const, etc). The highlights are addition of new support for PLX USB338x devices, and support for USB 2.0-only configurations of the DWC3 IP core. Signed-of-by: Felipe Balbi <balbi@ti.com>
Add sw_babble_control() logic to differentiate between transient babble and real babble condition. Also add the SW babble control register definitions. Babble control register logic is implemented in the latest revision of AM335x. Find whether we are running on newer silicon. The babble control register reads 0x4 by default in newer silicon as opposed to 0 in old versions of AM335x. Based on this enable the sw babble control logic. Signed-off-by: George Cherian <george.cherian@ti.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Currently musb_platform_reset() is only used by dsps. In case of BABBLE interrupt for other platforms the musb_platform_reset() is a NOP. In such situations no need to re-initialize the endpoints. Also in the latest silicon revision of AM335x, we do have a babble recovery mechanism without resetting the IP block. In preperation to add that support its better to have a rest_done return for musb_platform_reset(). Signed-off-by: George Cherian <george.cherian@ti.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
During babble condition both first disconnect of devices are initiated. Make sure MUSB controller is reset and re-initialized after all disconnects. To acheive this schedule a delayed work for babble recovery. While at that convert udelay to usleep_range. Refer Documentation/timers/timers-howto.txt Signed-off-by: George Cherian <george.cherian@ti.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
BABBLE and RESET share the same interrupt. The interrupt is considered to be RESET if MUSB is in peripheral mode and as a BABBLE if MUSB is in HOST mode. Handle babble condition iff MUSB is in HOST mode. Signed-off-by: George Cherian <george.cherian@ti.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Following the name change of the NOP transceiver driver in commit 4525bee (usb: phy: rename usb_nop_xceiv to usb_phy_generic), the transceiver driver was no longer operable under its old name. Register the transceiver driver before calling usb_get_phy() to make sure we are noticed by an error message if it is not available. Signed-off-by: Apelete Seketeli <apelete@seketeli.net> Signed-off-by: Felipe Balbi <balbi@ti.com>
The musb/cppi41 code installs a hrtimer to work around DMA completion interrupts that have fired too early on AM335x hardware. This timer is currently programmed to first fire 140 microseconds after the DMA completion callback. According to the commit which introduced it (a655f481d83, "usb: musb: musb_cppi41: handle pre-mature TX complete interrupt"), that value is is considered a 'rule of thumb' that worked well with the test case described in the commit log. Test show, however, that for USB audio devices and much smaller packet sizes, the timer has to fire earlier in order to correctly handle the audio stream. The original test case had output transfer sizes of 1514 bytes, and a delay of 140 microseconds. For audio devices with 24 bytes channel size, 3 microseconds seem to work well. Hence, let's assume that the time it takes to clear the bit correlates with the number of bytes transferred. The referenced commit log mentions such a suspicion as well. Let the timer fire in cppi41_channel->total_len/10 microseconds to correctly handle both cases. Also, shorten the interval in which the timer fires again in case of a non-empty early_tx list. With these changes in place, both FS and HS audio devices appear to work well on AM335x hardware. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Sebastian Reimers <sebastian.reimers@googlemail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit 1af54b7a4. The commit tried to address cases in which isochronous transfers are 'not reliable', most probably in the tests conducted, polling for the MUSB_TXCSR_TXPKTRDY bit in MUSB_TXCSR is done too late. Hence, it installs a work struct which basically busy-polls for the bit in a rather agressive way by rescheduling the work if the FIFO is not empty. With USB audio devices, tests have shown that it takes approximately 100 iterations of the asynchronous worker until the FIFO signals completion, which leads to 100% CPU loads when streaming audio. The issue the patch tried to address can be handled differently, which is what the next patch does. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Sebastian Reimers <sebastian.reimers@googlemail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>