Ou trouver les pilotes USB 2.0 ?? Un petit lien serait le bienvenu

un piti google m'a donné ca :
http://www.linux-usb.org/usb2.html
 
et vi google c'est pratique pour trouver des infos....
pr rappel, google, c sur www.google.fr
 
enfin moa j'dis ca....

merci   mais marche pas le lien, c'est pas grave j'ai trouvé sur clubic merci quand quand même  

komment ca ki marche pas le lien ??!!
ca doit venir de chez toa paske chez moa ca marche nickel

Chez moi aussi ça marche!  
 
Tiens, un ptit copier/colle   :
 
Linux and USB 2.0
David Brownell
<dbrownell@users.sourceforge.net>
 
23 Jul 2002
 
 
This is a short writeup explaining what USB 2.0 changed and what's going on with it in Linux. It starts by talking about user visible changes followed by driver-visible ones. Finally it summarizes the current state of Linux USB 2.0 driver support in recent 2.4 and 2.5 kernels.  
 
You should probably know that "USB" is an abbreviation of the Universal Serial Bus, which is widely used for peripherals in modern desktop systems. (It's not "universal" in the sense that you'd want it instead of HyperTransport!) PCs typically support one or more USB controllers (one per "USB bus" ) each of which can support up to 127 different devices. "Legacy free" PCs omit non-USB peripheral support (like RS-232 serial lines, and PS/2 ports). USB is asymmetric, even at the level of its cabling (so you won't connect things incorrectly), and it supports "hotplugging" for all its peripherals (so you don't have to configure them by hand). Those features both help reduce end-user setup and configuration problems, which was a major goal for the technology.  
 
User-Visible Changes in USB 2.0
Today, most devices and systems support USB version 1.1, which supported two device speeds: low speed at 1.5 Mbit/sec, and full speed at 12 Mbit/sec. USB 2.0 is appearing in current product designs, and one of its main features is adding a new speed: high speed, at 480 Mbit/sec.  
 
