Re: USB changes for UAS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 01, 2010 at 10:02:56PM -0400, Alan Stern wrote:
> > Yup.  It's probably also more overhead on the host side.  As we've
> > discussed before, most UAS devices probably still do BOT on a different
> > interface configuration, and I'm quite happy for usb-storage to outperform
> > uas in these circumstances.
> 
> So whatever scheme we use to select a driver, it should default to UAS 
> if the HCD has SG support and to BOT otherwise?  (Boy, I hardly ever 
> get to use so many acronyms in a single sentence!)

Well, yeah, that's not ideal :-)

> > Only what I've done so far -- making it possible for a driver to directly
> > populate urb->sg and send it down without using the usb_sg_wait()
> > interface.
> 
> If the scatterlist is allowed to contain more than one element, this
> would be tantamount to enhancing usb_sg_* to work asynchronously and
> folding it into usb_submit_urb().

Yes, I suppose it would.

> > The patch you did to EHCI (as1300 / commit 40f8db8f8f) does look quite
> > straightforward to port to the uhci-q.c and ohci-q.c file.  On the one
> > hand, that's a good thing, because I can just do that (er, if I can figure
> > out a way to test either of them).
> 
> Testing is easy -- just see if your mass storage devices still work.  
> usb-storage calls usb_sg_*, which will use the HCD's native SG support.

Easy ... if you have the hardware.  I need to check my hubs to see if
I have one that's USB 1.1 only, so I can force an EHCI controller into
UHCI mode.  I had to look fairly hard to find an OHCI controller in my
machine collection (not too many non-Intel chipsets in my house :-)

> >  On the other hand, it's not taking
> > advantage of EHCI's native ability to do scatter-gather in a single qtd if
> > the pages are virtually contiguous (see pages 86-88 of the EHCI 1.0 spec).
> > 
> > So EHCI could be further enhanced ... if it's worth it.
> 
> Hmm, maybe...  If it's not too hard to do.  I'll have to look at the 
> code.

I think the cleanest way to do it is to split qtd_fill into qtd_fill_buf
and qtd_fill_sg; use the former for the usb_pipecontrol and one_more
cases; and the latter in the main loop.  qtd_fill_buf could be quite simple
since it's never going to use multiple pages.  qtd_fill_sg would be pretty
complex though.

I have no idea how much improvement we'd see from using multiple pages
in a qtd instead of using one qtd per page though.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux