What to do with all of the USB UHCI drivers in the kernel?

What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
controller drivers in the kernel!  That's about 3 too many for me :)

So what to do?  I propose the following:

  From now until July 1, I want everyone to test out both the uhci-hcd
  and usb-uhci-hcd drivers on just about every piece of hardware they
  can find.  This includes SMP, UP, preempt kernels, big and little
  endian machines, and loads of different types of USB devices.

  (Note, for those who don't realize it, the uhci-hcd driver is based
  off of the uhci.c driver, and the usb-uhci-hcd driver is based off of
  the usb-uhci.c driver.  Both of these drivers now use the USB HCD
  interface, hopefully reducing some code complexity and size because of
  this.  So this means that the uhci.c and usb-uhci.c drivers are
  going to go away, just like the usb-ohci.c driver did in 2.5.16.)

  Let me (and the linux-usb-devel list) know about any thoughts you have
  pertaining to liking one of the drivers over the other one.  Speed
  tests, size tests, code pretty tests, comment spelling tests,
  documentation tests, you name it, I want to know about it.  If you
  don't want your comments to be public, send them to me directly and I
  will not let anyone else know what you said, but will use the info to
  try to pick which one should stay.

  I will be doing the same thing (running speed tests, and hardware
  tests) and will be publishing those results on the linux-usb-devel
  list for others to verify.

  Then, the week of July 1, I will be taking everyone's comments and
  making a decision about which driver to keep.

thanks,

greg k-h

RE: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

Greg,

I'm gonna speak for Bluetooth USB devices.
I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF 
reader, etc. But they don't
seem to care much about which HCD is used and work equally well with both 
usb-uhci and uhci drivers.

I used to be a uhci driver fan :). But starting somewhere from 2.4.16 or so 
Bluetooth devices work much better
with usb-uhci driver (not all devices but most of them). Even thought 
Bluetooth is pretty slow (about 700kbps)
performance difference is sometimes pretty significant 20-30% (ie usb-uhci 
driver is faster).

So basically I vote for usb-uhci. However some things will have to be 
fixed. We (Bluetooth folks) have couple
of devices that refuse to work with usb-uhci (I didn't test the latest 
usb-uhci though).

Thanks
Max

>Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
>controller drivers in the kernel!  That's about 3 too many for me :)
>
>So what to do?  I propose the following:
>
>   From now until July 1, I want everyone to test out both the uhci-hcd
>   and usb-uhci-hcd drivers on just about every piece of hardware they
>   can find.  This includes SMP, UP, preempt kernels, big and little
>   endian machines, and loads of different types of USB devices.
>
>   (Note, for those who don't realize it, the uhci-hcd driver is based
>   off of the uhci.c driver, and the usb-uhci-hcd driver is based off of
>   the usb-uhci.c driver.  Both of these drivers now use the USB HCD
>   interface, hopefully reducing some code complexity and size because of
>   this.  So this means that the uhci.c and usb-uhci.c drivers are
>   going to go away, just like the usb-ohci.c driver did in 2.5.16.)
>
>   Let me (and the linux-usb-devel list) know about any thoughts you have
>   pertaining to liking one of the drivers over the other one.  Speed
>   tests, size tests, code pretty tests, comment spelling tests,
>   documentation tests, you name it, I want to know about it.  If you
>   don't want your comments to be public, send them to me directly and I
>   will not let anyone else know what you said, but will use the info to
>   try to pick which one should stay.
>
>   I will be doing the same thing (running speed tests, and hardware
>   tests) and will be publishing those results on the linux-usb-devel
>   list for others to verify.
>
>   Then, the week of July 1, I will be taking everyone's comments and
>   making a decision about which driver to keep.
>
>thanks,
>
>greg k-h



Max

http://bluez.sf.net
http://vtun.sf.net

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Greg KH]

