Merge branch 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6

The SMBus controller is function 3 in device 1f. Class 0c05 is SMBus Serial

Controller.

If you do NOT see the 24x3 device at function 3, and you can't figure out

any way in the BIOS to enable it,

The ICH chips are quite similar to Intel's PIIX4 chip, at least in the

SMBus controller.

See the file i2c-piix4 for some additional information.

Process Call Support

--------------------

The 82801DB (ICH4) and later chips support several SMBus 2.0 features.

Hidden ICH SMBus

----------------

If your system has an Intel ICH south bridge, but you do NOT see the

SMBus device at 00:1f.3 in lspci, and you can't figure out any way in the

BIOS to enable it, it means it has been hidden by the BIOS code. Asus is

well known for first doing this on their P4B motherboard, and many other

boards after that. Some vendor machines are affected as well.

The first thing to try is the "i2c_ec" ACPI driver. It could be that the

SMBus was hidden on purpose because it'll be driven by ACPI. If the

i2c_ec driver works for you, just forget about the i2c-i801 driver and

don't try to unhide the ICH SMBus. Even if i2c_ec doesn't work, you

better make sure that the SMBus isn't used by the ACPI code. Try loading

the "fan" and "thermal" drivers, and check in /proc/acpi/fan and

/proc/acpi/thermal_zone. If you find anything there, it's likely that

the ACPI is accessing the SMBus and it's safer not to unhide it. Only

once you are certain that ACPI isn't using the SMBus, you can attempt

to unhide it.

In order to unhide the SMBus, we need to change the value of a PCI

register before the kernel enumerates the PCI devices. This is done in

drivers/pci/quirks.c, where all affected boards must be listed (see

function asus_hides_smbus_hostbridge.) If the SMBus device is missing,

and you think there's something interesting on the SMBus (e.g. a

hardware monitoring chip), you need to add your board to the list.

The motherboard is identified using the subvendor and subdevice IDs of the

host bridge PCI device. Get yours with "lspci -n -v -s 00:00.0":

00:00.0 Class 0600: 8086:2570 (rev 02)

        Subsystem: 1043:80f2

        Flags: bus master, fast devsel, latency 0

        Memory at fc000000 (32-bit, prefetchable) [size=32M]

        Capabilities: [e4] #09 [2106]

        Capabilities: [a0] AGP version 3.0

Here the host bridge ID is 2570 (82865G/PE/P), the subvendor ID is 1043

(Asus) and the subdevice ID is 80f2 (P4P800-X). You can find the symbolic

names for the bridge ID and the subvendor ID in include/linux/pci_ids.h,

and then add a case for your subdevice ID at the right place in

drivers/pci/quirks.c. Then please give it very good testing, to make sure

that the unhidden SMBus doesn't conflict with e.g. ACPI.

If it works, proves useful (i.e. there are usable chips on the SMBus)

and seems safe, please submit a patch for inclusion into the kernel.

Note: There's a useful script in lm_sensors 2.10.2 and later, named

unhide_ICH_SMBus (in prog/hotplug), which uses the fakephp driver to

temporarily unhide the SMBus without having to patch and recompile your

kernel. It's very convenient if you just want to check if there's

anything interesting on your hidden ICH SMBus.

**********************

The lm_sensors project gratefully acknowledges the support of Texas

Instruments in the initial development of this driver.

 * (type=4) Analog Devices ADM1032 evaluation board

 * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031

 * (type=6) Barco LPT->DVI (K5800236) adapter

 * (type=7) One For All JP1 parallel port adapter

These devices use different pinout configurations, so you have to tell

the driver what you have, using the type module parameter. There is no

  http://home.wanadoo.nl/hihihi/libk8005.htm

  http://struyve.mine.nu:8080/index.php?block=k8000

  http://sourceforge.net/projects/libk8005/

One For All JP1 parallel port adapter

-------------------------------------

The JP1 project revolves around a set of remote controls which expose

the I2C bus their internal configuration EEPROM lives on via a 6 pin

jumper in the battery compartment. More details can be found at:

http://www.hifi-remote.com/jp1/

Details of the simple parallel port hardware can be found at:

http://www.hifi-remote.com/jp1/hardware.shtml

    Datasheet: Publicly available at the Intel website

  * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges

    Datasheet: Only available via NDA from ServerWorks

  * ATI IXP southbridges IXP200, IXP300, IXP400

  * ATI IXP200, IXP300, IXP400 and SB600 southbridges

    Datasheet: Not publicly available

  * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge

    Datasheet: Publicly available at the SMSC website http://www.smsc.com

  * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8251

    Datasheet: available on request and under NDA from VIA

  * VIA Technologies, Inc. CX700

    Datasheet: available on request and under NDA from VIA

Authors:

	Kysti Mlkki <kmalkki@cc.hut.fi>,

	Mark D. Studebaker <mdsxyz123@yahoo.com>,

 device 1106:3227   (VT8237R)

 device 1106:3337   (VT8237A)

 device 1106:3287   (VT8251)

 device 1106:8324   (CX700)

If none of these show up, you should look in the BIOS for settings like

enable ACPI / SMBus or even USB.

Except for the oldest chips (VT82C596A/B, VT82C686A and most probably

VT8231), this driver supports I2C block transactions. Such transactions

are mainly useful to read from and write to EEPROMs.

The CX700 additionally appears to support SMBus PEC, although this driver

doesn't implement it yet.

  structure, those name member should be initialized to a driver name

  string. i2c_driver itself has no name member anymore.

* [Driver model] Instead of shutdown or reboot notifiers, provide a

  shutdown() method in your driver.

* [Power management] Use the driver model suspend() and resume()

  callbacks instead of the obsolete pm_register() calls.

Coding policy:

* [Copyright] Use (C), not (c), for copyright.