Hello, I wrote:
This part is being done at musb_host_rx()
You're doing it in musb_host_tx() actually. Although musb_host_rx()
is also broken WRT the isochronous transfers.
doing next packet programming within same urb and *not* starting next
urb. Thus musb_start_urb() doesn't come into this path.
What? Read the code, please -- musb_start_urb() call should always
precede musb_host_tx() which handles the DMA interrupt. Unless
something
clears DMAReqEnab after musb_start_urb() call, setting it only once
should work.
musb_start_urb() call does precede musb_host_tx() but when urb is
*completed*.
I think you are aware that there are multiple packets within same
isochronous urb and musb_start_urb() programs only for first packet.
============================================================
case USB_ENDPOINT_XFER_ISOC:
qh->iso_idx = 0;
qh->frame = 0;
offset = urb->iso_frame_desc[0].offset;
len = urb->iso_frame_desc[0].length;
============================================================
Sure. What I'm still not aware of is where and how the TXCSR DMA bits
are cleared after the first fragment. Hopefully, testing will reveal
this...
I really should have stared at the code a bit more myself. Now that I
have the sad truth has dawned on me... :-/
My patch "USB: musb: bugfixes for multi-packet TXDMA support" (commit
c7bbc056a92476b3b3d70a8df7cc746ac5d56de7) inevitably causes the DMA bits to
be cleared because we're using DMA mode 1 regardless of whether this is
isochronous transfer or no. (We could really use mode 0 for isochronous
transfer and save the hassle when filtering out DMA completion interrupt in
musb_host_tx().)
So, I now have to ACK your patch (which could use a better description
though) and strew my head with ashes. All this also must mean that I have
managed to break ISO Tx DMA in the internal tree, where I added the
abovementioned patch after the one that fixed it (the order of the patches
in the community tree is reverse). I probably did not retest USB audio back
then...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
