Menu
▾
▴
[LV-kern-commit] CVS: kernel-2.4/Documentation/i2c dev-interface,1.1.1.1,1.2 summary,1.1.1.1,1.2 writing-clients,1.1.1.1,1.2
|
From: Andy P. <at...@us...> - 2002-04-09 17:08:09
|
Update of /cvsroot/linux-vax/kernel-2.4/Documentation/i2c
In directory usw-pr-cvs1:/tmp/cvs-serv7449/i2c
Modified Files:
dev-interface summary writing-clients
Log Message:
synch 2.4.15 commit 28
Index: dev-interface
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/i2c/dev-interface,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- dev-interface 14 Jan 2001 20:06:36 -0000 1.1.1.1
+++ dev-interface 9 Apr 2002 16:55:41 -0000 1.2
@@ -70,6 +70,9 @@
/* buf[0] contains the read byte */
}
+IMPORTANT: because of the use of inline functions, you *have* to use
+'-O' or some variation when you compile your program!
+
Full interface description
==========================
Index: summary
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/i2c/summary,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- summary 14 Jan 2001 20:06:37 -0000 1.1.1.1
+++ summary 9 Apr 2002 16:55:41 -0000 1.2
@@ -1,9 +1,9 @@
-This is an explanation of what i2c is, and what is supported.
+This is an explanation of what i2c is, and what is supported in this package.
I2C and SMBus
=============
-I2C (pronounce: I square C) is a protocol developed by Philips. It is a
+I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
slow two-wire protocol (10-100 kHz), but it suffices for many types of
devices.
@@ -25,6 +25,7 @@
Adapter
Device -> Driver
Client
+
An Algorithm driver contains general code that can be used for a whole class
of I2C adapters. Each specific adapter driver depends on one algorithm
driver.
@@ -35,29 +36,40 @@
For a given configuration, you will need a driver for your I2C bus (usually
a separate Adapter and Algorithm driver), and drivers for your I2C devices
-(usually one driver for each device).
+(usually one driver for each device). There are no I2C device drivers
+in this package. See the lm_sensors project http://www.lm-sensors.nu
+for device drivers.
+
+Included Bus Drivers
+====================
+Note that not only stable drivers are patched into the kernel by 'mkpatch'.
-Included Drivers
-================
Base modules
------------
i2c-core: The basic I2C code, including the /proc interface
i2c-dev: The /dev interface
+i2c-proc: The /proc interface for device (client) drivers
Algorithm drivers
-----------------
-i2c-algo-bit: A bit-banging algorithm
-i2c-algo-pcf: A PCF 8584 style algorithm
+i2c-algo-8xx: An algorithm for CPM's I2C device in Motorola 8xx processors (NOT BUILT BY DEFAULT)
+i2c-algo-bit: A bit-banging algorithm
+i2c-algo-pcf: A PCF 8584 style algorithm
+i2c-algo-ppc405: An algorithm for the I2C device in IBM 405xx processors (NOT BUILT BY DEFAULT)
Adapter drivers
---------------
i2c-elektor: Elektor ISA card (uses i2c-algo-pcf)
i2c-elv: ELV parallel port adapter (uses i2c-algo-bit)
+i2c-pcf-epp: PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (BROKEN - missing i2c-pcf-epp.h)
i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
+i2c-ppc405: IBM 405xx processor I2C device (uses i2c-algo-ppc405) (NOT BUILT BY DEFAULT)
+i2c-pport: Primitive parallel port adapter (uses i2c-algo-bit)
+i2c-rpx: RPX board Motorola 8xx I2C device (uses i2c-algo-8xx) (NOT BUILT BY DEFAULT)
i2c-velleman: Velleman K9000 parallel port adapter (uses i2c-algo-bit)
Index: writing-clients
===================================================================
RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/i2c/writing-clients,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- writing-clients 14 Jan 2001 20:06:42 -0000 1.1.1.1
+++ writing-clients 9 Apr 2002 16:55:41 -0000 1.2
@@ -33,7 +33,7 @@
/* detach_client */ &foo_detach_client,
/* command */ &foo_command, /* May be NULL */
/* inc_use */ &foo_inc_use, /* May be NULL */
- /* dec_use */ &foo_dev_use /* May be NULL */
+ /* dec_use */ &foo_dec_use /* May be NULL */
}
The name can be chosen freely, and may be upto 40 characters long. Please
@@ -190,7 +190,7 @@
detection algorithm.
You do not have to use this parameter interface; but don't try to use
-function i2c_probe() (or sensors_detect()) if you don't.
+function i2c_probe() (or i2c_detect()) if you don't.
NOTE: If you want to write a `sensors' driver, the interface is slightly
different! See below.
@@ -344,17 +344,17 @@
return i2c_probe(adapter,&addr_data,&foo_detect_client);
}
-For `sensors' drivers, use the sensors_detect function instead:
+For `sensors' drivers, use the i2c_detect function instead:
int foo_attach_adapter(struct i2c_adapter *adapter)
{
- return sensors_detect(adapter,&addr_data,&foo_detect_client);
+ return i2c_detect(adapter,&addr_data,&foo_detect_client);
}
Remember, structure `addr_data' is defined by the macros explained above,
so you do not have to define it yourself.
-The i2c_probe or sensors_detect function will call the foo_detect_client
+The i2c_probe or i2c_detect function will call the foo_detect_client
function only for those i2c addresses that actually have a device on
them (unless a `force' parameter was used). In addition, addresses that
are already in use (by some other registered client) are skipped.
@@ -363,9 +363,9 @@
The detect client function
--------------------------
-The detect client function is called by i2c_probe or sensors_detect.
+The detect client function is called by i2c_probe or i2c_detect.
The `kind' parameter contains 0 if this call is due to a `force'
-parameter, and 0 otherwise (for sensors_detect, it contains 0 if
+parameter, and 0 otherwise (for i2c_detect, it contains 0 if
this call is due to the generic `force' parameter, and the chip type
number if it is due to a specific `force' parameter).
@@ -530,7 +530,7 @@
/* SENSORS ONLY BEGIN */
/* Register a new directory entry with module sensors. See below for
the `template' structure. */
- if ((i = sensors_register_entry(new_client, type_name,
+ if ((i = i2c_register_entry(new_client, type_name,
foo_dir_table_template,THIS_MODULE)) < 0) {
err = i;
goto ERROR4;
@@ -574,8 +574,8 @@
int err,i;
/* SENSORS ONLY START */
- /* Deregister with the `sensors' module. */
- sensors_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id);
+ /* Deregister with the `i2c-proc' module. */
+ i2c_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id);
/* SENSORS ONLY END */
/* Try to detach the client from i2c space */
@@ -772,12 +772,12 @@
First, I will give an example definition.
static ctl_table foo_dir_table_template[] = {
- { FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &sensors_proc_real,
- &sensors_sysctl_real,NULL,&foo_func },
- { FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &sensors_proc_real,
- &sensors_sysctl_real,NULL,&foo_func },
- { FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &sensors_proc_real,
- &sensors_sysctl_real,NULL,&foo_data },
+ { FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &i2c_proc_real,
+ &i2c_sysctl_real,NULL,&foo_func },
+ { FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &i2c_proc_real,
+ &i2c_sysctl_real,NULL,&foo_func },
+ { FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &i2c_proc_real,
+ &i2c_sysctl_real,NULL,&foo_data },
{ 0 }
};
@@ -791,8 +791,8 @@
fourth should always be 0. The fifth is the mode of the /proc file;
0644 is safe, as the file will be owned by root:root.
-The seventh and eighth parameters should be &sensors_proc_real and
-&sensors_sysctl_real if you want to export lists of reals (scaled
+The seventh and eighth parameters should be &i2c_proc_real and
+&i2c_sysctl_real if you want to export lists of reals (scaled
integers). You can also use your own function for them, as usual.
Finally, the last parameter is the call-back to gather the data
(see below) if you use the *_proc_real functions.
|
