David Brownell wrote:
I'm considering addition of another (tryly "idle") phase because the stage after the status phase completion interrupt and before the RxPktRdy interrupt was clearly missed.
In answer to Greg's previous question: looks like this patch is rather clearly *not* 2.6.29 material. ;)
Well, could wait indeed. DaVinci and OMAP are hiding those IRQs from user anyway (but my OMAP-L1x glue doesn't)...
Sergei, adding another phase to the state machine should be no particular issue, but do keep in mind that the musb_g_ep0_state values reflect *protocol* states right now.
The states actually should correspond to the interrupts generated by MUSB (with one exception, ACKWAIT). The problem is that one state was skipped (the corresponding IRQ *usually* gets coalesced with a preceding one in the STATUS/OUT phase).
That is, the model is that the various IRQ-driven transitions should be sorted out, races and all, and then mapped to those states. The Mentor documentation is excessively weak about most of the hardware state transitions (and e.g. their OTG states are a complete mismatch to the OTG specs), so coming up with something that mirrors hardware not protocol states isn't very straightforward.
Contrarywise, it's the only viable solution I think -- since we can't see what happens on USB directly and have to rely on MUSB as a proxy. And anyway, the ACKWAIT state doesn't seem to correspond to anything in the USB protocol -- it looks like artificial addition.
- Dave
WBR, Sergei -- 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
