From: David Vrabel <david.vrabel@csr.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
AntonioLin <antonio.lin@alcormicro.com>,
linux-usb@vger.kernel.org, "Perez-Gonzalez,
Inaky" <inaky.perez-gonzalez@intel.com>
Subject: Re: Scatter-gather list constraints
Date: Mon, 23 Jun 2008 20:06:52 +0100 [thread overview]
Message-ID: <485FF44C.4010600@csr.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0806231109280.2556-100000@iolanthe.rowland.org>
Alan Stern wrote:
> On Mon, 23 Jun 2008, David Vrabel wrote:
>
>> Note that this 1024 byte multiple is for one particular WUSB mass
>> storage device. The WUSB standard permits max packet sizes of up 3584
>> (in multiples of 512), but I suspect WUSB mass storage devices will only
>> use 512, 1024, or 2048.
>>
>> For a solution, we may be able to do something if the HWA host
>> controller is passed a single URB with an s-g list (rather than one URB
>> per s-g list entry) and was careful about how it segmented the URB into
>> transfers to the rpipe.
>
> That would be ideal. However there is no way to pass an S-G list along
> with an URB; there's no field for it in the data structure. And none
> of the existing host controller drivers support such a thing.
>
> I suppose we could add a field to struct urb and add a flag indicating
> whether the controller driver supports S-G lists.
This is what I was thinking.
Can the number of entries in a sg list be limited? e.g., if the
hardware only had support for say, 64 entries?
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
next prev parent reply other threads:[~2008-06-23 19:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 20:30 Scatter-gather list constraints Alan Stern
2008-06-20 20:50 ` David Miller
2008-06-21 13:59 ` Andi Kleen
2008-06-21 14:54 ` Alan Stern
2008-06-21 15:21 ` Andi Kleen
2008-06-21 21:50 ` Alan Stern
2008-06-21 23:00 ` Andi Kleen
2008-06-22 14:35 ` Alan Stern
2008-06-24 10:41 ` FUJITA Tomonori
2008-06-24 14:57 ` Alan Stern
2008-06-25 0:18 ` FUJITA Tomonori
2008-06-25 14:23 ` Alan Stern
2008-06-26 2:06 ` FUJITA Tomonori
2008-06-26 5:39 ` FUJITA Tomonori
2008-06-26 6:35 ` Jens Axboe
2008-06-26 6:58 ` FUJITA Tomonori
2008-06-26 12:39 ` Jens Axboe
2008-06-26 12:54 ` Andi Kleen
2008-06-26 13:00 ` Jens Axboe
2008-06-26 15:12 ` Alan Stern
2008-06-26 17:41 ` Jens Axboe
2008-08-27 21:32 ` Alan Stern
2008-06-26 15:16 ` Boaz Harrosh
2008-06-26 17:39 ` Jens Axboe
2008-06-26 14:18 ` Alan Stern
2008-06-23 14:46 ` David Vrabel
2008-06-23 15:12 ` Alan Stern
2008-06-23 19:06 ` David Vrabel [this message]
2008-06-23 19:45 ` Alan Stern
2008-06-23 21:53 ` Stefan Richter
2008-06-25 4:02 ` Perez-Gonzalez, Inaky
2008-06-25 14:24 ` Alan Stern
2008-06-26 16:43 ` Perez-Gonzalez, Inaky
2008-06-26 19:34 ` Alan Stern
2008-06-26 22:39 ` Inaky Perez-Gonzalez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=485FF44C.4010600@csr.com \
--to=david.vrabel@csr.com \
--cc=antonio.lin@alcormicro.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.