On Mon, Mar 04, 2002 at 12:14:33PM -0800, David Brownell wrote:
> > > > >     - Shows high bandwidth endpoints with something like
> > > > >       "1024*3" for maxpacket size; other endpoints just
> > > > >       have two extra spaces there.
> > > > 
> > > > Why have the "*n" here?  Why not just spit out the whole number?  That
> > > > would break less parsers :)
> 
> I suspect they'd already be breaking due to the polling
> intervals measured in microseconds.  Which, FWIW,
> can seem a bit much.
> 
> Comments about continuing to measure in milliseconds,
> except when microseconds are necessary (e.g. for 250us.
> poll intervals)?  That'd make parsing rather complex, but
> then some of us have always thought that file was there
> for users to read, not programs ... :)

I agree, the file is there for users, not programs.  I don't mind the
change.

> > > Because the "high bandwidth" mode doesn't affect
> > > the maximum packet size ... it allows multiple packets
> > > to be issued per microframe, each of up to maxpacket.
> > > It's a new (bit)field in the endpoint descriptor.
> > 
> > Then why try to overload the "maxpacket size" field and not just add a
> > new field, "packets per microframe"?
> 
> Well, for control and bulk there's no fixed number ... :)
> 
> Rather than that I'd just change the meaning of the field,
> and do the multiply.  For ISO/INTR it'd be the max data
> transferred per schedule interval (frame or microframe).
> For CTRL/BULK it'd be the same ... except that the
> schedule interval isn't fixed, it's "as available".

That sounds good.

> The "high bandwidth" mode does seem like it's set up
> so that there's only one way to encode N bytes.  It's
> not legal to send 1024 bytes as 512*2, it's got to be
> one big packet instead; and there's a similar boundary
> at 2048 bytes.  (See table 9-14.)

I've always wondered about that table, and what kind of device is going
to require that big of a packet for every transaction.  We are sure are
moving beyond the simple "keyboard and mouse" bus replacement :)

thanks,

greg k-h

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to