apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6: (56 commits)
  i2c: Add detection capability to new-style drivers
  i2c: Call client_unregister for new-style devices too
  i2c: Clean up old chip drivers
  i2c-ibm_iic: Register child nodes
  i2c: New-style EEPROM driver using device IDs
  i2c: Export the i2c_bus_type symbol
  i2c-au1550: Fix PM support
  i2c-dev: Delete empty detach_client callback
  i2c: Drop stray references to lm_sensors
  i2c: Check for ACPI resource conflicts
  i2c-ocores: basic PM support
  i2c-sibyte: SWARM I2C board initialization
  i2c-i801: Fix handling of error conditions
  i2c-i801: Rename local variable temp to status
  i2c-i801: Properly report bus arbitration loss
  i2c-i801: Remove verbose debugging messages
  i2c-algo-pcf: Drop unused struct members
  i2c-algo-pcf: Multi-master lost-arbitration improvement
  i2c: Deprecate the legacy gpio drivers
  i2c-pxa: Initialize early
  ...
This commit is contained in:
Linus Torvalds
2008-07-15 11:16:05 -07:00
parent 98339cbd36 4735c98f84
commit dc221eae08
72 changed files with 3897 additions and 2261 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/feature-removal-schedule.txt
-7
View File
@@ -222,13 +222,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
---------------------------
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)
Documentation/i2c/busses/i2c-i810
-47
View File
@@ -1,47 +0,0 @@
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.
Documentation/i2c/busses/i2c-prosavage
-23
View File
@@ -1,23 +0,0 @@
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.
Documentation/i2c/busses/i2c-savage4
-26
View File
@@ -1,26 +0,0 @@
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.
Documentation/i2c/fault-codes
+127
View File
@@ -0,0 +1,127 @@
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.
Documentation/i2c/smbus-protocol
+2 -2
View File
@@ -42,8 +42,8 @@ Count (8 bits): A data byte containing the length of a block operation.
[..]: Data sent by I2C device, as opposed to data sent by the host adapter.
SMBus Quick Command: i2c_smbus_write_quick()
=============================================
SMBus Quick Command
===================
This sends a single bit to the device, at the place of the Rd/Wr bit.
Documentation/i2c/writing-clients
+40 -11
View File
@@ -44,6 +44,10 @@ static struct i2c_driver foo_driver = {
.id_table = foo_ids,
.probe = foo_probe,
.remove = foo_remove,
/* if device autodetection is needed: */
.class = I2C_CLASS_SOMETHING,
.detect = foo_detect,
.address_data = &addr_data,
/* else, driver uses "legacy" binding model: */
.attach_adapter = foo_attach_adapter,
@@ -217,6 +221,31 @@ in the I2C bus driver. You may want to save the returned i2c_client
reference for later use.
Device Detection (Standard driver model)
----------------------------------------
Sometimes you do not know in advance which I2C devices are connected to
a given I2C bus. This is for example the case of hardware monitoring
devices on a PC's SMBus. In that case, you may want to let your driver
detect supported devices automatically. This is how the legacy model
was working, and is now available as an extension to the standard
driver model (so that we can finally get rid of the legacy model.)
You simply have to define a detect callback which will attempt to
identify supported devices (returning 0 for supported ones and -ENODEV
for unsupported ones), a list of addresses to probe, and a device type
(or class) so that only I2C buses which may have that type of device
connected (and not otherwise enumerated) will be probed. The i2c
core will then call you back as needed and will instantiate a device
for you for every successful detection.
Note that this mechanism is purely optional and not suitable for all
devices. You need some reliable way to identify the supported devices
(typically using device-specific, dedicated identification registers),
otherwise misdetections are likely to occur and things can get wrong
quickly.
Device Deletion (Standard driver model)
---------------------------------------
@@ -569,7 +598,6 @@ SMBus communication
in terms of it. Never use this function directly!
extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value);
extern s32 i2c_smbus_read_byte(struct i2c_client * client);
extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value);
extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command);
@@ -578,30 +606,31 @@ SMBus communication
extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
extern s32 i2c_smbus_write_word_data(struct i2c_client * client,
u8 command, u16 value);
extern s32 i2c_smbus_read_block_data(struct i2c_client * client,
u8 command, u8 *values);
extern s32 i2c_smbus_write_block_data(struct i2c_client * client,
u8 command, u8 length,
u8 *values);
extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
u8 command, u8 length, u8 *values);
These ones were removed in Linux 2.6.10 because they had no users, but could
be added back later if needed:
extern s32 i2c_smbus_read_block_data(struct i2c_client * client,
u8 command, u8 *values);
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
u8 command, u8 length,
u8 *values);
These ones were removed from i2c-core because they had no users, but could
be added back later if needed:
extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value);
extern s32 i2c_smbus_process_call(struct i2c_client * client,
u8 command, u16 value);
extern s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length,
u8 *values)
All these transactions return -1 on failure. The 'write' transactions
return 0 on success; the 'read' transactions return the read value, except
for read_block, which returns the number of values read. The block buffers
need not be longer than 32 bytes.
All these transactions return a negative errno value on failure. The 'write'
transactions return 0 on success; the 'read' transactions return the read
value, except for block transactions, which return the number of values
read. The block buffers need not be longer than 32 bytes.
You can read the file `smbus-protocol' for more information about the
actual SMBus protocol.