On Tue, May 21, 2002 at 12:41:39PM -0700, Maksim (Max) Krasnyanskiy wrote:
> Greg,
> 
> I'm gonna speak for Bluetooth USB devices.
> I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF 
> reader, etc. But they don't
> seem to care much about which HCD is used and work equally well with both 
> usb-uhci and uhci drivers.
> 
> I used to be a uhci driver fan :). But starting somewhere from 2.4.16 or so 
> Bluetooth devices work much better
> with usb-uhci driver (not all devices but most of them). Even thought 
> Bluetooth is pretty slow (about 700kbps)
> performance difference is sometimes pretty significant 20-30% (ie usb-uhci 
> driver is faster).
> 
> So basically I vote for usb-uhci. However some things will have to be 
> fixed. We (Bluetooth folks) have couple
> of devices that refuse to work with usb-uhci (I didn't test the latest 
> usb-uhci though).

Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted
anyway :)

I am more interested in usb-uhci-hcd.c and uhci-hcd.c drivers, which both
showed up in 2.5.16.  Yes they are based on the previous usb-uhci.c and
uhci.c drivers respectivly, but they are a bit different (they use the
hcd core code which reduces the size of the driver.)

You also might want to check out uhci.c again in 2.4.19-pre.  It has had
a lot of previous bugs fixed and works _much_ better for me than before.

thanks,

greg k-h

Re: [linux-usb-devel] RE: What to do with all of the USB UHCI drivers in the kernel ?

[Johannes Erdfelt]

On Tue, May 21, 2002, Maksim (Max) Krasnyanskiy <maxk@qualcomm.com> wrote:
> I'm gonna speak for Bluetooth USB devices.
> I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF 
> reader, etc. But they don't
> seem to care much about which HCD is used and work equally well with both 
> usb-uhci and uhci drivers.
> 
> I used to be a uhci driver fan :). But starting somewhere from 2.4.16 or so 
> Bluetooth devices work much better
> with usb-uhci driver (not all devices but most of them). Even thought 
> Bluetooth is pretty slow (about 700kbps)
> performance difference is sometimes pretty significant 20-30% (ie usb-uhci 
> driver is faster).
> 
> So basically I vote for usb-uhci. However some things will have to be 
> fixed. We (Bluetooth folks) have couple
> of devices that refuse to work with usb-uhci (I didn't test the latest 
> usb-uhci though).

Please test the latest version of the drivers. Both uhci and usb-uhci
have had various bug fixes. I'm sure the performance problems you've had
with uhci have been fixed for a little while now.

Also, feedback about the -hcd variants would useful too since one of
those will be the only ones left for 2.5.

JE

Re: What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

On Tue, May 21, 2002 at 10:23:15AM -0500, Timothy E. Jedlicka - wrk wrote:
> greg@kroah.com said:
> > Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> > controller drivers in the kernel!  That's about 3 too many for me :)
> 
> Stupid follow-up question for you.  Is it possible for me to stay on 2.4.18, 
> but test the 2.5.16 USB subsystem?  I really don't want to move my whole 
> system to 2.5.16, but would be willing to experiment with the USB parts.  Is 
> this possible?  Can I just rebuild the usb modules - I'm guessing this 
> wouldn't work, but thought I would ask anyway.  Or to ask another way - any 
> way us 2.4 folks can help?

You _might_ want to try dropping the drivers/usb tree from 2.5.x into
2.4 (and the usb files in include/linux/usb*.h too) and see what
happens.

Odds are the build process will not work, and I think some of the usbfs
changes will also not work.  But it would be interesting to see what you
found :)

So in short, I don't think that you could test out the 2.5 code on 2.4.
Is there some reason you can't run a 2.5 kernel?  Personally I run it on
lots of different machines (laptops, desktops, servers, etc.)
successfully.

If you can't run a 2.5 kernel, you can just take a look through the
code, and tell me what you think of that.  Readability is one of the
criteria I'm going to be using.

thanks,

greg k-h

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

> > So basically I vote for usb-uhci. However some things will have to be
> > fixed. We (Bluetooth folks) have couple
> > of devices that refuse to work with usb-uhci (I didn't test the latest
> > usb-uhci though).
>
>Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted 
>anyway :)
I thought that usb-uhci-hcd and uhci-hcd are direct derivatives of usb-uhci 
and uhci
(ie just minor API changes). And therefor perform exactly the same.

