On 01/09/2012 04:45 PM, Greg KH wrote:
On Mon, Jan 09, 2012 at 04:31:59PM +0100, Sebastian Andrzej Siewior wrote:
On 01/09/2012 04:09 PM, Greg KH wrote:
On Mon, Jan 09, 2012 at 03:32:38PM +0100, Sebastian Andrzej Siewior wrote:
On 01/09/2012 03:23 PM, Matthew Wilcox wrote:
On Mon, Jan 09, 2012 at 01:55:02PM +0100, Sebastian Andrzej Siewior wrote:
Hi Sarah,
I've been looking into UAS support for hcds without support for sg.
I think that's fundamentally the wrong approach. Instead, HCDs should
be modified to add support for SGs. I posted a patch series that made
progress towards that goal a while back.
That is what Felipe and I decided for the gadget framework.
Alan / Greg, any comments from your side?
HGs should be supporting sg, why are they not?
It was not required in the first place because it was added later to
the usb framework. The EHCI, WHCI and XHCI host driver are the only
supporting it. I posted patches for dummy_hcd so we have 4 which
support it. There is a total of 22 hcds which makes 18% which have it
implemented.
Ok, and why would you want to run a UAS device on anything other than
those controllers?
There is nothing wrong with adding UAS to a device which can do only
USB2.0. On the hand you could attach your USB3.0 UAS device to the ohci
controller because you have an old computer _or_ some other device
which has only musb for instance.
usb_sg_init() provides a workaround for them. So if the HCD supports sg
it ends up with one URB. If it does not the function allocates a bunch
of URBs and sets urb->transfer_buffer = sg_virt(sg) for each sg entry
which should work. It will fail if the hcd supports DMA transfers (no
bounce buffer from the scsi host because it can handle high mem) and
does not support sg (for the HIGHMEM page the transfer_buffer will be
set to NULL).
So that could be one problem we have.
UAS is not using this function. It comes with usb_sg_wait() which
queues the URBs _and_ waits until the transfer is complete. For UAS
it should be non-blocking because we need to do this from IRQ
context.
So the question is how to deal with it.
Fix the UAS driver to not do a blocking call from interrupt context?
All this controllers are 2.0 or less. According to the protocol we
learn in the URB's completion that we have enqueue a new URB. So
blocking here means a context switch into an UAS-thread/workqueue. This
is no good.
So I propose (start of this thread) to change usb_sg_wait() so it does
not wait.
greg k-h
Sebastian
--
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
