On 01/24/2012 08:54 AM, Felipe Balbi wrote:
yes. Lets say 2k of 4k have been transferred. I don't get an interrupt
which says transfer complete. So I am interrupting the transfer "in
progress."
if 2k is all you need to get, of course you will get Transfer Complete.
Host will append a ZLP to finish the transfer.
Only if you terminate with a ZLP. For the sending side, g_zero issues a
write(4k) and the host side has to fetch the data. Now lets say we
fetched 2k and then we crashed and won't fetch any longer.
Fixing this not easy. We are atomic here and I can't sleep. A busy loop
to wait until the command is not simple (but ugly) because other
commands may complete in between. So the only way to fix this behavior
actually, I don't think you need to wait for the interrupt at all. Just
poll CMDAct bit on DEPCMD (like we already do), after that's cleared the
command has completed and all other bitfields you might need are valid.
The real problem, though, is that there's always a request pending on
request_list which doesn't get givenback early enough.
Yep. So why not make the relevant composite part async?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