>I am more interested in usb-uhci-hcd.c and uhci-hcd.c drivers, which both
>showed up in 2.5.16.  Yes they are based on the previous usb-uhci.c and
>uhci.c drivers respectivly, but they are a bit different (they use the
>hcd core code which reduces the size of the driver.)
I see. Ok. I'll try 2.5.17 on one of my machines with UHCI controller.

>You also might want to check out uhci.c again in 2.4.19-pre.  It has had
>a lot of previous bugs fixed and works _much_ better for me than before.
Ok.

Thanks
Max

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Johannes Erdfelt]

On Tue, May 21, 2002, Maksim (Max) Krasnyanskiy <maxk@qualcomm.com> wrote:
> 
> > > So basically I vote for usb-uhci. However some things will have to be
> > > fixed. We (Bluetooth folks) have couple
> > > of devices that refuse to work with usb-uhci (I didn't test the latest
> > > usb-uhci though).
> >
> >Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted 
> >anyway :)
> I thought that usb-uhci-hcd and uhci-hcd are direct derivatives of usb-uhci 
> and uhci
> (ie just minor API changes). And therefor perform exactly the same.

I wouldn't consider it a minor API change, but theoretically they should
perform identically. Since some changes were non trivial, I wouldn't
guarantee that they behave identically :)

However, I'm not sure that's all that interesting. The code is a
straight enough port over that if there are bugs, they'll be there in
both versions, except for some trivial porting mistakes. Those are easy
to find and easy to fix normally.

The other kinds of bugs, like fundamental design flaws or bugs that
have always been there, are more interesting and likely to be in both.

IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
testing with the -hcd variants is the most ideal since that will be the
final code base.

JE

Re: [linux-usb-devel] RE: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

>Please test the latest version of the drivers. Both uhci and usb-uhci
>have had various bug fixes. I'm sure the performance problems you've had
>with uhci have been fixed for a little while now.
Yep. I did a quick test with Intel, Ericsson and Broadcom devices.
Both HCDs have the same performance in 2.4.19-pre8.

>Also, feedback about the -hcd variants would useful too since one of
>those will be the only ones left for 2.5.
Will do.

Max

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

>IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
>testing with the -hcd variants is the most ideal since that will be the
>final code base.

Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
I did not notice any difference in behavior. Both have the same 
performance, just like 2.4.19-pre8.

One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
returns EINVAL if urb->interval==0.
My Broadcom FW loader (uses usbdevfs) needs one-shot interrupts. So in 
order to test Broadcom devices
I changed to hcd.c to allow urb->interval==0. With that change uhci-hcd 
works just fine, I can load fw and
use the device. But usb-uhci-hcd kills the machine pretty hard (hw reset 
needed).

Here is a patch for hcd.c.

--- hcd.c.orig  Tue May 21 17:50:09 2002
+++ hcd.c       Tue May 21 17:01:44 2002
@@ -1456,11 +1456,9 @@
          * supports different values... this uses EHCI/UHCI defaults (and
          * EHCI can use smaller non-default values).
          */
