UHCI,OHCI,EHCI: number of TDs necessary ?

[erdmann]

Hallo,

reading through USB 2.0 spec and UHCI,OHCI,EHCI specs, do I understand this correctly:
UHCI: exactly one TD per endpoint's maxPacketSize (or less) ?
OHCI: one TD possibly for MULTIPLE packets of maxPacketSize (or less) ?
EHCI: one TD possibly for MULTIPLE packets of maxPacketSize (or less) ?

With "maxPacketSize" I mean the size that is reported as "wMaxPacketSize" for the endpoint descriptor or 8 bytes for a setup packet.


I am aware of the fact that control transfers are a different beast in that the setup, optional data and ack stages need separate TDs by nature.


What gets me confused are the 2 terms "max data payload" and "maxPacketSize" in the USB spec. They seem to be the same but I am not sure.

[Jan Axelson]

The answer to the first question I don't know offhand, but maximum data payload and wMaxPacketSize are the same thing.

See 5.5.3 in the USB 2.0 spec:

An endpoint reports in its configuration information the value for its maximum data payload size.

and similar statements for other endpoint types.

[erdmann]

I have problems understanding the specific way in which UHCI, OHCI, EHCI manage transfers via TDs. The question was how much data one TD can handle:

my impression was that for UHCI you have to "spend" one TD for each transfer of wMaxPacketSize size (or less if there is less to transfer). Consequently you have to set the toggle bit for each individual packet as a TD applies to exactly one packet and you will have to split up a large transfer into multiple transfers of wMaxPacketSize length in software.

For OHCi and EHCI I have a different impression: looks like you need to specify wMaxPacketSize size (in the Endpoint descriptorfor OHCI or queue head for EHCI respectively) but you can specify data buffers much larger than wMaxPacketSize. Looks like OHCI and EHCI are smart enough to break up a large transfer described by a single TD into multiple transfers of wMaxPacketSize length (or less for the last packet) and toggle the toggle bit completely autonomously for these multiple packets.

Correct ?

[Barry Twycross]

You impression is correct.

UHCI is very dumb and makes the host driver do a lot of the work. I'd forgotten it can't even keep track of data toggles. So the host driver has to schedule each packet individually, with the correct data toggle.

OCHI was designed to be smarter than UHCI and the hardware took on some of the responsibility that UHCI delegated to software. OCHI can (and does) keep track of the data toggle for you. A buffer larger than one packet is also possible, an OHCI TD can on average cope with 4k of data, memory is assumed to be in 4k pages and it'll cope with one page crossing.

The stated intent of EHCI was to combine the best of UHCI and OHCI, it keeps track of data toggles like OHCI and has similar buffer management to OHCI. One TD can on average cope with 16k of data, with 4 page crossings.

[erdmann]

Many thanks for your answer which answered my question.