> My hope was that I could use the fact that the ->next pointer doesn't
> submit the data stage URB until _after_ the command stage URB is completed.
As I say, this is naturally done in the completion sequence,
outside the HCD (and today, in the completion handler).
My main issue is that the HCDs shouldn't need to care
about such stuff: they should deal with I/O transfers, and
that's about all.
Now, if some shared code, like the usb_hcd_giveback_urb()
routine used currently by the EHCI driver, were to basically
usb_submit_urb (urb->next) before it invoked the completion
handler on a successful urb, I'd be happy enough. (More so
if all the HCDs did the same kind of stuff...)
> > > This works well when I've only
> > > got one command to deal with at a time, but I'd like to be able to handle
> > > multiple commands in the queue to improve performance.
> >
> > But any one of them can get an error ... I don't quite see how the URBs can
> > take care of themselves that much.
>
> Right... but what errors? The endpoint can stall in the data stage,
> retiring all the data stage URBs and accelerating us to the status stage.
Similarly for any of the other errors that can ever happen.
If you're saying you want the first error from a chain of (bulk) requests to
kill all the other requests in that chain, I'd be happy with that answer ... I've
had a question in that area! I can make EHCI bulk do that quickly enough;
dunno what other HCDs do today.
> The device can be removed, which retires all the URBs. Short packets won't
> happen, and if they do, we're so hosed anyway that killing the device is
> the only option....
Ah, isn't it desirable to recover from many failures? I guess that's an
issue in the filesystem/scsi/... layering. Read alternate blocks, write
to a better sector, and so on. Killing seems too severe.
> > I can see all of that working with today's URB submission API, as sketched
> > above. Though I'm thinking the "submit" would be to a small state machine
> > engine used only by usb-storage, which talks to usbcore as needed. (Those
> > synchronous control/bulk submission routines would vanish ...)
>
> Doesn't it seem a bit silly to need a custom state machine here, when more
> drivers might be able to use it? Yes, it could be done your way ...
I'm talking about stuff I don't want to see in HCDs, you're talking about stuff
you don't want to see in device drivers. Luckily there's software between the
two, which could handle such stuff!
Suppose you could submit an urb->next chain:
control (for command)
bulk (block1)
bulk (block2)
bulk (block3)
...
bulk (blockN)
bulk (status)
The engine could presumably hide inside usb_submit_urb, but not
nessarily need to live inside each HCD ...
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
