Merge with 2.4.0-test11.

3 files changed, 176 insertions, 41 deletions

diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt
new file mode 100644
index 000000000..a526ffc67
--- /dev/null
+++ b/Documentation/usb/hotplug.txt
@@ -0,0 +1,124 @@
+USB HOTPLUGGING
+
+In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
+into the bus with power on.  In most cases, users expect the devices to become
+immediately usable.  That means the system must do many things, including:
+
+    - Find a driver that can handle the device.  That may involve
+      loading a kernel module; newer drivers can use modutils to
+      publish their device (and class) support to user utilities.
+
+    - Bind a driver to that device.  That's done using the USB
+      device driver's probe() routine.
+    
+    - Tell other subsystems to configure the new device.  Print
+      queues may need to be enabled, networks brought up, disk
+      partitions mounted, and so on.  In some cases these will
+      be driver-specific actions.
+
+This involves a mix of kernel mode and user mode actions.  Making devices
+be immediately usable means that any user mode actions can't wait for an
+administrator to do them:  the kernel must trigger them, either passively
+(triggering some monitoring daemon to invoke a helper program) or
+actively (calling such a user mode helper program directly).
+
+Those triggered actions must support a system's administrative policies;
+such programs are called "policy agents" here.  Typically they involve
+shell scripts that dispatch to more familiar administration tools.
+
+
+KERNEL HOTPLUG HELPER (/sbin/hotplug)
+
+When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
+/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
+That parameter names a program which the kernel may invoke at various times.
+
+The /sbin/hotplug program can be invoked by any subsystem as part of its
+reaction to a configuration change, from a thread in that subsystem.
+Only one parameter is required: the name of a subsystem being notified of
+some kernel event.  That name is used as the first key for further event
+dispatch; any other argument and environment parameters are specified by
+the subsystem making that invocation.
+
+A reference implementation of a /sbin/hotplug script is available at the
+http://www.linux-usb.org website, which works USB for but also knows how to
+delegate to any /etc/hotplug/$TYPE.agent policy agent present.
+
+
+USB POLICY AGENT
+
+The USB subsystem currently invokes /sbin/hotplug when USB devices
+are added or removed from system.  The invocation is done by the kernel
+hub daemon thread [khubd], or else as part of root hub initialization
+(done by init, modprobe, kapmd, etc).  Its single command line parameter
+is the string "usb", and it passes these environment variables:
+
+    ACTION ... "add", "remove"
+    PRODUCT ... USB vendor, product, and version codes (hex)
+    TYPE ... device class codes (decimal)
+    INTERFACE ... interface 0 class codes (decimal)
+
+If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is
+the pathname of the device, and is useful for devices with multiple and/or
+alternate interfaces that complicate driver selection.
+
+Currently available policy agent implementations can load drivers for
+modules, and can invoke driver-specific setup scripts.  The newest ones
+leverage USB modutils support.  Later agents might unload drivers.
+
+
+USB MODUTILS SUPPORT
+
+Current versions of modutils will create a "modules.usbmap" file which
+contains the entries from each driver's MODULE_DEVICE_TABLE.  Such files
+can be used by various user mode policy agents to make sure all the right
+driver modules get loaded, either at boot time or later. 
+
+See <linux/usb.h> for full information about such table entries; or look
+at existing drivers.  Each table entry describes one or more criteria to
+be used when matching a driver to a device or class of devices.
+
+A short example, for a driver that supports several specific USB devices
+and their quirks, might have a MODULE_DEVICE_TABLE like this:
+
+    static const struct usb_device_id mydriver_id_table = {
+	{ idVendor: 0x9999, idProduct 0xaaaa, driver_info: QUIRK_X },
+	{ idVendor: 0xbbbb, idProduct 0x8888, driver_info: QUIRK_Y|QUIRK_Z },
+	...
+	{ } /* end with an all-zeroes entry */
+    }
+    MODULE_DEVICE_TABLE (usb, mydriver_id_table);
+
+Most USB device drivers should pass these tables to the USB subsystem as
+well as to the module management subsystem.  Not all, though: some driver
+frameworks connect using interfaces layered over USB, and so they won't
+need such a "struct usb_driver".
+
+Drivers that connect directly to the USB subsystem should be declared
+something like this:
+
+    static struct usb_driver mydriver = {
+	name:		"mydriver",
+	id_table:	mydriver_id_table,
+	probe:		my_probe,
+	disconnect:	my_disconnect,
+
+	/*
+	if using the usb chardev framework:
+	    minor:		MY_USB_MINOR_START,
+	    fops:		my_file_ops,
+	if exposing any operations through usbdevfs:
+	    ioctl:		my_ioctl,
+	*/
+    }
+
+When the USB subsystem knows about a driver's device ID table, it's used when
+choosing drivers to probe().  The thread doing new device processing checks
+drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
+device descriptors for the device.  It will only call probe() if there is a
+match, and the third argument to probe() will be the entry that matched.
+
+If you don't provide an id_table for your driver, then your driver may get
+probed for each new device; the third parameter to probe() will be null.
+
+
diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt
index 304a1ec90..bc9cad2ab 100644
--- a/Documentation/usb/ov511.txt
+++ b/Documentation/usb/ov511.txt
@@ -5,22 +5,17 @@ Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
 Author: Mark McClelland
 Homepage: http://alpha.dyndns.org/ov511
 
