Thanks Dan, that's very helpful.
I haven't seen anything in the drivers/usb/gadget directory which
looks like an au1100 driver, so if you could send me any code you
have, I'd be grateful :-)
From: Dan Malek [mailto:firstname.lastname@example.org]
Sent: 21 October 2005 16:36
To: Hamilton, Ian
Cc: 'email@example.com' MIPS
Subject: Re: au1x00 usb device status
On Oct 21, 2005, at 9:17 AM, Hamilton, Ian wrote:
> Is there a full description of the timing problem somewhere on the
> In particular, how quickly does the interrupt need to be serviced?
There are two major challenges (and many minor ones).
The major challenges are timing related. First, the USB status
is not cumulative, if you can't service the interrupt within the
latency of the next status change, you lose. The second challenge
is the management of the data flow. You need to turn around
DMA buffers very quickly, as the FIFO is small. If you happen
to DMA a power of 2 size that matches what you just told the FIFOs,
you then have to also do a zero length DMA to properly terminate
the transfer on the USB. To reduce the latency of DMA processing,
I was considering not using the general DMA functions, but
rather implementing custom versions of the DMA functions in
the USB driver. This will reduce the latency window, but not
eliminate it. Oh yeah, there is also an "old" and "new" version
of this peripheral in the Au1100. The new one tried to address
some of the problems, and it helped a little. If you code to
the "old" interface, I believe it will work on all silicon (with
challenges), but if you detect the new silicon it's a little easier
to meet the latency requirements. However, I could always
find too many cases where the interrupt latency of Linux
just caused us to miss interrupts and lose the USB state.
The Gadget interface is really nice, but the additional
indirection of the software layers makes the problems
even more challenging.
Good Luck. I've been there and don't care to visit again.