David Brownell wrote:
>
> > > > Because it's faster to just send the CLEAR_HALT than to actually stop and
> > > > look at the status -- other driver vendors have realized this, resulting in
> > > > some odd-looking but totally legal bus transactions which run very quickly.
> > >
> > > I can't buy this. The instructions requesting I/O cost more than the ones
> > > testing status, and then there's cost for the I/O cost itself.
> >
> > But not when you have to have an interrupt before you can check status and thus
> > miss at least 1 usb frame.
>
> Based on the previous context, I was assuming that interrupt already.
> It had already been established that today's host controller drivers won't
> guarantee the type of scheduling you've just assumed. (On Linux, that is.)
I realise that.
I was suggesting it might be usefull to have support for this in the HCD drivers.
With usb-storage it would reduce the time for a read/write transfer to complete with
(a max of ) 11
ms.
11ms is a lot of (extra) delay for a diskoperation.
Are there any other drivers who could benefit from the mechanism requested?
> > I am not familiar with the specifics of the *hci's, so I don't know if this is
>even possible.
>
> Well, the UHCI drivers won't queue control urbs, and while OHCI
> can do that I don't see any guarantees (from any *hci driver) for how
> sequencing is done on control and bulk requests. Periodic urbs
> (interrupt, iso) are the only ones offering any guarantees.
Again, I am aware of that.
I was actually wondering whether it can be done by the hardware?
(sorry if I got my naming mixed up)
> (The urb->next queuing, above the HCD queue level, can provide
> such sequencing guarantees, but only if it's leveraging bulk queuing
> is it going to be able to avoid needing interrupts to trigger progress
> to the next urb in the sequence.)
If no other drivers need a mechanism like the requested one, I don't think it would be
very usefull
to implement it. With the usage of bulk queueing, the driver would loose only 2
frames on
resubmitting during completion. (The one after the control, submitting 10 queued bulk
urbs, and the
one after the last bulk urb, submitting the status_bulk and an optional unstall on the
data
endpoint.) Good enough I guess, maybe if I had a usb harddrive I would think
differently ;)
J.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
