Arvid Brodin wrote:
The transfer *might* be active. There's no way to tell, as far as I can see.
So even if we don't mask the interrupt using the skip map, we might not get
an interrupt (in fact this seemed to be the usual case when I looked into
this before). And if we don't get the interrupt, we never release the slot,
which is of course bad in the long run. :)
So waiting for an interrupt is bad because it may not come and we run out
of ptds. Not waiting is bad because we may reuse the slot and have it
reported as done while we haven't done anything.
So it is playing with fire either way. I hate that chip.
To avoid the problem of re-using the slot too early, I have done this (in
patch #2 in this series):
When unlinking:
1) Set skip bit
When queueing new transfer at some later time:
2) Write new ptd
3) Read done_map, mask out the bit for this slot. (The done maps
are now stored in struct isp1760_hcd to allow this, since they
cannot be written back to the isp1760.)
4) Clear skip map bit.
This should avoid errouneous interrupts for unlinked ptds, unless we can
get "done interrupts" for ptds even after writing new data to the slot (not
impossible I guess, if the hardware starts the transfer and we are then very
quick to reuse the slot).
I would like to have some kind of way to communicate with the hardware to
make sure the hardware considers a ptd inactive, but I haven't found any. I.e.
clear DW0_VALID_BIT and wait for DW3_ACTIVE_BIT to become unset or something
like that. But the hardware seems to totally ignore changes to both the
ACTIVE and the VALID bit after it has started processing the slot. :(
Yeah. I don't remember anything being mentioned how to interrupt / cancel
a transfer. Okay. So lets do it your way.
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
