> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
> On Thu, May 04, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> > 4. bandwidth allocation in HCDs [needed for USB PlugFest in
> > August/2000]
>
> Randy, you wrote the initial implementation. What do you
> think needs to be
> done to get this working correctly per the specs?
===
I'll be looking at it soon.
> I'd also like to add a number 5:
>
> 5. Standardize on one UHCI driver
===
Not surprised to see this added. It was almost in my
list. I agree that we need to decide on this
issue, but it's not a burning priority like PnP is
(except maybe to you, since it involves you & your time).
> > c. Remove some of the backwards-compatibility API.
>
> Which backwards-compatible API are you talking about? I'd like to keep
> usb_control_msg and usb_bulk_msg, but nuke usb_request_irq,
> usb_request_bulk and usb_terminate_bulk.
>
> According to my sources, the only driver which uses usb_request_irq is
> uss720.c and it doesn't seem all too difficult to fix.
>
> usb_control_msg and usb_bulk_msg are more convenience functions to do
> synchronous transfers than backward compatible API's.
===
Same conclusion, similar reasoning.
So do we need to leave the "nuke" ones for awhile, marked as
Deprecated, or nuke them now to discourage their use (if there
are some non-Linux-kernel-source code drivers using them)?
(and get uss720.c changed)
> > Request from Martin Mares:
> > - I'd also like to see some support for progress reporting
> > on bulk URB's. It's needed for my USB networking
> > driver which is close to being finished and I'd like to see
> > it in one of the first few 2.4 releases.
>
> Should we create a new API call for this?
>
> usb_status_urb which forces the HC driver to check on the status and
> update lengths, status, etc?
===
We really haven't discussed this functionality.
I put it here because MM responded to the last USB jobs list
with this request. How important is it? Is it something
that several drivers would like/would use?
It seems a little "different" to me. You don't ask
PCI or SCSI or an Ethernet adapter or a modem how much of a
transfer it has completed, do you? You could, but I don't
think that they are mainstream requests.
Or asked another way: What does this provide to a driver?
A chance to increase performance by being able to stream
some I/O requests a little better? If so, that would be
interesting to me.
~Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]