On Thursday 23 July 2009, Alan Stern wrote: > On Wed, 22 Jul 2009, David Brownell wrote: > > > > While a QH might need all sort of complicated manipulations, right > > > now I'm concerned only about linking and unlinking. > > > > Exactly. You can't escape those cases for any "live" QH. > > Those "complicated manipulations" have to be the standard > > case, or you will corrupt other data transfers. > > Do you have any particular examples of these manipulations in mind? > qh_update() perhaps? I agree, it's important to be careful not to > relink a QH while an URB is being given back. But is there anything > else? The silicon quirk that qh_refresh() mentions, for one. It shows up in a few code paths. I vaguely recall thinking that could be factored into two separate issues, but that it was simpler to view (and treat) it as just one. > > > If the QH is currently idle then ehci_urb_dequeue() doesn't need to > > > call unlink_async() in the first place; it only needs to force a rescan > > > (your (b) case below). > > > > No; if it's currently idle it's also currently empty, so > > nothing would need to be done. (This should never happen, > > since there'd be no URBs to unlink...) > > Well, that's the thing. As of recently it _is_ possible for an IDLE QH > to have URBs pending. This can happen if the QH is forced to be IDLE > because it is waiting for a Clear-TT-Buffer to finish. I'd be tempted to update the state machine to include a new QH_WAIT_TT_CLEAR state then ... transitions presumably from QH_LINKED (via HALT/error) to that. As soon as the clear completes, the HALT bit in the QH can be toggled and it could go back to QH_LINKED. I can't see any reason to require such QH ops to go through the unlink process; they're supposed to be very quick, yes? That'd preserve the invariant that QH_IDLE implies TD-list-is-empty. > > > If the QH _is_ currently linked then ehci_urb_dequeue() needs to unlink > > > it -- forcing a rescan isn't enough (your (a) case). For this it does > > > need to call unlink_async(), which does need to initiate the unlink. > > > > Except for the (b) subcase dealing with a halted QH that's > > still linked ... > > Ah, good point. And potentially a new QH_WAIT_TT_CLEAR state, also a flavor of (b) ... - Dave > > > Just have unlink_async() set a flag. Maybe have qh_completions() > > handle the (b) case if stopped; for sure, have scan_async() do the > > honors for (a). Clear the flag after handling it. > > Right. > > Alan Stern > > -- 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
