lkml.org 
[lkml]   [2008]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Scatter-gather list constraints
On Mon, 23 Jun 2008, David Vrabel wrote:

> 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?

Yes, there are two fields in struct request_queue for this:
max_phys_segments (the driver's limit) and max_hw_segments (the
hardware's limit).

Standard EHCI hardware requires that the memory locations of the data
for each packet be "virtually contiguous", i.e., discontiguities are
allowed only at 4-KB page boundaries. This severely limits the ability
to handle general S-G lists. For example, a 1024-byte packet can't be
broken up into two 512-byte pieces unless the first piece ends at a
page boundary and the second piece begins at a page boundary. Maybe
HWA host controllers are required to be more flexible, I don't know.

This may mean that your suggested approach won't work.

Alan Stern



\
 
 \ /
  Last update: 2008-06-23 21:47    [W:0.075 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site