On Thu, Oct 22, 2009 at 03:57:49PM -0400, Alan Stern wrote:
> On Thu, 22 Oct 2009, Sarah Sharp wrote:
>
> > Also, the frame ID field is only used for the starting frame. While
> > buffers are still posted within the isochronous scheduling threshold,
>
> "Posted"?
Sorry, not enough tea this morning. "Posting" is not any official term,
I was just talking about the act of telling the hardware about buffers
in an URB. Sort of like adding them to the frame list in EHCI, only
xHCI has different structures.
The xHCI driver maps an URB into one or more transfer request buffers
(TRBs) on an endpoint ring (which is a chunk of physically contiguous
memory). By "posted" I mean changing the fields in a TRB to include the
buffer pointer(s) in the URB and passing ownership of those TRBs to the
hardware by toggling the cycle bit of the TRBs. The xHCI driver will
then ring the doorbell for that endpoint.
The doorbell is a way to notify the hardware that there are buffers
available for an endpoint. You have to ring it every time for bulk and
control endpoints, since those are asynchronous. You have to ring the
doorbell for inactive periodic endpoints too. For active periodic
endpoints, the host doesn't need a doorbell, because it knows to look at
the ring before executing that scheduled transfer. If you ring a
doorbell for an empty ring or an active periodic ring, that should be
harmless. But ringing a doorbell is not always part of posting a
buffer.
> > the xHC will ignore the frame ID and transfer data at the interval
> > specified in the endpoint context.
>
> "Endpoint context"?
xHCI has an internal representation for each endpoint in a device that
the software sets up for the hardware:
/**
* struct xhci_ep_ctx
* @ep_info: endpoint state, streams, mult, and interval information.
* @ep_info2: information on endpoint type, max packet size, max burst size,
* error count, and whether the HC will force an event for all
* transactions.
* @deq: 64-bit ring dequeue pointer address. If the endpoint only
* defines one stream, this points to the endpoint transfer ring.
* Otherwise, it points to a stream context array, which has a
* ring pointer for each flow.
* @tx_info:
* Average TRB lengths for the endpoint ring and
* max payload within an Endpoint Service Interval Time (ESIT).
*
* Endpoint Context - section 6.2.1.2. This assumes the HC uses 32-byte context
* structures. If the HC uses 64-byte contexts, there is an additional 32 bytes
* reserved at the end of the endpoint context for HC internal use.
*/
struct xhci_ep_ctx {
u32 ep_info;
u32 ep_info2;
u32 deq[2];
u32 tx_info;
/* offset 0x14 - 0x1f reserved for HC internal use */
u32 reserved[3];
};
The host will only pay attention to the interval the xHCI driver sets in
the endpoint context.
> Here, are you talking about transactions other than the first? It's
> not clear how to reconcile your statements that "the frame ID field is
> ... used for the starting frame" and "the xHC will ignore the frame
> ID".
Sorry, I just got clarification on how the frame ID field is supposed to
work. The frame ID field is used in the first TRB when the isoc
endpoint is first being started, or being started after an
overrun/underrun error. After the first transfer, the frame ID field is
ignored.
> > If a buffer isn't posted within the IST, the host controller will send
> > one overrun/underrun event to the driver. It will also stop scheduling
> > transfers for that endpoint, but leave the bandwidth for that endpoint
> > claimed.
>
> Indeed, according to your previous descriptions bandwidth is never
> released until an altsetting or config is changed.
Yes, that is how it works right now; that could change in the future.
The USB core could be modified to call into the xHCI driver when a USB
device driver binds to an interface to reserve the bandwidth. Then
devices that don't have a driver, or interfaces that are never used
won't take bus bandwidth. But I'd like to actually get isoc transfers
working before I optimize the driver.
> > When the doorbell is rung again for the endpoint, the host
> > controller will restart the transfers, looking at the frame ID if it's
> > set and the ASAP flag isn't set.
>
> I hate the "doorbell" metaphor. For one thing, these bits don't behave
> like a door -- nothing gets opened or closed. For another, when you
> actually press the button to ring a physical doorbell, the button
> doesn't remain pressed the whole time until the door is opened -- it
> becomes unpressed the moment you release it.
I think they were going for a notification metaphor, and not thinking
about the mechanics of doorbells. :)
> > So, as long as you only use urb->start_frame for the starting *frame*,
> > the xHCI driver should be able to accommodate device drivers.
>
> But urb->start_frame is implemented as meaning the starting
> _microframe_ for high-speed devices.
Then why is it called start_frame and not start_microframe or
start_uframe? Grumble.
> However, given the hit-or-miss way in which existing HCDs implement it
> (i.e., basically not at all), I guess there's nothing wrong with
> pre-allocating the schedule and then choosing the actual starting
> uframe to be the slot closest to the uframe given by urb->start_frame.
Did you mean "choosing the actual starting frame"? Or are you planning
on scheduling inactive endpoints with microframe granularity for every
HCD other than xHCI?
Sarah
--
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