-       switch (temp) {
-       case PIPE_ISOCHRONOUS:
-       case PIPE_INTERRUPT:
+       if (urb->interval && (temp == PIPE_ISOCHRONOUS || temp == 
PIPE_INTERRUPT)) {
                 /* too small? */
-               if (urb->interval <= 0)
+               if (urb->interval < 0)
                         return -EINVAL;
                 /* too big? */
                 switch (urb->dev->speed) {

usb-uhci-hcd has to be fixed.
btw It tries to round interval value even thought it's done by hcd.c

So, Bluetooth USB devices should work fine with either usb-uhci-hcd or 
uhci-hcd.
(assuming that above patch is applied and one-shot is fixed in usb-uhci-hcd)

On a side note. Why are URBs still not SLABified ?
Drivers still have those silly urb pools and stuff. I thought you guys were 
gonna fix that.

Max

Re: What to do with all of the USB UHCI drivers in the kernel?

[André Bonin]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]


----- Original Message -----
From: "Greg KH" <greg@kroah.com>
To: <linux-usb-devel@lists.sourceforge.net>
Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
Sent: Monday, May 20, 2002 6:31 PM
Subject: What to do with all of the USB UHCI drivers in the kernel?


>
> Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> controller drivers in the kernel!  That's about 3 too many for me :)
>
> So what to do?  I propose the following:
>
>   From now until July 1, I want everyone to test out both the uhci-hcd
>   and usb-uhci-hcd drivers on just about every piece of hardware they
>   can find.  This includes SMP, UP, preempt kernels, big and little
>   endian machines, and loads of different types of USB devices.

The UHCI driver never recognizes my hardware.  The OHCI driver (in the
2.4.18 kernel) does however.  My Asus A7M266-D doesn't have an onboard USB
but they ship an add-on card with the motherboard (made by Asus).

I attached the relevant syslogs and kernel logs for a boot-up with the UHCI
driver.  The USB startup is towards the end.

List of USB devices attached:

1) AsusTek USB enhanced Host Controller
2) Logitech USB Camera (QuickCam Web)
3) NEC PCI to USB Open Host Controller
4) NEC PCI to USB Open Host Controller
5) USB Root Hub x2 (Must belong to the USB hub on my monitor, ViewSonic
G773-2)
6) USB Root Hub x2 (Must belong to the USB hub on my monitor, ViewSonic
G773-2)
7) Microsoft IntelliMouse Optical (imPs2)

Thanks!

>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

*****************************************************
André Bonin
Computer Engineering Technologist
Ottawa (Ontario)
Canada
*****************************************************

[-- Attachment #2: syslog --]
[-- Type: application/octet-stream, Size: 1201 bytes --]

May 21 20:36:20 Cherlyn kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
May 21 20:36:20 Cherlyn kernel: uhci.c: USB Universal Host Controller Interface driver v1.1
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usblp
May 21 20:36:20 Cherlyn kernel: printer.c: v0.12: USB Printer Device Class driver
May 21 20:36:20 Cherlyn kernel: Initializing USB Mass Storage driver...
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usb-storage
May 21 20:36:20 Cherlyn kernel: USB Mass Storage support registered.
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hiddev
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hid
May 21 20:36:20 Cherlyn kernel: hid-core.c: v1.31:USB HID core driver
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usbscanner
May 21 20:36:20 Cherlyn kernel: scanner.c: 0.4.6:USB Scanner Driver
May 21 20:36:20 Cherlyn kernel: mice: PS/2 mouse device common for all mice
May 21 20:36:21 Cherlyn /usr/sbin/gpm[221]: oops() invoked from gpn.c(454)
May 21 20:36:21 Cherlyn /usr/sbin/gpm[221]: Repeating into ImPS2 protocol not yet implemented :-(: File exists
May 21 20:36:22 Cherlyn lpd[234]: restarted

[-- Attachment #3: kern.log --]
[-- Type: application/octet-stream, Size: 1046 bytes --]

May 21 20:36:20 Cherlyn kernel: Linux version 2.5.17 (root@Cherlyn) (gcc version 2.95.4 20011002 (Debian prerelease)) #4 SMP Tue May 21 20:26:15 EST 2002
...
May 21 20:36:20 Cherlyn kernel: uhci.c: USB Universal Host Controller Interface driver v1.1
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usblp
May 21 20:36:20 Cherlyn kernel: printer.c: v0.12: USB Printer Device Class driver
May 21 20:36:20 Cherlyn kernel: Initializing USB Mass Storage driver...
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usb-storage
May 21 20:36:20 Cherlyn kernel: USB Mass Storage support registered.
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hiddev
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hid
May 21 20:36:20 Cherlyn kernel: hid-core.c: v1.31:USB HID core driver
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usbscanner
May 21 20:36:20 Cherlyn kernel: scanner.c: 0.4.6:USB Scanner Driver
May 21 20:36:20 Cherlyn kernel: mice: PS/2 mouse device common for all mice

Re: [linux-usb-devel] Re: What to do with all of the USB UHCI drivers in the kernel ?

[David Brownell]

Maksim (Max) Krasnyanskiy wrote:
> 
> One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
> returns EINVAL if urb->interval==0.

Hmm, eventually that automagic resubmit model needs to go away,
in favor of a straight queued transfer model -- where in effect
there are _only_ "one shot" transfers, which for interrupts are
just going to hang out on endpoint queues that are properly
scheduled.  That's needed to make interrupt reads and writes
have the same transfer model ... right now interrupt OUT transfers
don't work very well.  (And they'll be the most common type when
we eventually get those device/target side driver APIs sorted.)

Meanwhile, I suppose I can see wanting access to that UHCI-ism.
However your patch would do that wrong, since it should only
apply to interrupt transfers.


> usb-uhci-hcd has to be fixed.
> btw It tries to round interval value even thought it's done by hcd.c

That was one of my quick-review comments too.  It doesn't hurt,
it's just one of several URB sanity-check/preprocessing steps
that doesn't need to be in every driver.


> On a side note. Why are URBs still not SLABified ?

Hasn't seemed to be necessary.  kmalloc() is slabified already,
so it's not clear that a control/bulk/interrupt URB pool shared
between drivers -- size, maybe a handful -- would be better than
sharing that same memory with other kernel code.

- Dave

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Greg KH]

On Tue, May 21, 2002 at 06:04:21PM -0700, Maksim (Max) Krasnyanskiy wrote:
> 
> >IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
> >testing with the -hcd variants is the most ideal since that will be the
> >final code base.
> 
> Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
> I did not notice any difference in behavior. Both have the same 
> performance, just like 2.4.19-pre8.
> 
> One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
> returns EINVAL if urb->interval==0.
> My Broadcom FW loader (uses usbdevfs) needs one-shot interrupts. So in 
> order to test Broadcom devices
> I changed to hcd.c to allow urb->interval==0. With that change uhci-hcd 
> works just fine, I can load fw and
> use the device. But usb-uhci-hcd kills the machine pretty hard (hw reset 
> needed).
> 
> Here is a patch for hcd.c.

Thanks for the patch.

> On a side note. Why are URBs still not SLABified ?
> Drivers still have those silly urb pools and stuff. I thought you guys were 
> gonna fix that.

It hasn't been proven that it's really needed.  95% of the current
drivers create their urbs when the device is plugged in, and then free
them when they are removed.  Making that kind of allocation into a slab
is a bit silly :)

