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

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

What:	i2c-i810, i2c-prosavage and i2c-savage4

When:	May 2008

Why:	These drivers are superseded by i810fb, intelfb and savagefb.

Who:	Jean Delvare <khali@linux-fr.org>

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

What (Why):

	- include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files

	  (superseded by xt_TOS/xt_tos target & match)

Kernel driver i2c-i810

Supported adapters:

  * Intel 82810, 82810-DC100, 82810E, and 82815 (GMCH)

  * Intel 82845G (GMCH)

Authors: 

	Frodo Looijaard <frodol@dds.nl>, 

	Philip Edelbrock <phil@netroedge.com>,

        Kyösti Mälkki <kmalkki@cc.hut.fi>,

	Ralph Metzler <rjkm@thp.uni-koeln.de>,

	Mark D. Studebaker <mdsxyz123@yahoo.com>

Main contact: Mark Studebaker <mdsxyz123@yahoo.com>

Description 

----------- 

WARNING: If you have an '810' or '815' motherboard, your standard I2C

temperature sensors are most likely on the 801's I2C bus. You want the

i2c-i801 driver for those, not this driver.

Now for the i2c-i810...

The GMCH chip contains two I2C interfaces.

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. It may be connected to a

TV-out chip such as the BT869 or possibly to a digital flat-panel display.

Features

-------- 

Both busses use the i2c-algo-bit driver for 'bit banging'

and support for specific transactions is provided by i2c-algo-bit.

Issues

------

If you enable bus testing in i2c-algo-bit (insmod i2c-algo-bit bit_test=1),

the test may fail; if so, the i2c-i810 driver won't be inserted. However,

we think this has been fixed.

Kernel driver i2c-prosavage

Supported adapters:

	S3/VIA KM266/VT8375 aka ProSavage8 

	S3/VIA KM133/VT8365 aka Savage4 

Author: Henk Vergonet <henk@god.dyndns.org>

Description

-----------

The Savage4 chips contain 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.

Usefull for gaining access to the TV Encoder chips.

Kernel driver i2c-savage4

Supported adapters:

  * Savage4

  * Savage2000

Authors: 

	Alexander Wold <awold@bigfoot.com>,

	Mark D. Studebaker <mdsxyz123@yahoo.com> 

Description

-----------

The Savage4 chips contain 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 DDC bus is not yet supported because its register

is not directly memory-mapped.

The second interface is a general-purpose I2C bus. This is the only

interface supported by the driver at the moment.

This is a summary of the most important conventions for use of fault

codes in the I2C/SMBus stack.

A "Fault" is not always an "Error"

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

Not all fault reports imply errors; "page faults" should be a familiar

example.  Software often retries idempotent operations after transient

faults.  There may be fancier recovery schemes that are appropriate in

some cases, such as re-initializing (and maybe resetting).  After such

recovery, triggered by a fault report, there is no error.

In a similar way, sometimes a "fault" code just reports one defined

result for an operation ... it doesn't indicate that anything is wrong

at all, just that the outcome wasn't on the "golden path".

In short, your I2C driver code may need to know these codes in order

to respond correctly.  Other code may need to rely on YOUR code reporting

the right fault code, so that it can (in turn) behave correctly.

I2C and SMBus fault codes

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

These are returned as negative numbers from most calls, with zero or

some positive number indicating a non-fault return.  The specific

numbers associated with these symbols differ between architectures,

though most Linux systems use <asm-generic/errno*.h> numbering.

Note that the descriptions here are not exhaustive.  There are other

codes that may be returned, and other cases where these codes should

be returned.  However, drivers should not return other codes for these

cases (unless the hardware doesn't provide unique fault reports).

Also, codes returned by adapter probe methods follow rules which are

specific to their host bus (such as PCI, or the platform bus).

EAGAIN

	Returned by I2C adapters when they lose arbitration in master

	transmit mode:  some other master was transmitting different

	data at the same time.

	Also returned when trying to invoke an I2C operation in an

	atomic context, when some task is already using that I2C bus

	to execute some other operation.

EBADMSG

	Returned by SMBus logic when an invalid Packet Error Code byte

	is received.  This code is a CRC covering all bytes in the

	transaction, and is sent before the terminating STOP.  This

	fault is only reported on read transactions; the SMBus slave

	may have a way to report PEC mismatches on writes from the

	host.  Note that even if PECs are in use, you should not rely

	on these as the only way to detect incorrect data transfers.

EBUSY

	Returned by SMBus adapters when the bus was busy for longer

	than allowed.  This usually indicates some device (maybe the

	SMBus adapter) needs some fault recovery (such as resetting),

	or that the reset was attempted but failed.

EINVAL

	This rather vague error means an invalid parameter has been

	detected before any I/O operation was started.  Use a more

	specific fault code when you can.

	One example would be a driver trying an SMBus Block Write

	with block size outside the range of 1-32 bytes.

EIO

	This rather vague error means something went wrong when

	performing an I/O operation.  Use a more specific fault

	code when you can.

ENODEV

	Returned by driver probe() methods.  This is a bit more

	specific than ENXIO, implying the problem isn't with the

	address, but with the device found there.  Driver probes

	may verify the device returns *correct* responses, and

	return this as appropriate.  (The driver core will warn

	about probe faults other than ENXIO and ENODEV.)

ENOMEM

	Returned by any component that can't allocate memory when

	it needs to do so.

ENXIO

	Returned by I2C adapters to indicate that the address phase

	of a transfer didn't get an ACK.  While it might just mean

	an I2C device was temporarily not responding, usually it

	means there's nothing listening at that address.

	Returned by driver probe() methods to indicate that they

	found no device to bind to.  (ENODEV may also be used.)

EOPNOTSUPP

	Returned by an adapter when asked to perform an operation

	that it doesn't, or can't, support.

	For example, this would be returned when an adapter that

	doesn't support SMBus block transfers is asked to execute

	one.  In that case, the driver making that request should

	have verified that functionality was supported before it

	made that block transfer request.

	Similarly, if an I2C adapter can't execute all legal I2C

	messages, it should return this when asked to perform a

	transaction it can't.  (These limitations can't be seen in

	the adapter's functionality mask, since the assumption is

	that if an adapter supports I2C it supports all of I2C.)

EPROTO

	Returned when slave does not conform to the relevant I2C

	or SMBus (or chip-specific) protocol specifications.  One

	case is when the length of an SMBus block data response

	(from the SMBus slave) is outside the range 1-32 bytes.

ETIMEDOUT

	This is returned by drivers when an operation took too much

	time, and was aborted before it completed.

	SMBus adapters may return it when an operation took more

	time than allowed by the SMBus specification; for example,

	when a slave stretches clocks too far.  I2C has no such

	timeouts, but it's normal for I2C adapters to impose some

	arbitrary limits (much longer than SMBus!) too.