Hey, I've done a bit more digging at the problem seems to be that for some reason the TXPKTRDY bit in the HOST_CSR register never get's cleared by the MUSB controller.
This is causing cppi41_dma_callback() to schedule work due to musb_is_tx_fifo_empty() stating there is still data in the outgoing FIFO. Consequently the callback schedules cppi_trans_done_work() which also uses musb_is_tx_fifo_empty() which then reschedules itself if there is still data. Thus the cppi41_trans_done() -> musb_interrupt() -> musb_host_tx() are never called so the USB controller never gets released. You can see this through the dmesg. Working: [ 11.042601] cp210x ttyUSB0: usb_serial_generic_write_start - length = 132, data = 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 54 45 53 54 49 4e 47 20 54 45 53 54 49 4e 47 24 [ 11.042636] musb-hdrc musb-hdrc.0.auto: ... next ep10 TX urb cc9cef00 [ 11.042658] musb-hdrc musb-hdrc.0.auto: qh ce3d6900 urb cc9cef00 dev2 ep1out-bulk, hw_ep 10, ce394b00/176 [ 11.042679] musb-hdrc musb-hdrc.0.auto: --> hw10 urb cc9cef00 spd2 dev2 ep1out h_addr00 h_port00 bytes 176 [ 11.042701] musb-hdrc musb-hdrc.0.auto: configure ep10/a4 packet_sz=256, mode=0, dma_addr=0x8e394b00, len=176 is_tx=1 [ 11.042718] musb-hdrc musb-hdrc.0.auto: Start TX10 dma [ 11.042808] musb-hdrc musb-hdrc.0.auto: DMA transfer done on hw_ep=10 bytes=176/176 [ 11.043165] musb-hdrc musb-hdrc.0.auto: OUT/TX10 end, csr 3500, dma [ 11.043210] musb-hdrc musb-hdrc.0.auto: complete cc9cef00 usb_serial_generic_write_bulk_callback+0x0/0xd4 [usbserial] (0), dev2 ep1out, 176/176 Failing: [ 11.043239] cp210x ttyUSB0: usb_serial_generic_write_start - length = 256, data = 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 54 45 53 54 49 4e 47 20 54 45 53 54 49 4e 47 24 [ 11.043279] musb-hdrc musb-hdrc.0.auto: ... next ep10 TX urb cc9ced00 [ 11.043301] musb-hdrc musb-hdrc.0.auto: qh ce3d6900 urb cc9ced00 dev2 ep1out-bulk, hw_ep 10, ce394a00/132 [ 11.043322] musb-hdrc musb-hdrc.0.auto: --> hw10 urb cc9ced00 spd2 dev2 ep1out h_addr00 h_port00 bytes 132 [ 11.043344] musb-hdrc musb-hdrc.0.auto: configure ep10/a4 packet_sz=256, mode=0, dma_addr=0x8e394a00, len=132 is_tx=1 [ 11.043361] musb-hdrc musb-hdrc.0.auto: Start TX10 dma [ 11.043389] musb-hdrc musb-hdrc.0.auto: DMA transfer done on hw_ep=10 bytes=132/132 FYI I've been using http://www.ti.com/lit/ug/sprufy9/sprufy9.pdf for the register descriptions as they're all missing from the am335x docs (as suggested here: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/211653.aspx) Is this a known problem? Chris On Monday, 17 February 2014 16:44:59 UTC+13, Chris Kimber wrote: > > Hey All, > > I've just tried to move my BeagleBone from the TI provided BSP (Argo Linux > 3.2 Release 04.06.00.11) to one of the newer community kernels from > https://github.com/beagleboard/kernel. > > I'm not using any distro, just a busybox based rootfs. > > My motivations for moving to the later kernels are to gain Device Tree and > a bunch of other drivers for some I2C devices as well as the TPS PMIC > backlight (ultimately this will be used on a Beaglebone based custom > design). I figured it would be easier to move forward that to reverse > engineer these drivers into the old 3.2 kernel. > > Everything seems to work, except for one of the USB use cases I'm > interested in. I'm able to mount a USB stick and copy a couple of gigs of > data between the two without any issues. However, when I try to communicate > with a CP2102 USB UART I very quickly seem to hang the driver. This worked > fine in the old 3.2 kernel. > > It seems to send a bunch of data (but It doesn't seem to arrive on the > other end of the UART) and then the TX buffer fills and causes my sending > test app (https://gist.github.com/anonymous/55ab3051827aeb698f95) to > hang. When I pull the USB cable, I get a kernel panic somewhere in the DMA > driver waiting to clear the FIFO. I've tried this on 3.8, 3.12 and 3.13 all > with similar results (3.13 panic = > https://gist.github.com/anonymous/12ef2a1223f7a953f293) > > I'm using the stock am335x-bone.dts for each of the kernels. > > I've also removed the USB support from u-boot (2014.01) to make sure no > contamination got through. > > I've also tried to disabling the USB DMA support in the kernel .config. > > I've found that I get the exact same symptoms if I use a different USB > UART ftdio_sio, so I think the problem is somewhere under the hood within > the musb core/platform bindings. > > I figured I’d see if anyone else has run into any problems like this, and > was wondering if someone could answer a couple of questions I have: > > * What is the recommended kernel to be using now? Should I stick to 3.13? > > * How much verification/what verification has been done on the USB Host to > define it as working as is declared in README.md > > Cheers for any help > > Chris > > > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