Now if more drivers start doing fun stuff like the visor.c driver does
in the 2.5 tree, then it might make more sense to create a URB specific
slab.

thanks,

greg k-h

Re: [linux-usb-devel] Re: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

At 09:33 PM 5/21/2002 -0700, David Brownell wrote:
>Maksim (Max) Krasnyanskiy wrote:
>>One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
>>returns EINVAL if urb->interval==0.
><....>
>Meanwhile, I suppose I can see wanting access to that UHCI-ism.
>However your patch would do that wrong, since it should only
>apply to interrupt transfers.
Yeah, I guess it doesn't make sense to do one-shot iso.

>>On a side note. Why are URBs still not SLABified ?
>
>Hasn't seemed to be necessary.  kmalloc() is slabified already,
>so it's not clear that a control/bulk/interrupt URB pool shared
>between drivers -- size, maybe a handful -- would be better than
>sharing that same memory with other kernel code.
Well, kmalloc has slabs of a fixed size and will round requested amount
to the nearest value. For example on x86 sizeof(struct urb) == 84 which
will be rounded to 96 by kmalloc ie 12 bytes unused (on Sparc64 it's about 
20 bytes).
Also we could use slab constructor to pre-initialize some urb fields.

Max

Re: What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

On Tue, May 21, 2002 at 09:10:04PM -0400, André Bonin wrote:
> 
> ----- Original Message -----
> From: "Greg KH" <greg@kroah.com>
> To: <linux-usb-devel@lists.sourceforge.net>
> Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
> Sent: Monday, May 20, 2002 6:31 PM
> Subject: What to do with all of the USB UHCI drivers in the kernel?
> 
> 
> >
> > Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> > controller drivers in the kernel!  That's about 3 too many for me :)
> >
> > So what to do?  I propose the following:
> >
> >   From now until July 1, I want everyone to test out both the uhci-hcd
> >   and usb-uhci-hcd drivers on just about every piece of hardware they
> >   can find.  This includes SMP, UP, preempt kernels, big and little
> >   endian machines, and loads of different types of USB devices.
> 
> The UHCI driver never recognizes my hardware.  The OHCI driver (in the
> 2.4.18 kernel) does however.  My Asus A7M266-D doesn't have an onboard USB
> but they ship an add-on card with the motherboard (made by Asus).