To put it another way: USB 1.1 was OK for low speed devices like mice and keyboards, and even for medium speed ones like Ethernet (10 Mbit/sec) adapters, or consumer electronics gadgets that only exchange a few megabytes of data (like many digital still cameras and MP3 players). But you need USB 2.0 to get reasonable speed for multiple large transfers as with some PC peripherals like disk drives (including MP3 jukeboxes or high resolution webcams (USB video).  
 
OK, it's faster! ... but what else will a Linux user notice about USB 2.0? We'll go from the outside in: starting from what you'll see with product boxes, and then working toward what you'll see with normal Linux user mode tools. One thing you won't notice is designed-in compatibility problems. Apart from some constraints on how you set up high speed devices, all your USB 1.1 hardware works just fine with USB 2.0 systems.  
 
Updated USB Logos
One thing that you should watch for, and use to your advantage, is a new testing and branding program. Earlier USB devices sometimes had compatibility problems, and the tighter electrical requirements of USB 2.0 could have aggravated that issue. Instead, there are new USB 2.0 logos and a testing program that must be passed before devices are allowed to use them.  
 
Here are the new and old USB logos. The USB 2.0 logo may omit the red stripe if the device is certified for USB 2.0 support but not at high speed:
 
 New USB 2.0 Logo
(high speed version)  
 Old USB 1.1 Logo (no compatibility testing done)  
 
Be cautious about "high speed" devices that for any reason don't display that new logo. Those devices may not work very well, and it'll be your fault for encouraging vendors that sell nonconformant devices. The Linux community can hope that the conformance testing catches more of that annoying bug-compatible with Microsoft firmware, but at least having better testing should be a significant help. That is, this isn't purely a marketing gimmick, there's actually some value wrapped up in this logo.  
 
Hubs and Cabling
One big win for the USB 2.0 upgrade is that cables don't need to change. With the possible exception of some low quality cables that may not even handle USB 1.1 very well, you can keep using your existing USB cables. There was no need to switch to optical signal transmission, or anything similarly incompatible.  
 
USB 2.0 hubs are special. Not only do they support high speed devices (older USB 1.1 hubs can't), but also because they all include "transaction translator" support that helps prevent full and low speed devices from wasting most of the USB bandwidth. See the next section, on backwards compatibility, for how this impacts end users with high speed buses whose devices may not all operate at high speed.  
 
There's also a standard for how hub indicator LEDs work. Basically they can light up in two colors (amber and green), and will be used in standard ways to indicate status even when the hub isn't operating at high speed. Green indicates everything's fine, and amber indicates an error (like "too much current drawn on this port" ). A blinking indicator highlights a given port, for use with specialized diagnostic procedures. The Linux kernel doesn't currently use these LEDs except in an automatic mode, but tools could be written to use them.  
 
USB 2.0 defines a "mini-B" connector standard, which is much smaller than the standard B type connector. (The "B" connectors go downstream toward devices, and they're squarish. Your PC host supports several rectangular "A" connectors, which always go upstream to hubs or hosts.) I've not seen any of these yet, but I'll hope that they start to replace the expensive proprietary cables used in many of the more expensive USB devices, such as higher end still cameras, even for devices that don't need high speed support.  
 
There is also an evolution of USB 2.0 called USB "On The Go" (OTG) which supports some point-to-point peer style hookups, like a digital camera or PDA connecting to a USB printer, for devices (maybe portable) that are often used without a PC. That won't be discussed here, in part because USB OTG products don't exist yet. They're expected to start appearing later this year.  
 
Host Controllers and Backwards Compatibility
You can connect USB 2.0 devices to USB 1.1 hosts and hubs, and they should work just fine ... but at 12 Mbit/sec, not at 480 Mbit/sec.  
 
To get "high speed" behavior you'll need an updated host controller. It must support "USB 2.0 high speed", through the "EHCI" standard. Today you can get those as PCI cards (usually with a five port controller from NEC), and motherboards are starting to appear with such controllers built in. I've seen both NEC and VIA controllers on such motherboards, and PCI cards with controllers from NEC, Philips, and VIA. In summer 2002 you should expect to see generations of motherboards that include such support directly in their "south bridge", with chipsets from vendors such as ALI, ATI, Intel, NVidia, SiS, and VIA. (That's in alphabetical order; I'm not intending to slight any vendors.)  
 
You may also need newer hubs with USB 2.0 support. Probably the most important aspect of such hubs is how they support trees of devices that mix both high speed and full (or low) speed devices. The short version of the story is that to get high speed transfers out of a high-speed capable device, you must hook it up through an EHCI controller (that's using an EHCI driver!), and any hubs between the host and the device must only be USB 2.0 hubs.  
 
That is, a tree of USB devices can start out with a high speed root hub, but if you plug in any USB 1.1 hubs to that tree, USB devices on branches below that hub will only operate at slower full/low (USB 1.1) speeds ... even if it's a USB 2.0 device. Linux might someday warn you when you cable things in a sub-optimal way. (Maybe a blinking green LED, if you happen do use a new hub to do it?) For now the lesson is that if you want to use a device at high speed, double check it after cabling things up. You can do this with "usbfs".  
 
"usbfs" and /proc/bus/usb/devices
You may know "usbfs" through its original, and somewhat confusing name, of "usbdevfs". The name changed because it was completely unrelated to "devfs".  
 
If you use "usbfs" (perhaps through scripts like usbtree or tools like usbview) you will notice a few minor changes. Most notably, the USB version for some devices will be "2.0", and those devices will report their speed as "480Mb/s" when they're running at high speed. (In compatibility mode, at full speed, they'll say "12Mb/s".) Some of the endpoint descriptors may change. Maximum packet sizes can be bigger, and polling intervals for periodic transfers will sometimes be measured in microseconds (like 250us), not milliseconds (like 2ms), and you may even see NAK rates for bulk endpoints. For example, this descriptor is for one USB 2.0 CD-RW when it's running at high speed:  
 
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05ab ProdID=0060 Rev= 2.10
S:  Manufacturer=In-System Design
S:  Product=USB Storage Adapter
S:  SerialNumber=2201010A0247C8AB
C:* #Ifs= 1 Cfg#= 2 Atr=c0 MxPwr= 98mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   2 Ivl=32ms
 
 
Here's the descriptor for the same CD-RW when there's no EHCI driver, so it's running at full speed (probably not a good idea to burn CDs at this speed though):  
 
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05ab ProdID=0060 Rev= 2.10
S:  Manufacturer=In-System Design
S:  Product=USB Storage Adapter
S:  SerialNumber=2201010A0247C8AB
C:* #Ifs= 1 Cfg#= 2 Atr=c0 MxPwr= 98mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   2 Ivl=32ms
 
 
Other than that "480Mb/s" speed rating, most of that per-device usbfs information will only be interesting to folk working with device drivers. That "480Mb/s" in the descriptor for your device will be a sign that you've cabled it up correctly (so it runs at high speed). But there are also differences you may notice if you look at the root hub support for each of your systems USB busses.  
 
USB 1.1 "Companion Controllers"
Perhaps the most curious thing is that when you plug in a full (or low) speed device to a connector on your high speed USB controller, it will be connecting to a different bus than when you plug in a high speed device to that same USB "A" socket on your PC! In the CD-RW example above, the bus number changed. Sometimes the port number will also change. (OK, so maybe you wouldn't have noticed.)  
 
That's because of how the controllers work. Here's how /proc/bus/usb/devices looks on one system with a five port NEC EHCI based controller, and nothing hooked up to it. I added some whitespace and highlighting so you can see what's going on a bit better:  
 
T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.05
S:  Manufacturer=Linux 2.5.8 ohci-hcd
S:  Product=NEC Corporation USB
S:  SerialNumber=00:0b.0
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
 
T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.05
S:  Manufacturer=Linux 2.5.8 ohci-hcd
S:  Product=NEC Corporation USB (#2)
S:  SerialNumber=00:0b.1
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
 
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 5
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.05
S:  Manufacturer=Linux 2.5.8 ehci-hcd
S:  Product=NEC Corporation USB 2.0
S:  SerialNumber=00:0b.2
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms
 
 
Yes, three USB buses on one controller card! (The PCI card is 00:0b but each bus has a different PCI function number.) And it looks like there's a total of ten ports (sum the "MxCh" entries saying how many ports the root hubs have), not five ... how can that be?  
 
The answer is that the two OHCI "companion controllers" are used along with the EHCI controller, and a silicon switch connects each port to only one controller at a time. When an EHCI driver runs, all ports start out connected to EHCI. When EHCI detects a full or low speed device on a port, that port is switched over to one of the companion controllers. High speed devices it keeps for itself ... so each port seems to connect to either EHCI or its companion controller (never both!) based on whether it runs at high speed or not. If there's no EHCI driver there to handle high speed devices, then everything gets treated as full or low speed since the switch won't connect things to the EHCI controller. (Companion controllers won't necessarily be OHCI; some are UHCI.)  
 
So to fully use a USB 2.0 host controller you must still use an OHCI or UHCI host controller driver, as you've likely been doing already. And if that's the only driver you have, you can still use hardware that includes USB 2.0 support ... it just won't be as fast until you upgrade to an OS version with USB 2.0 support. In the big picture that's a great migration story for the core USB 2.0 technology: the hardware can upgrade, and the software follows later when it's convenient for end users. (Much like most vendors' stories for migrating from one generation of CPU, or instruction set, to the next one.)  
 
Driver-Visible Changes in USB 2.0
The most visible change was the addition of "high speed" devices and transfers. In a Linux USB device driver, you can tell if the device is high speed (and thus whether its transfers will be at high speed!) by testing whether dev->speed == USB_SPEED_HIGH.  
 
The rules for full and low speed transfers have not changed, but some rules changed for high speed transfers. (You may have noticed some of those changes when comparing the high speed and full speed usbfs information shown above for the CD-RW.) In a few cases drivers need to have code that knows which rules apply, but mostly the changes will be transparent to correctly written drivers. Those changes include:  
 
Maximum packet sizes for control transfers are fixed at 64 bytes, and for bulk transfers they are fixed at 512 bytes. For full and low speed, those limits are smaller and can also vary between devices.  
Maximum packet sizes for interrupt transfers can now be up to 1024 bytes. (For full and low speed, those limits are much smaller.) Likewise for ISO transfers (which previously had a curious 1023 byte limit).  
There are now eight "microframes" per frame. A useful number to keep in mind is that thirteen bulk packets of 512 bytes each can be exchanged in one microframe. (At full speed, nineteen bulk packets of 64 packets could be exchanged in one frame. High speed transfers can be more than forty times faster than full speed ones!)  
Periodic transfers can only reserve up to eighty percent of the USB bandwidth (per microframe). In USB 1.1, up to ninety percent was available.  
Periodic transfer periods are measured in microframes, not frames. Both ISO and interrupt transfer intervals now use a log2 encoding, where previously only ISO transfers used that encoding. (Interrupt transfers can now have larger or smaller periods.) Drivers will need to interpret endpoint->bInterval differently for high speed devices, and also set urb->interval accordingly.  
Periodic transfers can support a "high bandwidth" mode, where up to 3 packets (3KB at most) per microframe can be transferred. This shows up in a new field in endpoint descriptors. Drivers will need to interpret usb_maxpacket() differently for high speed, since that holds the new bit field as well as the original one. (With USB 1.1 devices, periodic transfers only involve one packet each period.)  
EHCI provides less detailed error indicators than OHCI or UHCI. This means that drivers for USB 1.1 devices should retest for good behavior while connecting through a transaction translator in a USB 2.0 hub. Try things like unplugging devices while they're actively in use. It's likely they'll see EPIPE (endpoint stall) errors in some cases where previously they saw ETIMEDOUT (ohci) or EILSEQ (uhci). Unlike true endpoint stalls, usb_clear_halt() won't be able to talk to the device. (Your driver does have code to recover correctly from halted endpoints, doesn't it? It should!)  
There are also protocol changes that should be invisible to most device drivers ... except in some cases for the host or device controller drivers, or the hub driver:  
 
There's a new "other speed configuration" descriptor for devices that can work at both full and high speed. When a device is working at full speed, it would usually have different descriptors for high speed operation ... see the CD-RW example above. You don't need to re-enumerate at the other speed to see those descriptors.  
"Split transactions" use a new feature of USB 2.0 hubs, the "transaction translator, which makes more efficient use of USB bandwidth. (All transactions run at high speed. Hubs build in buffering and logic for full or low speed speed operations.)  
NYET transactions on the wire, used to detect that split transactions are not yet complete.  
PING transactions on the wire help flow control to high speed bulk or control endpoints.  
DATA2 and MDATA transactions on the wire are used with isochronous transfers.  
The hub descriptor defines a few new fields, and uses the protocol number to say whether each port has its own transaction translator.  
When Linux start to be embedded more widely inside USB devices (not just USB hosts) the USB "function" or "target" drivers will need a new kind of USB programming interface. That will also support USB 2.0; higher speed targets will benefit from the capabilities of Linux more than most USB 1.1 targets (even including Linux-based PDAs). The current Linux-USB programming interface has a host side model: one master talking to many targets (like a web client talking to many servers). A new target side model is in the works, for the 2.5 series. While it should resemble the current programming interfaces (at least in terms of submitting URBs) it must treat USB busses very differently from a host side API. That's because implementing the target function only involves talking to a single USB Host (like a web server only responding to one client at a time). Also, target side drivers can never initiate control requests, they can only respond to them.  
 
Linux Driver Support
People have been using USB 2.0 with usb-storage devices from Linux hosts since June 2001, but it was only in early winter of that year (a short while before Linus created the 2.5 development branch) that other USB 2.0 devices (notably, hubs) began to be available. So while some changes for USB 2.0 were rolling into 2.4 kernels through the year 2001, most of the tricky stuff (the ehci-hcd driver) was separate until the 2.5 kernel branched. Recently, some Linux distributions have begun to include this support.  
 
Host Controller Driver Support
At this writing the "ehci-hcd" driver is not as well proven as the OHCI or UHCI drivers, so it's still labeled experimental, but it's just fine for many purposes.  
 
The Linux 2.5 kernel has the most up-to-date USB 2.0 support, as well as quite a number of other USB updates and cleanups. (At this writing 2.5.14 is the current version.) There could be a general backport of this USB stack later on, to the 2.4 tree.  
The 2.4.19 kernel is the first to bundle a 2.4 based version of the ehci-hcd driver. Expect that 2.4 version to be less current than the 2.5 version, though fixes for any significant bugs should be in both versions.  
Recent Linux distributions (like RedHat or Mandrake) include a version that's less up-to-date than the current 2.4 version.  
In terms of functionality, the latest driver:  
 
Supports all four USB transfer types at high speed: control, bulk, interrupt, and isochronous. However, scheduling for interrupt transfers currently takes shortcuts which prevent them from using much bandwidth. (Or handling many devices.)  
Has partial support for split transactions (full and low speed transfers) through USB 2.0 hubs:  
Control and bulk transfers work, except that the hub driver doesn't know how to recover some kinds of error. (Unless you're using the very latest code.) That means: that while you should be able to use many USB 1.1 devices like disks and still cameras through such hubs, you might also run into some failure modes that can't yet be recovered. (And some device drivers might also need updates to handle new failure modes, as noted above.)  
Full and low speed interrupt transactions work, taking the same scheduling shortcuts as high speed interrupt transfers take. So most keyboards and mice should work on USB 2.0 hubs, if you're using one of the most recent kernels.  
You can't use full speed isochronous transfers through USB 2.0 hubs. That means: don't hook up USB 1.1 webcams, speakers, etc. to high speed buses, they'll enumerate but you won't be able to use them otherwise.  
Only the newest kernels support BIOS handshaking (transferring "ownership" of EHCI from BIOS/SMM to Linux, as is done for OHCI or UHCI). That's because it depends on EHCI hardware features that are not yet generally available, used by BIOS implementations that talk to EHCI controllers integrated on motherboard "South Bridge" chipsets.  
Works with a variety of EHCI silicon implementations. NEC led the market by over a year, but now implementations from Intel (ICH4), Philips and VIA also work with that driver. Other implementations (ALI, ATI, SiS, ...) are anticipated to work without needing significant changes.  
You'll find that most PCI USB 2.0 add-in cards (and CardBus/PCMCIA ones) use the NEC silicon. (Some of those will likely start to use an updated version that NEC recently announced. It's faster, and supports the final "1.0" version of the EHCI spec.) Some folk have problems with the CardBus versions, because Linux hasn't always managed to get the IRQs assigned correctly on their particular laptop make/model. Once such BIOS/PCI level problems get resolved, the ehci-hcd driver works with those CardBus configurations too.  
 
See the linux/Documentation/usb/ehci.txt file in your Linux kernel source distribution for some more information. As always with drivers still in development, if you have any problems, try the latest code (preferably in the 2.5 kernel, otherwise in the latest 2.4 code) to see if the problem has been fixed yet. And if not, report problems to the linux-usb-devel mailing list.  
 
Device Driver Support
Storage devices, and to some extent hubs, seem to be all that most folk need so far, but high speed scanners and printers ought to be in the works too.  
 
Device Driver Comments  
USB 2.0 hubs hub (usbcore) USB 2.0 hubs work, but haven't been widely stressed (especially in terms of faults happening during transaction translation).  
Disks, CD-RW, etc usb-storage Linux USB 2.0 support seems to work pretty well for the usb-storage devices that now exist, though it's slowed down since the usb-storage driver does not queue its USB requests. (Some devices will run twice as fast when that's fixed.) Most devices seem to use the In-System Design ISD-300 part internally.  
Archos MP3 Jukebox usb-storage Needs a tweak to usb-storage error handling, or a workaround: start the Archos and let it boot up before you load or hotplug the usb-storage module..  
Orange iBOT2 WebCam none yet... here's your chance! This is the first USB 2.0 webcam announced, and with that video rate it's surely begging for a Linux driver ...  
Cypress EZ-USB FX2 custom These are 8051 microcontrollers with support for high speed transfers, designed for use inside USB devices and with custom firmware. The fxload software lets you download that firmware. For the start of one interesting Linux-based example (hosted at sf.net), see the SR-1 software radio.  
 
Regardless of what type of high speed device you use, USB hotplugging works the same as it always has on Linux.  
 
References
http://www.linux-usb.org ... for all the Linux-USB info.  
http://www.usb.org/developers/docs.html ... for USB 2.0 information, including specifications for USB 2.0  
For host controller interfaces, most systems connect to USB through PCI and obey one of these three specifications:
http://developer.intel.com/technology/usb/ehcispec.htm ... Intel; EHCI 1.0 specification (for high speed and USB 2.0)  
http://www.compaq.com/productinfo/ [...] enhci.html ... Compaq, Microsoft, and National Semiconductor; OHCI 1.0a specification (for full/low speed and USB 1.1)  
http://developer.intel.com/design/USB/UHCI11D.htm ... Intel; UHCI 1.1D specification (for full/low speed and USB 1.1)  
http://www.kernel.org ... get yourself a USB 2.0 enabled Linux kernel!  
http://linux-hotplug.sourceforge.net ... if you're working with Linux to support USB 2.0 devices based on Cypress FX2 microcontrollers, use fxload to download your USB device firmware.  

 
ya meme www.google.fr/linux !
 

tu prends la dernière version du kernel 2.4.19 et tu recompiles ton kernel en activant le support ehci (ou un truc comme ça) dans la conf de l'usb et ça roule pour l'usb en théorie

 
Non. Google c'est sur http://www.google.com
google.fr c'est pour les petits frenchies anglophobes
 
 

heu google.fr te sorts pas forcément que des pages en français...