-NEW IN THIS VERSION:
- o Stability improvements
- o Support for hue control
- o 160x120 mostly working
- o OV6620 color problems fixed
- o More WebCam 3 detection improvements
-
 INTRODUCTION:
 
 This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
 Any camera using the OV511/OV511+ and the OV7610/20/20AE CCD should work. It 
 supports streaming and capture of color or monochrome video via the Video4Linux
-API. Most V4L apps are compatible with it, but a few videoconferencing programs
+API. Most V4L apps are compatible with it, but a few video-conferencing programs
 do not work yet. The following resolutions are supported: 640x480, 448x336,
 384x288, 352x288, and 320x240.
 
+If you need more information, please visit the OV511 homepage at the above URL.
+
 WHAT YOU NEED:
 
 - If you want to help with the development, get the chip's specification docs at
@@ -81,29 +76,6 @@ Now you should be able to run xawtv. Right click for the options dialog. If
 you get a scrambled image it is likely that you made a mistake in Xawtv.ad.
 Try setting the size to 320x240 if all else fails.
 
-FAQ:
-Q: "Why does the picture have noise and look grainy"
-A: This is a problem at low light levels, and may be also due to subtle bugs in
-   the code. The cause is most likely the OV7610 settings we are currently
-   using. I am looking into this problem.
-
-Q: "The driver sometimes says `Failed to read OV7610 ID.' What is the deal?"
-A: The I2C code that allows the OV511 to communicate with the camera chip is a
-   bit flaky right now. This message means that the I2C bus never got
-   initialized properly, and the camera will most likely not work even if you
-   disable this warning. Try unloading/reloading the driver or unplugging/re-
-   plugging the camera if this happens. Also try increasing the i2c_detect_tries
-   parameter (see below).
-
-Q: "Why do you bother with this phony camera detection crap? It doesn't do
-    anything useful!"
-A: The main purpose of only supporting known camera models is to force people
-   with new camera models to tell me about them, so I can assemble the list
-   above, and so the code can know what CCD chip you have. Right now, nearly all
-   of the cameras use the OV7610 and consequently I have not put support for
-   other ones in, so the value of the detection code is questionable. Eventually
-   though, new CCDs might appear and we will be fortunate to have the detection.
-
 MODULE PARAMETERS:
 
   You can set these with:  insmod ov511 NAME=VALUE
@@ -136,7 +108,7 @@ MODULE PARAMETERS:
         or so lines higher than the red component. This is only apparent in 
         images with white objects on black backgrounds at 640x480. Setting this
         to 1 will realign the color planes correctly. NOTE: This is still