This is probably because you have an OHCI hardware device, not a UHCI
device.  What does 'lspci -v' say for your machine?

And how does 2.5.17 work for you?

thanks,

greg k-h

Re: What to do with all of the USB UHCI drivers in the kernel?

[Andre Bonin]

Greg KH wrote:
> On Tue, May 21, 2002 at 09:10:04PM -0400, André Bonin wrote:
> 
>>----- Original Message -----
>>From: "Greg KH" <greg@kroah.com>
>>To: <linux-usb-devel@lists.sourceforge.net>
>>Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
>>Sent: Monday, May 20, 2002 6:31 PM
>>Subject: What to do with all of the USB UHCI drivers in the kernel?
>>
>>
>>
>>>Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
>>>controller drivers in the kernel!  That's about 3 too many for me :)
>>>
>>>So what to do?  I propose the following:
>>>
>>>  From now until July 1, I want everyone to test out both the uhci-hcd
>>>  and usb-uhci-hcd drivers on just about every piece of hardware they
>>>  can find.  This includes SMP, UP, preempt kernels, big and little
>>>  endian machines, and loads of different types of USB devices.
>>>
>>The UHCI driver never recognizes my hardware.  The OHCI driver (in the
>>2.4.18 kernel) does however.  My Asus A7M266-D doesn't have an onboard USB
>>but they ship an add-on card with the motherboard (made by Asus).
>>
> 
> This is probably because you have an OHCI hardware device, not a UHCI
> device.  What does 'lspci -v' say for your machine?

Sorry, i'me not too familiar with the USB architecture.  Anyway here is 
the relevant lspci entries (note: I did this under my working 2.4.18)

02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
         Subsystem: Unknown device 807d:0035
         Flags: bus master, medium devsel, latency 32, IRQ 19
         Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
         Capabilities: [40] Power Management version 2

02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
         Subsystem: Unknown device 807d:0035
         Flags: bus master, medium devsel, latency 32, IRQ 16
         Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
         Capabilities: [40] Power Management version 2

02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
         Subsystem: Unknown device 807d:1043
         Flags: bus master, medium devsel, latency 32, IRQ 17
         Memory at cc000000 (32-bit, non-prefetchable) [size=256]
         Capabilities: [40] Power Management version 2


> And how does 2.5.17 work for you?

Not too good beacuse I don't have the option of enabling OHCI :)  Are we 
still keeping it?


> thanks,

I thank you sir!

> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 

Re: What to do with all of the USB UHCI drivers in the kernel ?

[Maksim (Max) Krasnyanskiy]

At 10:06 PM 5/21/2002 -0700, Greg KH wrote:
> > On a side note. Why are URBs still not SLABified ?
> > Drivers still have those silly urb pools and stuff. I thought you guys 
> were
> > gonna fix that.
>
>It hasn't been proven that it's really needed.  95% of the current
>drivers create their urbs when the device is plugged in, and then free
>them when they are removed.  Making that kind of allocation into a slab
>is a bit silly :)
Well, I'm claiming that those drivers are wrong ;)
It makes sense to pre-allocate intr in, iso and bulk in URB. But (imo) it 
doesn't make much sense
to pre-allocate ctrl and bulk out. For example one might never send stuff 
out of USB serial port,
because it used only for logging or something, ut write_urb will always be 
allocated. Same
goes for ctrl, one sends ctrl requests only once in a while but URB is 
always allocated.

Also as Dave pointed out kmalloc is already slabified anyway. And as I 
mentioned kmalloc
has fixed size slabs and therefor will waste some memory.

