summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-12-08 08:12:16 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2009-12-08 08:12:16 -0800
commit41440ffe21f29bdb985cab76b2d0b06d83e63b19 (patch)
tree1d7d1ff6f699ccbabb71c7bc4172f7d15bc4bc45 /Documentation
parentdad3de7d0090280f44ff27131ed2878f1ab6ddad (diff)
parent6471b68982d3bb1a593c3e183c804ecf830125d3 (diff)
downloadlinux-41440ffe21f29bdb985cab76b2d0b06d83e63b19.tar.bz2
Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: i2c-stub: Documentation update i2c-stub: Allow user to disable some commands i2c-stub: Implement I2C block support i2c: Refactor for_each callbacks i2c-i801: Retry on lost arbitration i2c: Remove big kernel lock from i2cdev_open ics932s401: Clean up detect function i2c: Simplify i2c_detect_address i2c: Drop probe, ignore and force module parameters i2c: Add missing __devinit markers to old i2c adapter drivers i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDR i2c: Prevent priority inversion on top of bus lock i2c-voodoo3: Delete i2c-powermac: Drop temporary name buffer i2c-powermac: Include the i2c_adapter in struct pmac_i2c_bus i2c-powermac: Log errors i2c-powermac: Refactor i2c_powermac_smbus_xfer i2c-powermac: Reject unsupported I2C transactions i2c/chips: Move ds1682 to drivers/misc
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/feature-removal-schedule.txt9
-rw-r--r--Documentation/i2c/busses/i2c-voodoo362
-rw-r--r--Documentation/i2c/i2c-stub16
-rw-r--r--Documentation/i2c/old-module-parameters44
4 files changed, 55 insertions, 76 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index a004b04ffd3a..591e94448e63 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -407,15 +407,6 @@ Who: Alex Chiang <achiang@hp.com>
---------------------------
-What: i2c-voodoo3 driver
-When: October 2009
-Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
- driver but this caused driver conflicts.
-Who: Jean Delvare <khali@linux-fr.org>
- Krzysztof Helt <krzysztof.h1@wp.pl>
-
----------------------------
-
What: CONFIG_RFKILL_INPUT
When: 2.6.33
Why: Should be implemented in userspace, policy daemon.
diff --git a/Documentation/i2c/busses/i2c-voodoo3 b/Documentation/i2c/busses/i2c-voodoo3
deleted file mode 100644
index 62d90a454d39..000000000000
--- a/Documentation/i2c/busses/i2c-voodoo3
+++ /dev/null
@@ -1,62 +0,0 @@
-Kernel driver i2c-voodoo3
-
-Supported adapters:
- * 3dfx Voodoo3 based cards
- * Voodoo Banshee based cards
-
-Authors:
- Frodo Looijaard <frodol@dds.nl>,
- Philip Edelbrock <phil@netroedge.com>,
- Ralph Metzler <rjkm@thp.uni-koeln.de>,
- Mark D. Studebaker <mdsxyz123@yahoo.com>
-
-Main contact: Philip Edelbrock <phil@netroedge.com>
-
-The code is based upon Ralph's test code (he did the hard stuff ;')
-
-Description
------------
-
-The 3dfx Voodoo3 chip contains two I2C interfaces (aka a I2C 'master' or
-'host').
-
-The first interface is used for DDC (Data Display Channel) which is a
-serial channel through the VGA monitor connector to a DDC-compliant
-monitor. This interface is defined by the Video Electronics Standards
-Association (VESA). The standards are available for purchase at
-http://www.vesa.org .
-
-The second interface is a general-purpose I2C bus. The intent by 3dfx was
-to allow manufacturers to add extra chips to the video card such as a
-TV-out chip such as the BT869 or possibly even I2C based temperature
-sensors like the ADM1021 or LM75.
-
-Stability
----------
-
-Seems to be stable on the test machine, but needs more testing on other
-machines. Simultaneous accesses of the DDC and I2C busses may cause errors.
-
-Supported Devices
------------------
-
-Specifically, this driver was written and tested on the '3dfx Voodoo3 AGP
-3000' which has a tv-out feature (s-video or composite). According to the
-docs and discussions, this code should work for any Voodoo3 based cards as
-well as Voodoo Banshee based cards. The DDC interface has been tested on a
-Voodoo Banshee card.
-
-Issues
-------
-
-Probably many, but it seems to work OK on my system. :')
-
-
-External Device Connection
---------------------------
-
-The digital video input jumpers give availability to the I2C bus.
-Specifically, pins 13 and 25 (bottom row middle, and bottom right-end) are
-the I2C clock and I2C data lines, respectively. +5V and GND are probably
-also easily available making the addition of extra I2C/SMBus devices easy
-to implement.
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index 0d8be1c20c16..fa4b669c166b 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -2,9 +2,9 @@ MODULE: i2c-stub
DESCRIPTION:
-This module is a very simple fake I2C/SMBus driver. It implements four
-types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
-(r/w) word data.
+This module is a very simple fake I2C/SMBus driver. It implements five
+types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
+word data, and (r/w) I2C block data.
You need to provide chip addresses as a module parameter when loading this
driver, which will then only react to SMBus commands to these addresses.
@@ -21,8 +21,8 @@ EEPROMs, among others.
The typical use-case is like this:
1. load this module
- 2. use i2cset (from lm_sensors project) to pre-load some data
- 3. load the target sensors chip driver module
+ 2. use i2cset (from the i2c-tools project) to pre-load some data
+ 3. load the target chip driver module
4. observe its behavior in the kernel log
There's a script named i2c-stub-from-dump in the i2c-tools package which
@@ -33,6 +33,12 @@ PARAMETERS:
int chip_addr[10]:
The SMBus addresses to emulate chips at.
+unsigned long functionality:
+ Functionality override, to disable some commands. See I2C_FUNC_*
+ constants in <linux/i2c.h> for the suitable values. For example,
+ value 0x1f0000 would only enable the quick, byte and byte data
+ commands.
+
CAVEATS:
If your target driver polls some byte or word waiting for it to change, the
diff --git a/Documentation/i2c/old-module-parameters b/Documentation/i2c/old-module-parameters
new file mode 100644
index 000000000000..8e2b629d533c
--- /dev/null
+++ b/Documentation/i2c/old-module-parameters
@@ -0,0 +1,44 @@
+I2C device driver binding control from user-space
+=================================================
+
+Up to kernel 2.6.32, many i2c drivers used helper macros provided by
+<linux/i2c.h> which created standard module parameters to let the user
+control how the driver would probe i2c buses and attach to devices. These
+parameters were known as "probe" (to let the driver probe for an extra
+address), "force" (to forcibly attach the driver to a given device) and
+"ignore" (to prevent a driver from probing a given address).
+
+With the conversion of the i2c subsystem to the standard device driver
+binding model, it became clear that these per-module parameters were no
+longer needed, and that a centralized implementation was possible. The new,
+sysfs-based interface is described in the documentation file
+"instantiating-devices", section "Method 4: Instantiate from user-space".
+
+Below is a mapping from the old module parameters to the new interface.
+
+Attaching a driver to an I2C device
+-----------------------------------
+
+Old method (module parameters):
+# modprobe <driver> probe=1,0x2d
+# modprobe <driver> force=1,0x2d
+# modprobe <driver> force_<device>=1,0x2d
+
+New method (sysfs interface):
+# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
+
+Preventing a driver from attaching to an I2C device
+---------------------------------------------------
+
+Old method (module parameters):
+# modprobe <driver> ignore=1,0x2f
+
+New method (sysfs interface):
+# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
+# modprobe <driver>
+
+Of course, it is important to instantiate the "dummy" device before loading
+the driver. The dummy device will be handled by i2c-core itself, preventing
+other drivers from binding to it later on. If there is a real device at the
+problematic address, and you want another driver to bind to it, then simply
+pass the name of the device in question instead of "dummy".