-        experimental and very buggy. You will likely need a fast (500 Mhz) CPU.
+        experimental and very buggy. You will likely need a fast (500 MHz) CPU.
 
   NAME: snapshot
   TYPE: integer (boolean)
@@ -203,15 +175,21 @@ MODULE PARAMETERS:
   DESC: Prevent apps from timing out if frame is not done in time. This is
         useful if you are having problems with Xawtv getting "stuck" on a frame
         when your system is under heavy load.
- 
+
+  NAME: sensor_gbr
+  TYPE: boolean
+  DEFAULT: 0
+  DESC: This makes the sensor output GBR422 instead of YUV420. This saves the
+        driver the trouble of converting YUV to RGB, but it currently does not
+        work very well (the colors are not quite right)
+
 WORKING FEATURES:
- o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, 320x240, and
-   160x120
- o RGB24, YUV420, YUV422, YUYV, and YUV422P color
+ o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, and 320x240
+ o RGB24, RGB565, YUV420, YUV422, YUYV, and YUV422P color
  o Monochrome
  o Setting/getting of saturation, contrast, brightness, and hue (only some of
    them work the OV7620 and OV7620AE)
- o proc status reporting
+ o /proc status reporting
 
 EXPERIMENTAL FEATURES:
  o fix_rgb_offset: Sometimes works, but other times causes errors with xawtv and
@@ -219,6 +197,7 @@ EXPERIMENTAL FEATURES:
  o Snapshot mode (only works with some read() based apps; see below for more)
  o OV6620 sensor support
  o GBR422 parsing
+ o 160x120
 
 TODO:
  o Fix the noise / grainy image problem.
@@ -227,18 +206,19 @@ TODO:
    so we can't really work on that yet. Please kindly inform OmniVision that you
    would like them to release their specifications to the Linux community.
  o YUV422
- o Get snapshot mode working with mmap().
  o Fix fixFrameRGBoffset(). It is not stable yet with streaming video.
- o Get autoadjust disable working
  o V4L2 support (Probably not until it goes into the kernel)
- o Creative WebCam III has problems initializing its sensor. This should be
-   fixed now, but if you still have problems let me know.
  o Get rid of the memory management functions (put them in videodev.c??)
  o Setting of contrast and brightness not working with 7620/7620AE
  o Driver/camera state save/restore for when USB supports suspend/resume
  o Unstable on SMP systems
  o OV7620/OV6620 experience frame corruption with moving objects
  o OV6620 is too dark
+ o 176x144 support
+ o Driver sometimes hangs upon close() with OHCI
+ o The image should always be written properly to the mmap'ed buffer as long as
+   the requested image size is at least the minimum size. This will likely
+   require a rewrite of all the parsing code.
 
 HOW TO CONTACT ME:
 
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 4ffe021a7..a6efeefa5 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -151,6 +151,37 @@ Digi AccelePort Driver
   driver.
 
 
+Belkin USB Serial Adapter F5U103
+
+  Single port DB-9/PS-2 serial adapter from Belkin with firmware by eTEK Labs.
+
+Current status:
+  The following have been tested and work:
+    Baud rate    300-230400               
+    Data bits    5-8
+    Stop bits    1-2
+    Parity       N,E,O,M,S
+    Handshake    None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
+    Break        Set and clear
+    Line contrl  Input/Output query and control **
+
+    *  Hardware input flow control is only enabled for firmware
+       levels above 2.06.  Read source code comments describing Belkin
+       firmware errata.  Hardware output flow control is working for all
+       firmware versions.
+    ** Queries of inputs (CTS,DSR,CD,RI) show the last
+       reported state.  Queries of outputs (DTR,RTS) show the last
+       requested state and may not reflect current state as set by
+       automatic hardware flow control.
+
+TO DO List:
+  -- Add true modem contol line query capability.  Currently tracks the
+     states reported by the interrupt and the states requested.
+  -- Add error reporting back to application for UART error conditions.
+  -- Add support for flush ioctls.
+  -- Add everything else that is missing :)
+
+
 Generic Serial driver
 
   If your device is not one of the above listed devices, compatible with