>Now if more drivers start doing fun stuff like the visor.c driver does
>in the 2.5 tree, then it might make more sense to create a URB specific
>slab.
Some drivers are still maintaining bulk URB pools which is just unnecessary 
code and mem waste.
They should allocate/free bulk urbs on demand.
visor, usbnet, hci_usb and some other driver allocate URB on demand.

I guess the reason for having driver specific URB pools is because 
usb_alloc_urb (using kmalloc) was
slow. Now if it's replaced with slab cache it's no longer the case. So 
drivers should not pre-allocate
stuff unnecessary.

It definitely doesn't hurt to have URB specific cache. You get better stats 
(like URB slab utilization, etc).
You could chose to do slab poisoning and debug URB allocations and stuff. 
You could use slab constructor
to pre-initialize some URB fields.

Max

Re: What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

On Wed, May 22, 2002 at 03:35:48PM -0400, Andre Bonin wrote:
> >This is probably because you have an OHCI hardware device, not a UHCI
> >device.  What does 'lspci -v' say for your machine?
> 
> Sorry, i'me not too familiar with the USB architecture.  Anyway here is 
> the relevant lspci entries (note: I did this under my working 2.4.18)
> 
> 02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
>         Subsystem: Unknown device 807d:0035
>         Flags: bus master, medium devsel, latency 32, IRQ 19
>         Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
> 
> 02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
>         Subsystem: Unknown device 807d:0035
>         Flags: bus master, medium devsel, latency 32, IRQ 16
>         Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
> 
> 02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
>         Subsystem: Unknown device 807d:1043
>         Flags: bus master, medium devsel, latency 32, IRQ 17
>         Memory at cc000000 (32-bit, non-prefetchable) [size=256]
>         Capabilities: [40] Power Management version 2

You only have EHCI and OHCI hardware.  No wonder the UHCI drivers do not
work :)

> >And how does 2.5.17 work for you?
> 
> Not too good beacuse I don't have the option of enabling OHCI :)  Are we 
> still keeping it?

Yes, use the ohci-hcd driver.  Also you can use the ehci-hcd driver if
you have any USB 2.0 devices, as it looks like you have a USB 2.0
controller.

thanks,

greg k-h

Re: What to do with all of the USB UHCI drivers in the kernel?

[Martin Dalecki]

Uz.ytkownik Greg KH napisa?:
> On Wed, May 22, 2002 at 03:35:48PM -0400, Andre Bonin wrote:
> 
>>>This is probably because you have an OHCI hardware device, not a UHCI
>>>device.  What does 'lspci -v' say for your machine?
>>
>>Sorry, i'me not too familiar with the USB architecture.  Anyway here is 
>>the relevant lspci entries (note: I did this under my working 2.4.18)
>>
>>02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
>>        Subsystem: Unknown device 807d:0035
>>        Flags: bus master, medium devsel, latency 32, IRQ 19
>>        Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
>>        Capabilities: [40] Power Management version 2
>>
>>02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
>>        Subsystem: Unknown device 807d:0035
>>        Flags: bus master, medium devsel, latency 32, IRQ 16
>>        Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
>>        Capabilities: [40] Power Management version 2
>>
>>02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
>>        Subsystem: Unknown device 807d:1043
>>        Flags: bus master, medium devsel, latency 32, IRQ 17
>>        Memory at cc000000 (32-bit, non-prefetchable) [size=256]
>>        Capabilities: [40] Power Management version 2
> 
> 
> You only have EHCI and OHCI hardware.  No wonder the UHCI drivers do not
> work :)
> 
> 
>>>And how does 2.5.17 work for you?
>>
>>Not too good beacuse I don't have the option of enabling OHCI :)  Are we 
>>still keeping it?
> 
> 
> Yes, use the ohci-hcd driver.  Also you can use the ehci-hcd driver if
> you have any USB 2.0 devices, as it looks like you have a USB 2.0
> controller.


Could you please just do me a small favour and drop something
in to linux/Documentation. Becouse I'm right now already confused
about which driver to use and which alias to put in /etc/modules.conf
so kudzu stops hollering about not knowing what to do
if I out of a sudden reboot in to 2.5.xx kernel.

