au1x00 usb device status

au1x00 usb device status

[Rodolfo Giometti]

I'm trying to enable usb device support on an au1x00 based board, but
I notice that such support is still not ported to 2.6 nor to usb
gadget.

Does someone working on it in order to coordinate the job? :)

Thanks in advance,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

Re: au1x00 usb device status

[Pete Popov]

On Thu, 2005-10-06 at 09:33 +0200, Rodolfo Giometti wrote:
> I'm trying to enable usb device support on an au1x00 based board, but
> I notice that such support is still not ported to 2.6 nor to usb
> gadget.

USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550
just won't happen due to hw limitations. USB host and gadget on the 1200
are on hold at the moment. I'll let you know if that moves forward. We
already split out the pci bus dependencies from the echi driver and sent
David the patches. They'll be going upstream soon. Adding ehci host
support for the 1200 will be much easier then.

Pete

Re: au1x00 usb device status

[Rodolfo Giometti]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Thu, Oct 06, 2005 at 08:32:52AM -0700, Pete Popov wrote:
> USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550
> just won't happen due to hw limitations. USB host and gadget on the 1200

Thanks for your answer!

Can you please explain to me (in brief :) which hw limitations are you
talking about? Do you mean that usb device support in Linux cannot be
implemented, or just that this can be done but with some restriction?

Thanks for your help,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: au1x00 usb device status

[Pete Popov]

On Thu, 2005-10-06 at 17:47 +0200, Rodolfo Giometti wrote:
> On Thu, Oct 06, 2005 at 08:32:52AM -0700, Pete Popov wrote:
> > USB Host should be working fine. USB Gadget on the Au1000,1100,1500,1550
> > just won't happen due to hw limitations. USB host and gadget on the 1200
> 
> Thanks for your answer!
> 
> Can you please explain to me (in brief :) which hw limitations are you
> talking about? Do you mean that usb device support in Linux cannot be
> implemented, or just that this can be done but with some restriction?

Timing issues with the Au1x00 (not the au1200) make the Linux gadget
implementation extremely difficult to support. If you don't service the
usb interrupt within a certain amount of time, you lose the status and
the gadget loses its state.

Pete

Re: au1x00 usb device status

[Rodolfo Giometti]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Fri, Oct 21, 2005 at 02:12:17PM +0100, Hamilton, Ian wrote:
> We have code running under a 2.4 kernel working on this board, and I'm
> currently porting the code to a 2.6 kernel.
> 
> The USB device port seems to work OK for us with the 2.4 kernel.

Are you implemented any Gadget support? Or are you just using the
tty/raw emulation?

> Rodolfo,
> 
> Have you done any more work on this, or are you giving it up as a lost
> cause?

For the moment I sespended the developing in order to better
understand the timing problem, but I can restart immediately if some
new good news will came. :)

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@linux.it
Linux Device Driver                             giometti@enneenne.com
Embedded Systems                     home page: giometti.enneenne.com
UNIX programming                     phone:     +39 349 2432127

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: au1x00 usb device status

[Hamilton, Ian]

Hi Rodolfo.

> Are you implemented any Gadget support? Or are you just using the
> tty/raw emulation?

I'm a USB novice, so I'm not sure about this yet. The USB device port is
used
as a communication port to another board, so I guess a tty/raw emulation
would be appropriate, but I don't yet know how it was implemented on the
2.4
kernel. I'm still trying to understand the code.

I was hoping it would be a straight copy from 2.4 to 2.6, but clearly it
isn't :-(

Still, it is an opportunity to learn about USB :-)

Cheers,
Ian.

RE: au1x00 usb device status

[Hamilton, Ian]

Hi Rodolfo.

> Are you implemented any Gadget support? Or are you just using the
> tty/raw emulation?

I'm a USB novice, so I'm not sure about this yet. The USB device port is
used
as a communication port to another board, so I guess a tty/raw emulation
would be appropriate, but I don't yet know how it was implemented on the
2.4
kernel. I'm still trying to understand the code.

I was hoping it would be a straight copy from 2.4 to 2.6, but clearly it
isn't :-(

Still, it is an opportunity to learn about USB :-)

Cheers,
Ian.

Re: au1x00 usb device status

[Dan Malek]

On Oct 21, 2005, at 10:01 AM, Hamilton, Ian wrote:

> ......  so I guess a tty/raw emulation
> would be appropriate,

That's all that was available in 2.4.  I'd say if you actually
see it working, you are lucky :-)  The only way I have seen
this work successfully in a real product was using a
custom RTLinux driver to service most of the USB hardware,
then feed this upstream to the Linux USB software.

> I was hoping it would be a straight copy from 2.4 to 2.6, but clearly 
> it
> isn't :-(

You will want to use the gadget interface.  I think most of what
we had done in the past has been checked in, but if not I'll
dig it out.  It was never functional to my satisfaction.


Thanks.


	-- Dan

Re: au1x00 usb device status

[Dan Malek]

On Oct 21, 2005, at 10:01 AM, Hamilton, Ian wrote:

> ......  so I guess a tty/raw emulation
> would be appropriate,

That's all that was available in 2.4.  I'd say if you actually
see it working, you are lucky :-)  The only way I have seen
this work successfully in a real product was using a
custom RTLinux driver to service most of the USB hardware,
then feed this upstream to the Linux USB software.

> I was hoping it would be a straight copy from 2.4 to 2.6, but clearly 
> it
> isn't :-(

You will want to use the gadget interface.  I think most of what
we had done in the past has been checked in, but if not I'll
dig it out.  It was never functional to my satisfaction.


Thanks.


	-- Dan

Re: au1x00 usb device status

[Dan Malek]

On Oct 21, 2005, at 9:17 AM, Hamilton, Ian wrote:

> Is there a full description of the timing problem somewhere on the web?
> 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.


	-- Dan

Re: au1x00 usb device status

[Dan Malek]

On Oct 21, 2005, at 9:17 AM, Hamilton, Ian wrote:

> Is there a full description of the timing problem somewhere on the web?
> 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.


	-- Dan

RE: au1x00 usb device status

[Hamilton, Ian]

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 :-)

Cheers,
Ian.

-----Original Message-----
From: Dan Malek [mailto:dan@embeddedalley.com] 
Sent: 21 October 2005 16:36
To: Hamilton, Ian
Cc: 'linux-mips@linux-mips.org' 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
web?
> 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.


	-- Dan

RE: au1x00 usb device status

[Hamilton, Ian]

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 :-)

Cheers,
Ian.

-----Original Message-----
From: Dan Malek [mailto:dan@embeddedalley.com] 
Sent: 21 October 2005 16:36
To: Hamilton, Ian
Cc: 'linux-mips@linux-mips.org' 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
web?
> 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.


	-- Dan