Hello people,
I'd like to hear some advice before I waste yet more time on this.
Because my knowledge of USB concepts is close to nonexistent, I'll just
present the situation as I see it currently with just all details I have.
As I understand it, the problem with this thing in device mode is that
it is unable to automatically reorder IN data for different EPs
submitted to it by the driver to match the sequence of EPs in IN tokens
coming from host side. (A mismatch will be detected, however, and
reported to the driver through an irq) So as long as the hardware can
not provide necessary ordering by itself, this obviously has to be done
in software (in the driver). Otherwise, the device might ocasionally
still work in cases of very few IN EPs used and some very predictable IN
patterns (for which g_file_storage is apparently an example) but will
fail sooner or later.
Ok. The unpatched original dwc driver just does not care at all. The
workaround code (supposedly created by Amlogic) does care but the
reordering it applies is not based on any actual IN tokens. (To be
short, its does some hard-coded preventive reordering, probably based on
some experiments) So essentially, it just masqerades the problem a
little bit rather than removes it (Well, at least now I know why
android's adb via usb is so unstable on this device) So I suppose such
workaround isn't really worth applying.
In order to guarantee proper ordering in software (in case there are 2
or more IN EPs), the driver will need to:
1. not start submitting new IN data to Tx FIFO until a respective IN
token is received;
2. either be notified of every new IN token separately, or have an
opportunity to examine EP numbers of actual IN tokens received in a batch.
From my recent attempts I know that 1 is possible and simple, though
delaying start of transfer would probably result in less-than-optimal
overall speed in simple scenarios, but that it ok.
Now 2 is harder. While there are individual intktxfemp bits ("IN Token
while Tx Fifo Empty") for all EPs, under heavy CPU load (or just
occasionally) they might collide in a single irq and therefore will not
be sufficient to build the required sequence unambiguously. Fetching
informations on actual IN tokens from the controller is mentioned in
header files and implemented in some function in the driver but it does
not work on my device (all zeroes all the time, maybe the feature was
dropped to simplify the silicon or header file is imprecise, no idea) So
basically in this case of collided intktxfemp bits the only possibility
is do a random guess (e.g. try the first one), then if "EP mismatch"
interrupt occures, blacklist this EP temporarily and try another. Repeat
as necessary. Very ugly.
So question is, does it even make sense? Is it worth trying or am I too
wrong somethere?
Thank you.
Nikolai
22.01.2012 15:12, I wrote:
Hello,
22.01.2012 1:40, I wrote:
[...]
if matters). Without that, controller starts raising "IN Token Received
with EP mismatch" instead of normal "Transfer complete" bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this "EP mismatch" event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not
Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever
it was) addressing exactly this problem. It does not work well because
it is buggy, however the idea is simple enough: do not push data to Tx
FIFO if it still holds some previous unsent data for another EP. I think
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at
least the damned thing stops throwing "EP mismatch", I've checked)
--
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