Many thank's in advance.

PS. I could of course figure it out of my self, but since
I don't attach anything to USB on my box *that* frequently.

Re: What to do with all of the USB UHCI drivers in the kernel?

[Peter Osterlund]

Greg KH <greg@kroah.com> writes:

>   From now until July 1, I want everyone to test out both the uhci-hcd
>   and usb-uhci-hcd drivers on just about every piece of hardware they
>   can find.

I need this patch to convince the Makefile to build the new drivers.

--- linux/drivers/usb/Makefile.orig	Thu May 23 19:37:56 2002
+++ linux/drivers/usb/Makefile	Thu May 23 19:32:44 2002
@@ -12,6 +12,8 @@
 subdir-$(CONFIG_USB_EHCI_HCD)	+= host
 subdir-$(CONFIG_USB_OHCI_HCD)	+= host
 subdir-$(CONFIG_USB_OHCI)	+= host
+subdir-$(CONFIG_USB_UHCI_HCD)	+= host
+subdir-$(CONFIG_USB_UHCI_HCD_ALT)	+= host
 subdir-$(CONFIG_USB_UHCI_ALT)	+= host
 subdir-$(CONFIG_USB_UHCI)	+= host
 
-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

On Thu, May 23, 2002 at 07:41:22PM +0200, Peter Osterlund wrote:
> Greg KH <greg@kroah.com> writes:
> 
> >   From now until July 1, I want everyone to test out both the uhci-hcd
> >   and usb-uhci-hcd drivers on just about every piece of hardware they
> >   can find.
> 
> I need this patch to convince the Makefile to build the new drivers.

Already in Linus' tree, and will show up in 2.5.18.

thanks,

greg k-h

Re: What to do with all of the USB UHCI drivers in the kernel?

[Peter Osterlund]

Greg KH <greg@kroah.com> writes:

>   Let me (and the linux-usb-devel list) know about any thoughts you have
>   pertaining to liking one of the drivers over the other one.  Speed
>   tests, size tests, code pretty tests, comment spelling tests,
>   documentation tests, you name it, I want to know about it.  If you
>   don't want your comments to be public, send them to me directly and I
>   will not let anyone else know what you said, but will use the info to
>   try to pick which one should stay.

I did a simple test reading a bunch of files from a Freecom CDRW
drive.

usb-uhci-hcd           17840   0 (unused)

        pengo:/cdrw$ time wc petero/mp3/madonna/*
        ...
         188462 1091976 50386286 total

        real    1m24.930s
        user    0m10.440s
        sys     0m1.360s

uhci-hcd               24608   0 (unused)

        pengo:/cdrw$ time wc petero/mp3/madonna/*
        ...
         188462 1091976 50386286 total

        real    1m33.095s
        user    0m12.670s
        sys     0m11.870s

So the usb-uhci-hcd driver is 27% smaller, gives a 10% higher transfer
rate and produces less system load during the data transfers. (About
70% idle time versus 50% idle time on my 233MHz MMX system.)

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: What to do with all of the USB UHCI drivers in the kernel?

[Pierre Rousselet]

Greg KH wrote:
 >   From now until July 1, I want everyone to test out both the uhci-hcd
 >   and usb-uhci-hcd drivers on just about every piece of hardware they
 >   can find.  This includes SMP, UP, preempt kernels, big and little
 >   endian machines, and loads of different types of USB devices.

2.5.17, USB onboard Abit BE6, modem ADSL Speedtouch USB :

1) uhci without loading the modem driver :
# modprobe uhci
# rmmod uhci
OOPS (not logged)
kernel: kmem_cache_destroy: Can't free all objects cff416f8
kernel: uhci: not all urb_priv's were freed

2) usb-uhci uhci-hcd usb-uhci-hcd produce no visible difference in the
operation of the modem (62 kbytes/s for 608 kbits/s connexion speed).


Pierre
-- 
------------------------------------------------
   Pierre Rousselet <pierre.rousselet@wanadoo.fr>
------------------------------------------------