At 12:47 PM 5/21/2007, Alan Stern wrote:
Dave:
The situation with regard to start_frame is a mess. Although the name
and the documentation refer to frame numbers, for high speed devices
the value stored there is a microframe number instead.
Clearly anyone who's interested in the value will want to know the full
microframe number. But on the other hand, the value returned from
ehci_get_frame() actually _is_ a frame number, so there's no way for
drivers to learn the current microframe. Thus we have several related
problems: How to tell whether you're dealing with frames or microframes
and when to use each. Any suggestions on how to solve them?
Also, it seems to me that drivers ought to be able to take the current
(micro)frame value, add a small amount to it, and specify the result as
the start frame for an URB. But such behavior is not documented as
always workable, and we don't have any firm standard for how big the
"small amount" can be. My feeling is that all HCDs should guarantee
that anything up to 1 second will be acceptable. What do you think?
Alan Stern
Hi Alan,
About EHCI frame numbers. From the EHCI manual section 2.3.4:
<quote>
The SOF frame number value for the bus SOF token is derived or alternatively
managed from this register.
Please refer to Section 4.5 for a detailed explanation of the SOF value
management requirements on the host
controller. The value of FRINDEX must be 125 ìsec (1 micro-frame) ahead of
the SOF token value. The
SOF value may be implemented as an 11-bit shadow register. For this
discussion, this shadow register is 11
bits and is named SOFV. SOFV updates every 8 micro-frames. (1 millisecond).
An example implementation
to achieve this behavior is to increment SOFV each time the FRINDEX[2:0]
increments from a zero to a
one.
Software must use the value of FRINDEX to derive the current micro-frame
number, both for high-speed
isochronous scheduling purposes and to provide the get micro-frame number
function required for client
drivers. Therefore, the value of FRINDEX and the value of SOFV must be kept
consistent if chip is reset or
software writes to FRINDEX. Writes to FRINDEX must also write-through
FRINDEX[13:3] to
SOFV[10:0]. In order to keep the update as simple as possible, software
should never write a FRINDEX
value where the three least significant bits are 111b or 000b. Please refer
to Section 4.5
</quote>
So FRINDEX does count microframes, but the bus only sees bits d13 to d3. In
fact what Linux can respond in 125 microseconds? Realistically, very few
systems can respond in 1ms to use the frame number. So worrying about giving
an exact microframe number some unknown amount of time in the past is not
very useful.
Guaranteeing taking a scheduling value 1 second is the worst possible case,
but really a system should somehow know what its worst latency is, and use
that as the minimum. At the least, the size of the periodic table is the
(useful) worst case -(which is 256, 512 or 1024 ms).
Regards, Steve
_________________________________________________________________
More photos, more messages, more storageget 2GB with Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
