On Tue, 24 Jan 2012, Nikolai Zhubr wrote:
> 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.
Does this mean that the hardware has only one FIFO? Or only one for
each direction? That's a pretty limited design.
> 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?
Both of these approaches are fundamentally broken. You don't know in
advance what endpoint the host will try to communicate with, and if you
wait until an IN token is received then it's probably already too late
to put the data in the FIFO.
It's even possible that the host will want to receive one packet from
one endpoint (presumably the FIFO can hold more than one packet's
worth?) followed by one packet from another endpoint. Judging by your
description, it is impossible for the device to fulfill such requests.
You will simply have to live with mismatches. There's nothing wrong
them, so long as the device responds to a mismatch with NAK.
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
