Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging (41440ffe) · Commits · 戴 / test

Documentation/feature-removal-schedule.txt

+0 −9

Original line number	Diff line number	Diff line
		@@ -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.

Documentation/i2c/busses/i2c-voodoo3

deleted100644 → 0

+0 −62

Original line number	Diff line number	Diff line
		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.

Documentation/i2c/i2c-stub

+11 −5

Original line number	Diff line number	Diff line
		@@ -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

Documentation/i2c/old-module-parameters

0 → 100644

+44 −0

Original line number	Diff line number	Diff line
		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".

arch/powerpc/include/asm/pmac_low_i2c.h

+1 −5

Original line number	Diff line number	Diff line
		@@ -72,11 +72,7 @@ extern int pmac_i2c_get_type(struct pmac_i2c_bus *bus);
		extern int pmac_i2c_get_flags(struct pmac_i2c_bus *bus);
		extern int pmac_i2c_get_channel(struct pmac_i2c_bus *bus);

		/* i2c layer adapter attach/detach */
		extern void pmac_i2c_attach_adapter(struct pmac_i2c_bus *bus,
		struct i2c_adapter *adapter);
		extern void pmac_i2c_detach_adapter(struct pmac_i2c_bus *bus,
		struct i2c_adapter *adapter);
		/* i2c layer adapter helpers */
		extern struct i2c_adapter pmac_i2c_get_adapter(struct pmac_i2c_bus bus);
		extern struct pmac_i2c_bus pmac_i2c_adapter_to_bus(struct i2c_adapter adapter);

Admin message