> >One difference between that and what Roman sketched
> >was that I did was in the model for schedule management:
> >
> >- He suggested a new HCD level "set_endpoint_properties"
> > call (perhaps coupled to set_config and set_interface?)
> > to schedule the bandwidth.
> >
> This is just the old idea of a static, consistent and valid 'endpoint
> property descriptor'.
> Basically a URB is a container that contains the data and has a big label.
> At the moment we put some informations of an endpoint onto that label
> (type of transfer, interrupt interval,..) and some other informations of
> an endpoint into core-structures (toggle bit, max-packet size,...).
By "core structures" you mostly mean the usb_device and host
controller-internal structures. Type and (maximum) polling interval
(it is NOT an INTR-only notion, ISO uses it too :) are trouble spots.
> And labels of two different URBs to an endpoint can contain inconsistent
> data.
> So I think a URB should just contain the data/length/status and
> an address (endpoint/device or pointer to an endpoint descriptor) but
> not any property of an endpoint.
Hmm, that wasn't all I thought you said. Though admittedly
there's a distinction between _scheduling_ the bandwidth
and between setting the schedule _parameters_ ...
So far as the parameters go, I agree with you that duplicating
such stuff in the URB is error prone, we should move that. It'd
be appropriate to track that stuff in usb_device. I could see
it costing 32 endpoints * { 1 byte period, 1 byte type }. Or
making that info from endpoint descriptors more accessible;
that seems better (array of 32 mostly-null pointers).
> >- I'd suggested that the bandwidth would stay scheduled until
> > after an interrupt transfer completed, there was no transfer
> > queued.
> >
> If I understand you right here, I think you lose the offset (or phase)
> information of the interrupt schedule of the endpoint.
Not necessarily. It that's important, INTR and ISO endpoints could
record that schedule info. On the other hand, for HCs with a real
periodic schedule (including EHCI, OHCI, UHCI) it'd only matter
in the case where a periodic endpoint got fully descheduled, and
then another transfer got scheduled before that period completed.
Otherwise keeping the QH/ED in the schedule is what'd keep the
bandwidth scheduled ... and the offset/phase would be stable.
Once periodicity is lost (8 ms after the last 8ms-INTR transfer) the
phase doesn't really matter any more. Another option: defer the
deschedule until that point. (I'm sure that'd make Dan happier;
"re"submitting a new request from a userland completion handler
would be painful; being able to rely on some grace period would
be friendlier. :)
> E.g. if we send single shot interrupt URBs every 10ms to a 255ms
> endpoint. Then I
> think the transfer should take place every 255 ms.
> With your model there would be a transfer every 10ms.
Actually I was assuming the "single shot" model would vanish
for interrupt transfers (API change #2). So with today's model,
where urb->interval is used instead of a device property, that
endpoint becomes a 10ms one. (And almost all HCDs will turn
turn a "10ms" interrupt into an "8ms" one.)
But that does suggest that if usb_set_configuration() and
usb_set_interface() cause usbcore/etc to track that period,
keeping it out of the URB, then some call would be needed
to let the period be reduced.
Separate issue: not all controllers can support a 255ms
interrupt transfer period without major mayhem. Of course
it's legit for OHCI to truncate that to a 32ms period, since
polling more frequently is allowed.
- Dave
> - Roman
>
> >
> >Yes, I tend to think that it might be worth breaking existing
> >interrupt transfer code in this way to get an improved API.
> >But it'd be work...
> >
> >- Dave
> >
> >p.s. I have similar comments about ISO transfers... :)
> >
> > Apart from some wire-level differences, the main
> > structural difference between INTR and ISO is
> > supposed to be that (a) no lowspeed ISO, (b) for
> > fullspeed, INTR has a smaller maxpacket (64 bytes
> > vs 1023 for ISO), (c) at all speeds, errors on INTR
> > transfers are supposed to get retried, but ISO ones
> > get reported. Both are supposed to respect the
> > endpoint poll period, and "high bandwidth" mode
> > (up to 24 MByte/sec, highspeed) works much the same.
> >
> > In short, we may want to consider corresponding
> > updates to the ISO transfer model, since it's not
> > intended to be as different from the INTR one as
> > it is today in Linux.
> >
> >
> >
> >
> >
>
>
>
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
