I2C update for 2.6.8-rc1

Hi,

Here are some i2c driver fixes and updates for 2.6.8-rc1. There are a few new i2c chip drivers, and the biggest chunk is the new w1 (1-wire) driver subsystem contributed by Evgeniy Polyakov. The sysfs interface for w1 isn't finished quite yet (just need to create some more sysfs files, nothing major), but the main functionality is there, and this allows more w1 drivers to be contributed easier.

Please pull from: bk://kernel.bkbits.net/gregkh/linux/i2c-2.6

Individual patches will follow, sent to the sensors and linux-kernel lists.

thanks,

greg k-h

 Documentation/i2c/i2c-pport      |   45 -
 Documentation/i2c/i2c-velleman   |   20 
 Documentation/i2c/i2c-parport    |  156 +++++
 MAINTAINERS                      |   12 
 drivers/Kconfig                  |    2 
 drivers/Makefile                 |    1 
 drivers/i2c/busses/i2c-elektor.c |    6 
 drivers/i2c/busses/i2c-ibm_iic.c |  132 ++++-
 drivers/i2c/busses/scx200_acb.c  |    1 
 drivers/i2c/chips/Kconfig        |   42 +
 drivers/i2c/chips/Makefile       |    3 
 drivers/i2c/chips/adm1025.c      |  570 +++++++++++++++++++++
 drivers/i2c/chips/adm1031.c      | 1021 ++++++++++++++++++++++++++++++++++++++-
 drivers/i2c/chips/lm75.c         |   37 +
 drivers/i2c/chips/lm77.c         |  413 +++++++++++++++
 drivers/i2c/chips/lm78.c         |   88 ---
 drivers/i2c/chips/lm90.c         |   69 +-
 drivers/i2c/i2c-dev.c            |   33 -
 drivers/pci/quirks.c             |   58 +-
 drivers/w1/Kconfig               |   31 +
 drivers/w1/Makefile              |    9 
 drivers/w1/matrox_w1.c           |  246 +++++++++
 drivers/w1/w1.c                  |  623 +++++++++++++++++++++++
 drivers/w1/w1.h                  |  112 ++++
 drivers/w1/w1_family.c           |  133 +++++
 drivers/w1/w1_family.h           |   65 ++
 drivers/w1/w1_int.c              |  207 +++++++
 drivers/w1/w1_int.h              |   36 +
 drivers/w1/w1_io.c               |  138 +++++
 drivers/w1/w1_io.h               |   35 +
 drivers/w1/w1_log.h              |   38 +
 drivers/w1/w1_netlink.c          |   55 ++
 drivers/w1/w1_netlink.h          |   44 +
 drivers/w1/w1_therm.c            |  177 ++++++
 34 files changed, 4411 insertions(+), 247 deletions(-)

-----

<alex:alexdalton.org>:
o I2C: small ADM1030 fix
o I2C: ADM1030 and Co sensors chips support

<drewie:freemail.hu>:
o I2C: Add support for LM77

<orange:fobie.net>:
o I2C: patch quirks.c - SMBus hidden on hp laptop

Eugene Surovegin:
o I2C PPC4xx IIC driver: 0-length transactions bit-banging implementation

Greg Kroah-Hartman:
o 1 Wire: add Dallas 1-wire protocol driver subsystem
o I2C: sparse cleanups for a few i2c drivers

Jean Delvare:
o I2C: Refine detection of LM75 chips
o I2C: adm1025 driver ported to 2.6
o I2C: remove Documentation for i2c-pport
o I2C: Documentation for i2c-parport
o I2C: Add support for LM86, MAX6657 and MAX6658 to lm90
o I2C: Class of scx200_acb

Luiz Capitulino:
o I2C: i2c/i2c-dev.c::i2c_dev_init() cleanup

Mark M. Hoffman:
o I2C: Remove extra inits from lm78 driver

ChangeSet 1.1784.13.1, 2004/07/08 16:05:54-07:00, [email protected]

[PATCH] I2C: ADM1030 and Co sensors chips support

Here is a patch against linux-2.6.7-mm1 kernel that adds support for adm1030 and adm1031 sensors chips.

It has been reviewed several times by Jean Delvare, and he thinks it is ready for inclusion into 2.6 kernel. So here it is.

 drivers/i2c/chips/Kconfig   |   10 
 drivers/i2c/chips/Makefile  |    1 
 drivers/i2c/chips/adm1031.c |  988 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 999 insertions(+)

diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
@@ -22,6 +22,16 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called adm1021.
 
+config SENSORS_ADM1031
+	tristate "Analog Devices ADM1031 and compatibles"
+	depends on I2C && EXPERIMENTAL
+	select I2C_SENSOR
+	help
+	  If you say yes here you get support for Analog Devices ADM1031 
+	  and ADM1030 sensor chips.
+	  This driver can also be built as a module.  If so, the module
+	  will be called adm1031.
+
 config SENSORS_ASB100
 	tristate "Asus ASB100 Bach"
 	depends on I2C && EXPERIMENTAL

diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_SENSORS_W83781D)	+= w83781d.o
 
 obj-$(CONFIG_SENSORS_ADM1021)	+= adm1021.o
+obj-$(CONFIG_SENSORS_ADM1031)	+= adm1031.o
 obj-$(CONFIG_SENSORS_DS1621)	+= ds1621.o
 obj-$(CONFIG_SENSORS_EEPROM)	+= eeprom.o
 obj-$(CONFIG_SENSORS_FSCHER)	+= fscher.o

ChangeSet 1.1784.13.2, 2004/07/08 16:06:22-07:00, [email protected]

[PATCH] I2C PPC4xx IIC driver: 0-length transactions bit-banging implementation

IBM PPC 4xx i2c controller doesn't support 0-length transactions (e.g. used by SMBUS_QUICK). This patch implements bit-banging emulation for such requests and removes temporary kludge added earlier.

 drivers/i2c/busses/i2c-ibm_iic.c |  132 +++++++++++++++++++++++++++++++++++++--
 1 files changed, 126 insertions(+), 6 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -45,7 +45,7 @@
 
 #include "i2c-ibm_iic.h"
 
-#define DRIVER_VERSION "2.01"
+#define DRIVER_VERSION "2.1"
 
 MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
 MODULE_LICENSE("GPL");

@@ -96,6 +96,31 @@
 #  define DUMP_REGS(h,dev)	((void)0)
 #endif
 
+/* Bus timings (in ns) for bit-banging */
+static struct i2c_timings {
+	unsigned int hd_sta;
+	unsigned int su_sto;
+	unsigned int low;
+	unsigned int high;
+	unsigned int buf;
+} timings [] = {
+/* Standard mode (100 KHz) */
+{
+	.hd_sta	= 4000,
+	.su_sto	= 4000,
+	.low	= 4700,
+	.high	= 4000,
+	.buf	= 4700,
+},
+/* Fast mode (400 KHz) */
+{
+	.hd_sta = 600,
+	.su_sto	= 600,
+	.low 	= 1300,
+	.high 	= 600,
+	.buf	= 1300,
+}};
+
 /* Enable/disable interrupt generation */
 static inline void iic_interrupt_mode(struct ibm_iic_private* dev, int enable)
 {

@@ -196,6 +221,104 @@
 }
 
 /*
+ * Do 0-length transaction using bit-banging through IIC_DIRECTCNTL register.
+ */
+
+/* Wait for SCL and/or SDA to be high */
+static int iic_dc_wait(volatile struct iic_regs *iic, u8 mask)
+{
+	unsigned long x = jiffies + HZ / 28 + 2;
+	while ((in_8(&iic->directcntl) & mask) != mask){
+		if (unlikely(time_after(jiffies, x)))
+			return -1;
+		cond_resched();
+	}
+	return 0;
+}
+
+static int iic_smbus_quick(struct ibm_iic_private* dev, const struct i2c_msg* p)
+{
+	volatile struct iic_regs* iic = dev->vaddr;
+	const struct i2c_timings* t = &timings[dev->fast_mode ? 1 : 0];
+	u8 mask, v, sda;
+	int i, res;
+
+	/* Only 7-bit addresses are supported */
+	if (unlikely(p->flags & I2C_M_TEN)){
+		DBG("%d: smbus_quick - 10 bit addresses are not supported\n",
+			dev->idx);
+		return -EINVAL;
+	}
+
+	DBG("%d: smbus_quick(0x%02x)\n", dev->idx, p->addr);
+
+	/* Reset IIC interface */
+	out_8(&iic->xtcntlss, XTCNTLSS_SRST);
+
+	/* Wait for bus to become free */
+	out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+	if (unlikely(iic_dc_wait(iic, DIRCNTL_MSDA | DIRCNTL_MSC)))
+		goto err;
+	ndelay(t->buf);
+
+	/* START */
+	out_8(&iic->directcntl, DIRCNTL_SCC);
+	sda = 0;
+	ndelay(t->hd_sta);
+
+	/* Send address */
+	v = (u8)((p->addr << 1) | ((p->flags & I2C_M_RD) ? 1 : 0));
+	for (i = 0, mask = 0x80; i < 8; ++i, mask >>= 1){
+		out_8(&iic->directcntl, sda);
+		ndelay(t->low / 2);
+		sda = (v & mask) ? DIRCNTL_SDAC : 0;
+		out_8(&iic->directcntl, sda);
+		ndelay(t->low / 2);
+
+		out_8(&iic->directcntl, DIRCNTL_SCC | sda);
+		if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+			goto err;
+		ndelay(t->high);
+	}
+
+	/* ACK */
+	out_8(&iic->directcntl, sda);
+	ndelay(t->low / 2);
+	out_8(&iic->directcntl, DIRCNTL_SDAC);
+	ndelay(t->low / 2);
+	out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+	if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+		goto err;
+	res = (in_8(&iic->directcntl) & DIRCNTL_MSDA) ? -EREMOTEIO : 1;
+	ndelay(t->high);
+
+	/* STOP */
+	out_8(&iic->directcntl, 0);
+	ndelay(t->low);
+	out_8(&iic->directcntl, DIRCNTL_SCC);
+	if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+		goto err;
+	ndelay(t->su_sto);
+	out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+
+	ndelay(t->buf);
+
+	DBG("%d: smbus_quick -> %s\n", dev->idx, res ? "NACK" : "ACK");
+out:
+	/* Remove reset */
+	out_8(&iic->xtcntlss, 0);
+
+	/* Reinitialize interface */
+	iic_dev_init(dev);
+
+	return res;
+err:
+	DBG("%d: smbus_quick - bus is stuck\n", dev->idx);
+	res = -EREMOTEIO;
+	goto out;
+}
+
+/*
  * IIC interrupt handler
  */
 static irqreturn_t iic_handler(int irq, void *dev_id, struct pt_regs *regs)

@@ -457,13 +580,10 @@
 		if (unlikely(msgs[i].len <= 0)){
 			if (num == 1 && !msgs[0].len){
 				/* Special case for I2C_SMBUS_QUICK emulation.
-				 * Although this logic is FAR FROM PERFECT, this 
-				 * is what previous driver version did.
 				 * IBM IIC doesn't support 0-length transactions
-				 * (except bit-banging through IICx_DIRECTCNTL).
+				 * so we have to emulate them using bit-banging.
 				 */
-				DBG("%d: zero-length msg kludge\n", dev->idx); 
-				return 0;
+				return iic_smbus_quick(dev, &msgs[0]);
 			}
 			DBG("%d: invalid len %d in msg[%d]\n", dev->idx, 
 				msgs[i].len, i);

ChangeSet 1.1784.13.3, 2004/07/08 16:06:41-07:00, [email protected]

[PATCH] I2C: Class of scx200_acb

This is needed for the scx200_acb to accept hardware monitoring chips.

 drivers/i2c/busses/scx200_acb.c |    1 +
 1 files changed, 1 insertion(+)

diff -Nru a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
@@ -458,6 +458,7 @@
 	adapter->owner = THIS_MODULE;
 	adapter->id = I2C_ALGO_SMBUS;
 	adapter->algo = &scx200_acb_algorithm;
+	adapter->class = I2C_CLASS_HWMON;
 
 	init_MUTEX(&iface->sem);
 

ChangeSet 1.1784.13.4, 2004/07/08 16:07:05-07:00, [email protected]

[PATCH] I2C: Add support for LM86, MAX6657 and MAX6658 to lm90

This adds support for the LM86, MAX6657 and MAX6658 sensor chips to the lm90 driver. These are less popular than the LM90 and ADM1032 but several users have reported to use these, so I added support to the lm90 driver. All these chips are fully compatible so that's just a matter of accepting the new chip ids. I also slightly simplified the detection code.

 drivers/i2c/chips/Kconfig |    3 +-
 drivers/i2c/chips/lm90.c  |   69 ++++++++++++++++++++++++++++++----------------
 2 files changed, 48 insertions(+), 24 deletions(-)

diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
@@ -150,7 +150,8 @@
 	select I2C_SENSOR
 	help
 	  If you say yes here you get support for National Semiconductor LM90,
-	  LM89 and LM99, and Analog Devices ADM1032 sensor chips.
+	  LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and
+	  MAX6658 sensor chips.
 
 	  This driver can also be built as a module.  If so, the module
 	  will be called lm90.

ChangeSet 1.1784.13.5, 2004/07/08 16:07:27-07:00, [email protected]

[PATCH] I2C: i2c/i2c-dev.c::i2c_dev_init() cleanup.

This patch does the fallowing cleanup for
drivers/i2c/i2c-dev.c::i2c_dev_init():

*) in a error condition, return the error code of register_chrdev() insted of -EIO;
*) adds missing audit for class_register();
*) in a error condition, only prints "Driver Initialisation Failed", insted printing the cause. (Note that the error will be printed by the return of the error code, and the information about what function caused the problem need to be done by a debug code).

Only compiled, lack of hardware.

 drivers/i2c/i2c-dev.c |   33 +++++++++++++++++++++------------
 1 files changed, 21 insertions(+), 12 deletions(-)

diff -Nru a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
@@ -518,20 +518,29 @@
 
 	printk(KERN_INFO "i2c /dev entries driver\n");
 
-	if (register_chrdev(I2C_MAJOR,"i2c",&i2cdev_fops)) {
-		printk(KERN_ERR "i2c-dev.o: unable to get major %d for i2c bus\n",
-		       I2C_MAJOR);
-		return -EIO;
-	}
+	res = register_chrdev(I2C_MAJOR, "i2c", &i2cdev_fops);
+	if (res)
+		goto out;
+
+	res = class_register(&i2c_dev_class);
+	if (res)
+		goto out_unreg_chrdev;
+
+	res = i2c_add_driver(&i2cdev_driver);
+	if (res)
+		goto out_unreg_class;
+
 	devfs_mk_dir("i2c");
-	class_register(&i2c_dev_class);
-	if ((res = i2c_add_driver(&i2cdev_driver))) {
-		printk(KERN_ERR "i2c-dev.o: Driver registration failed, module not inserted.\n");
-		devfs_remove("i2c");
-		unregister_chrdev(I2C_MAJOR,"i2c");
-		return res;
-	}
+
 	return 0;
+
+out_unreg_class:
+	class_unregister(&i2c_dev_class);
+out_unreg_chrdev:
+	unregister_chrdev(I2C_MAJOR, "i2c");
+out:
+	printk(KERN_ERR "%s: Driver Initialisation failed", __FILE__);
+	return res;
 }
 
 static void __exit i2c_dev_exit(void)

ChangeSet 1.1784.13.6, 2004/07/08 16:07:58-07:00, [email protected]

[PATCH] I2C: Documentation for i2c-parport

At least, the i2c-parport gets some documentation. I heard several persons complaining that there was no sample electronics schema for building their own i2c-over-parallel-port, so I did just that, with the help of Sylvain Munaut. The documentation also includes the list of supported adapters, and a short comparison with other drivers using the parallel port to drive an i2c bus. At the end of the document I included an updated version of the i2c-velleman doc file (which I then deleted).

 Documentation/i2c/i2c-velleman |   20 -----
 Documentation/i2c/i2c-parport  |  156 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 156 insertions(+), 20 deletions(-)

diff -Nru a/Documentation/i2c/i2c-parport b/Documentation/i2c/i2c-parport
@@ -0,0 +1,156 @@
+==================
+i2c-parport driver
+==================
+
+2004-07-06, Jean Delvare
+
+This is a unified driver for several i2c-over-parallel-port adapters,
+such as the ones made by Philips, Velleman or ELV. This driver is
+meant as a replacement for the older, individual drivers:
+ * i2c-philips-par
+ * i2c-elv
+ * i2c-velleman
+ * video/i2c-parport (NOT the same as this one, dedicated to home brew
+                      teletext adapters)
+
+It currently supports the following devices:
+ * Philips adapter
+ * home brew teletext adapter
+ * Velleman K8000 adapter
+ * ELV adapter
+ * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032)
+
+These devices use different pinout configurations, so you have to tell
+the driver what you have, using the type module parameter. There is no
+way to autodetect the devices. Support for different pinout configurations
+can be easily added when needed.
+
+
+Building your own adapter
+-------------------------
+
+If you want to build you own i2c-over-parallel-port adapter, here is
+a sample electronics schema (credits go to Sylvain Munaut):
+
+Device                                                      PC
+Side          ___________________Vdd (+)                    Side
+               |    |         |
+              ---  ---       ---
+              | |  | |       | |
+              |R|  |R|       |R|
+              | |  | |       | |
+              ---  ---       ---
+               |    |         |
+               |    |    /|   |
+SCL  ----------x--------o |-----------x-------------------  pin 2
+                    |    \|   |       |
+                    |         |       |
+                    |   |\    |       |
+SDA  ----------x----x---| o---x---------------------------  pin 13
+               |        |/            |
+               |                      |
+               |         /|           |
+               ---------o |----------------x--------------  pin 3
+                         \|           |    |
+                                      |    |
+                                     ---  ---
+                                     | |  | |
+                                     |R|  |R|
+                                     | |  | |
+                                     ---  ---
+                                      |    | 
+                                     ###  ###
+                                     GND  GND
+        
+Remarks:
+ - This is the exact pinout and electronics used on the Analog Devices
+   evaluation boards.
+                   /|
+ - All inverters -o |- must be 74HC05, they must be open collector output.
+                   \|
+ - All resitors are 10k.
+ - Pins 18-25 of the parallel port connected to GND.
+ - Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
+   The ADM1032 evaluation board uses D4-D7. Beware that the amount of
+   current you can draw from the parallel port is limited. Also note that
+   all connected lines MUST BE driven at the same state, else you'll short
+   circuit the output buffers! So plugging the I2C adapter after loading
+   the i2c-parport module might be a good safety since data line state
+   prior to init may be unknown. 
+ - This is 5V!
+ - Obviously you cannot read SCL (so it's not really standard-compliant).
+   Pretty easy to add, just copy the SDA part and use another input pin.
+   That would give (ELV compatible pinout):
+
+
+Device                                                      PC
+Side          ______________________________Vdd (+)         Side
+               |    |            |    |
+              ---  ---          ---  ---
+              | |  | |          | |  | |
+              |R|  |R|          |R|  |R|
+              | |  | |          | |  | |
+              ---  ---          ---  ---
+               |    |            |    |
+               |    |      |\    |    |
+SCL  ----------x--------x--| o---x------------------------  pin 15
+                    |   |  |/         | 
+                    |   |             |
+                    |   |   /|        |
+                    |   ---o |-------------x--------------  pin 2
+                    |       \|        |    |
+                    |                 |    |
+                    |                 |    |
+                    |      |\         |    |
+SDA  ---------------x---x--| o--------x-------------------  pin 10
+                        |  |/              |
+                        |                  |
+                        |   /|             |
+                        ---o |------------------x---------  pin 3
+                            \|             |    |
+                                           |    |
+                                          ---  ---
+                                          | |  | |
+                                          |R|  |R|
+                                          | |  | |
+                                          ---  ---
+                                           |    | 
+                                          ###  ###
+                                          GND  GND
+
+
+If possible, you should use the same pinout configuration as existing
+adapters do, so you won't even have to change the code.
+
+
+Similar (but different) drivers
+-------------------------------
+
+This driver is NOT the same as the i2c-pport driver found in the i2c package.
+The i2c-pport driver makes use of modern parallel port features so that
+you don't need additional electronics. It has other restrictions however, and
+was not ported to Linux 2.6 (yet).
+
+This driver is also NOT the same as the i2c-pcf-epp driver found in the
+lm_sensors package. The i2c-pcf-epp driver doesn't use the parallel port
+as an I2C bus directly. Instead, it uses it to control an external I2C bus
+master. That driver was not ported to Linux 2.6 (yet) either.
+
+
+Legacy documentation for Velleman adapter
+-----------------------------------------
+
+Useful links:
+Velleman                http://www.velleman.be/
+Velleman K8000 Howto    http://howto.htlw16.ac.at/k8000-howto.html
+
+The project has lead to new libs for the Velleman K8000 and K8005:
+  LIBK8000 v1.99.1 and LIBK8005 v0.21
+With these libs, you can control the K8000 interface card and the K8005
+stepper motor card with the simple commands which are in the original
+Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
+many more, using /dev/velleman.
+  http://home.wanadoo.nl/hihihi/libk8000.htm
+  http://home.wanadoo.nl/hihihi/libk8005.htm
+  http://struyve.mine.nu:8080/index.php?block=k8000
+  http://sourceforge.net/projects/libk8005/

diff -Nru a/Documentation/i2c/i2c-velleman b/Documentation/i2c/i2c-velleman
@@ -1,23 +0,0 @@
-i2c-velleman driver
--------------------
-This is a driver for i2c-hw access for Velleman K8000 and other adapters.
-
-Useful links
-------------
-Velleman:
-	http://www.velleman.be/
-
-Velleman K8000 Howto:
-	http://howto.htlw16.ac.at/k8000-howto.html
-
-K8000 and K8005 libraries
--------------------------
-The project has lead to new libs for the Velleman K8000 and K8005:
-LIBK8000 v1.99.1 and LIBK8005 v0.21
-
-With these libs, you can control the K8000 interface card and the K8005
-stepper motor card with the simple commands which are in the original
-Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
-many more, using /dev/velleman.
-
-The libs can be found on http://groups.yahoo.com/group/k8000/files/linux/

ChangeSet 1.1784.13.7, 2004/07/08 16:08:19-07:00, [email protected]

[PATCH] I2C: Add support for LM77

This patch (against the current stack) adds support for the LM77 sensor chips made by National Semiconductor. Formerly this was claimed by the LM75 driver but when I got hold of an embedded board (built around the National Geode SC1100 CPU), which was equipped with an LM77, it turned out that the two chips are not compatible.

It has been developed with help of, reviewed and approved by Jean Delvare.

 drivers/i2c/chips/Kconfig  |   11 +
 drivers/i2c/chips/Makefile |    1 
 drivers/i2c/chips/lm77.c   |  413 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 425 insertions(+)

diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
@@ -99,6 +99,17 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called lm75.
 
+config SENSORS_LM77
+	tristate "National Semiconductor LM77"
+	depends on I2C && EXPERIMENTAL
+	select I2C_SENSOR
+	help
+	  If you say yes here you get support for National Semiconductor LM77
+	  sensor chips.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called lm77.
+
 config SENSORS_LM78
 	tristate "National Semiconductor LM78 and compatibles"
 	depends on I2C && EXPERIMENTAL

diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
@@ -15,6 +15,7 @@
 obj-$(CONFIG_SENSORS_GL518SM)	+= gl518sm.o
 obj-$(CONFIG_SENSORS_IT87)	+= it87.o
 obj-$(CONFIG_SENSORS_LM75)	+= lm75.o
+obj-$(CONFIG_SENSORS_LM77)	+= lm77.o
 obj-$(CONFIG_SENSORS_LM78)	+= lm78.o
 obj-$(CONFIG_SENSORS_LM80)	+= lm80.o
 obj-$(CONFIG_SENSORS_LM83)	+= lm83.o

ChangeSet 1.1784.13.8, 2004/07/09 14:47:23-07:00, [email protected]

[PATCH] I2C: remove Documentation for i2c-pport

 Documentation/i2c/i2c-pport |   45 --------------------------------------------
 1 files changed, 45 deletions(-)

diff -Nru a/Documentation/i2c/i2c-pport b/Documentation/i2c/i2c-pport
@@ -1,45 +0,0 @@
-Primitive parallel port is driver for i2c bus, which exploits 
-features of modern bidirectional parallel ports. 
-
-Bidirectional ports have particular bits connected in following way:
-   
-                        |
-            /-----|     R
-         --o|     |-----|
-      read  \-----|     /------- Out pin
-                      |/
-                   - -|\
-                write   V
-                        |
-                       ---  
-
-
-It means when output is set to 1 we can read the port. Therefore 
-we can use 2 pins of parallel port as SDA and SCL for i2c bus. It 
-is not necessary to add any external - additional parts, we can 
-read and write the same port simultaneously.
-	I only use register base+2 so it is possible to use all 
-8 data bits of parallel port for other applications (I have 
-connected EEPROM and LCD display). I do not use bit Enable Bi-directional
- Port. The only disadvantage is we can only support 5V chips.
-
-Layout:
-
-Cannon 25 pin
-
-SDA - connect to pin 14 (Auto Linefeed)
-SCL - connect to pin 16 (Initialize Printer)
-GND - connect to pin 18-25
-+5V - use external supply (I use 5V from 3.5" floppy connector)
-      
-no pullups  requied
-
-Module parameters:
-
-base = 0xXXX
-XXX - 278 or 378
-
-That's all.
-
-Daniel Smolik
[email protected]

ChangeSet 1.1784.13.9, 2004/07/09 14:47:50-07:00, [email protected]

[PATCH] I2C: adm1025 driver ported to 2.6

This is my port of the adm1025 driver to 2.6. It has been tested by a few users and reported to work OK.

 drivers/i2c/chips/Kconfig   |   10 
 drivers/i2c/chips/Makefile  |    1 
 drivers/i2c/chips/adm1025.c |  570 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 581 insertions(+)

diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
@@ -22,6 +22,16 @@
 	  This driver can also be built as a module.  If so, the module
 	  will be called adm1021.
 
+config SENSORS_ADM1025
+	tristate "Analog Devices ADM1025 and compatibles"
+	depends on I2C && EXPERIMENTAL
+	select I2C_SENSOR
+	help
+	  If you say yes here you get support for Analog Devices ADM1025
+	  and Philips NE1619 sensor chips.
+	  This driver can also be built as a module.  If so, the module
+	  will be called adm1025.
+
 config SENSORS_ADM1031
 	tristate "Analog Devices ADM1031 and compatibles"
 	depends on I2C && EXPERIMENTAL

diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_SENSORS_W83781D)	+= w83781d.o
 
 obj-$(CONFIG_SENSORS_ADM1021)	+= adm1021.o
+obj-$(CONFIG_SENSORS_ADM1025)	+= adm1025.o
 obj-$(CONFIG_SENSORS_ADM1031)	+= adm1031.o
 obj-$(CONFIG_SENSORS_DS1621)	+= ds1621.o
 obj-$(CONFIG_SENSORS_EEPROM)	+= eeprom.o

ChangeSet 1.1784.13.10, 2004/07/09 15:07:03-07:00, [email protected]

I2C: sparse cleanups for a few i2c drivers.

 drivers/i2c/busses/i2c-elektor.c |    6 +++---
 drivers/i2c/chips/adm1031.c      |   29 +++++++++++++----------------
 2 files changed, 16 insertions(+), 19 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
@@ -143,7 +143,7 @@
 		}
 	}
 	if (irq > 0) {
-		if (request_irq(irq, pcf_isa_handler, 0, "PCF8584", 0) < 0) {
+		if (request_irq(irq, pcf_isa_handler, 0, "PCF8584", NULL) < 0) {
 			printk(KERN_ERR "i2c-elektor: Request irq%d failed\n", irq);
 			irq = 0;
 		} else

@@ -244,7 +244,7 @@
  fail:
 	if (irq > 0) {
 		disable_irq(irq);
-		free_irq(irq, 0);
+		free_irq(irq, NULL);
 	}
 
 	if (!mmapped)

@@ -258,7 +258,7 @@
 
 	if (irq > 0) {
 		disable_irq(irq);
-		free_irq(irq, 0);
+		free_irq(irq, NULL);
 	}
 
 	if (!mmapped)

diff -Nru a/drivers/i2c/chips/adm1031.c b/drivers/i2c/chips/adm1031.c
@@ -101,10 +101,6 @@
 static int adm1031_detect(struct i2c_adapter *adapter, int address, int kind);
 static void adm1031_init_client(struct i2c_client *client);
 static int adm1031_detach_client(struct i2c_client *client);
-static inline u8 adm1031_read_value(struct i2c_client *client, u8 reg);
-static inline int
-adm1031_write_value(struct i2c_client *client, u8 reg, unsigned int value);
-
 static struct adm1031_data *adm1031_update_device(struct device *dev);
 
 /* This is the driver that will be inserted */

@@ -116,7 +112,19 @@
 	.detach_client = adm1031_detach_client,
 };
 
-static int adm1031_id = 0;
+static int adm1031_id;
+
+static inline u8 adm1031_read_value(struct i2c_client *client, u8 reg)
+{
+	return i2c_smbus_read_byte_data(client, reg);
+}
+
+static inline int
+adm1031_write_value(struct i2c_client *client, u8 reg, unsigned int value)
+{
+	return i2c_smbus_write_byte_data(client, reg, value);
+}
+
 
 #define TEMP_TO_REG(val)		(((val) < 0 ? ((val - 500) / 1000) : \
 					((val + 500) / 1000)))

@@ -847,17 +855,6 @@
 	}
 	kfree(client);
 	return 0;
-}
-
-static inline u8 adm1031_read_value(struct i2c_client *client, u8 reg)
-{
-	return i2c_smbus_read_byte_data(client, reg);
-}
-
-static inline int
-adm1031_write_value(struct i2c_client *client, u8 reg, unsigned int value)
-{
-	return i2c_smbus_write_byte_data(client, reg, value);
 }
 
 static void adm1031_init_client(struct i2c_client *client)

ChangeSet 1.1784.13.11, 2004/07/09 15:08:41-07:00, [email protected]

[PATCH] I2C: small ADM1030 fix

Please find an incremental patch that applies on top of the previous one (the one from the first message of the thread) and that adds parenthesis to the macro as pointed out by Mark.

 drivers/i2c/chips/adm1031.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Nru a/drivers/i2c/chips/adm1031.c b/drivers/i2c/chips/adm1031.c
@@ -162,8 +162,8 @@
 	(AUTO_TEMP_MIN_FROM_REG(reg) - 5000)
 
 #define AUTO_TEMP_MAX_FROM_REG(reg)		\
-	AUTO_TEMP_RANGE_FROM_REG(reg) +		\
-	AUTO_TEMP_MIN_FROM_REG(reg)
+	(AUTO_TEMP_RANGE_FROM_REG(reg) +	\
+	AUTO_TEMP_MIN_FROM_REG(reg))
 
 static int AUTO_TEMP_MAX_TO_REG(int val, int reg, int pwm)
 {

ChangeSet 1.1784.13.12, 2004/07/09 16:39:56-07:00, [email protected]

1 Wire: add Dallas 1-wire protocol driver subsystem

This was written and developed by Evgeniy Polyakov <[email protected]> with only very minor cleanups by me.

 MAINTAINERS             |    6 
 drivers/Kconfig         |    2 
 drivers/Makefile        |    1 
 drivers/w1/Kconfig      |   31 ++
 drivers/w1/Makefile     |    9 
 drivers/w1/matrox_w1.c  |  246 ++++++++++++++++++
 drivers/w1/w1.c         |  623 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/w1/w1.h         |  112 ++++++++
 drivers/w1/w1_family.c  |  133 ++++++++++
 drivers/w1/w1_family.h  |   65 +++++
 drivers/w1/w1_int.c     |  207 +++++++++++++++
 drivers/w1/w1_int.h     |   36 ++
 drivers/w1/w1_io.c      |  138 ++++++++++
 drivers/w1/w1_io.h      |   35 ++
 drivers/w1/w1_log.h     |   38 ++
 drivers/w1/w1_netlink.c |   55 ++++
 drivers/w1/w1_netlink.h |   44 +++
 drivers/w1/w1_therm.c   |  177 +++++++++++++
 18 files changed, 1958 insertions(+)

diff -Nru a/MAINTAINERS b/MAINTAINERS
@@ -2379,6 +2379,12 @@
 M:	[email protected]
 S:	Maintained
 
+W1 DALLAS'S 1-WIRE BUS
+P:	Evgeniy Polyakov
+M:	[email protected]
+L:	[email protected]
+S:	Maintained
+
 WAN ROUTER & SANGOMA WANPIPE DRIVERS & API (X.25, FRAME RELAY, PPP, CISCO HDLC)
 P:	Nenad Corbic
 M:	[email protected]

diff -Nru a/drivers/Kconfig b/drivers/Kconfig
@@ -42,6 +42,8 @@
 
 source "drivers/i2c/Kconfig"
 
+source "drivers/w1/Kconfig"
+
 source "drivers/misc/Kconfig"
 
 source "drivers/media/Kconfig"

diff -Nru a/drivers/Makefile b/drivers/Makefile
@@ -42,6 +42,7 @@
 obj-$(CONFIG_SERIO)		+= input/serio/
 obj-$(CONFIG_I2O)		+= message/
 obj-$(CONFIG_I2C)		+= i2c/
+obj-$(CONFIG_W1)		+= w1/
 obj-$(CONFIG_PHONE)		+= telephony/
 obj-$(CONFIG_MD)		+= md/
 obj-$(CONFIG_BT)		+= bluetooth/

diff -Nru a/drivers/w1/Kconfig b/drivers/w1/Kconfig
@@ -0,0 +1,31 @@
+menu "Dallas's 1-wire bus"
+
+config W1
+	tristate "Dallas's 1-wire support"
+	---help---
+	  Dallas's 1-wire bus is usefull to connect slow 1-pin devices 
+	  such as iButtons and thermal sensors.
+	  
+	  If you want W1 support, you should say Y here.
+
+	  This W1 support can also be built as a module.  If so, the module
+	  will be called wire.ko.
+
+config W1_MATROX
+	tristate "Matrox G400 transport layer for 1-wire"
+	depends on W1
+	help
+	  Say Y here if you want to communicate with your 1-wire devices
+	  using Matrox's G400 GPIO pins.
+	  
+	  This support is also available as a module.  If so, the module 
+	  will be called matrox_w1.ko.
+
+config W1_THERM
+	tristate "Thermal family implementation"
+	depends on W1
+	help
+	  Say Y here if you want to connect 1-wire thermal sensors to you
+	  wire.
+
+endmenu

diff -Nru a/drivers/w1/Makefile b/drivers/w1/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the Dallas's 1-wire bus.
+#
+
+obj-$(CONFIG_W1)	+= wire.o
+wire-objs		:= w1.o w1_int.o w1_family.o w1_netlink.o w1_io.o
+
+obj-$(CONFIG_W1_MATROX)		+= matrox_w1.o
+obj-$(CONFIG_W1_THERM)		+= w1_therm.o

diff -Nru a/drivers/w1/w1_int.h b/drivers/w1/w1_int.h
@@ -0,0 +1,36 @@
+/*
+ * 	w1_int.h
+ *
+ * Copyright (c) 2004 Evgeniy Polyakov <[email protected]>
+ * 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __W1_INT_H
+#define __W1_INT_H
+
+#include <linux/kernel.h>
+#include <linux/device.h>
+
+#include "w1.h"
+
+struct w1_master * w1_alloc_dev(int, struct device_driver *, struct device *);
+void w1_free_dev(struct w1_master *dev);
+int w1_add_master_device(struct w1_bus_master *);
+void w1_remove_master_device(struct w1_bus_master *);
+void __w1_remove_master_device(struct w1_master *);
+
+#endif /* __W1_INT_H */

diff -Nru a/drivers/w1/w1_io.h b/drivers/w1/w1_io.h
@@ -0,0 +1,35 @@
+/*
+ * 	w1_io.h
+ *
+ * Copyright (c) 2004 Evgeniy Polyakov <[email protected]>
+ * 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __W1_IO_H
+#define __W1_IO_H
+
+#include "w1.h"
+
+void w1_delay(unsigned long);
+void w1_write_bit(struct w1_master *, int);
+void w1_write_8(struct w1_master *, u8);
+u8 w1_read_bit(struct w1_master *);
+u8 w1_read_8(struct w1_master *);
+int w1_reset_bus(struct w1_master *);
+u8 w1_calc_crc8(u8 *, int);
+
+#endif /* __W1_IO_H */

diff -Nru a/drivers/w1/w1_log.h b/drivers/w1/w1_log.h
@@ -0,0 +1,38 @@
+/*
+ * 	w1_log.h
+ *
+ * Copyright (c) 2004 Evgeniy Polyakov <[email protected]>
+ * 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __W1_LOG_H
+#define __W1_LOG_H
+
+#define DEBUG
+
+#ifdef W1_DEBUG
+#  define assert(expr) do {} while (0)
+#else
+#  define assert(expr) \
+        if(unlikely(!(expr))) {				        \
+        printk(KERN_ERR "Assertion failed! %s,%s,%s,line=%d\n",	\
+        #expr,__FILE__,__FUNCTION__,__LINE__);		        \
+        }
+#endif
+
+#endif /* __W1_LOG_H */
+

ChangeSet 1.1784.13.13, 2004/07/14 11:50:09-07:00, [email protected]

[PATCH] I2C: Remove extra inits from lm78 driver

This patch is from the lm_sensors project CVS, from this revision:

1.63 (mds) remove initialization of limits by driver

It is better to set these limits by a combination of /etc/sensors.conf and 'sensors -s'; "mechanism not policy." Please apply.

 drivers/i2c/chips/lm78.c |   88 -----------------------------------------------
 1 files changed, 88 deletions(-)

diff -Nru a/drivers/i2c/chips/lm78.c b/drivers/i2c/chips/lm78.c
@@ -123,55 +123,6 @@
 }
 #define DIV_FROM_REG(val) (1 << (val))
 
-/* Initial limits. To keep them sane, we use the 'standard' translation as
-   specified in the LM78 sheet. Use the config file to set better limits. */
-#define LM78_INIT_IN_0(vid) ((vid)==3500 ? 2800 : (vid))
-#define LM78_INIT_IN_1(vid) ((vid)==3500 ? 2800 : (vid))
-#define LM78_INIT_IN_2 3300
-#define LM78_INIT_IN_3 (((5000)   * 100)/168)
-#define LM78_INIT_IN_4 (((12000)  * 10)/38)
-#define LM78_INIT_IN_5 (((-12000) * -604)/2100)
-#define LM78_INIT_IN_6 (((-5000)  * -604)/909)
-
-#define LM78_INIT_IN_PERCENTAGE 10
-
-#define LM78_INIT_IN_MIN_0(vid) (LM78_INIT_IN_0(vid) - \
-	LM78_INIT_IN_0(vid) * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_0(vid) (LM78_INIT_IN_0(vid) + \
-	LM78_INIT_IN_0(vid) * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MIN_1(vid) (LM78_INIT_IN_1(vid) - \
-	LM78_INIT_IN_1(vid) * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_1(vid) (LM78_INIT_IN_1(vid) + \
-	LM78_INIT_IN_1(vid) * LM78_INIT_IN_PERCENTAGE / 100)
-
-#define LM78_INIT_IN_MIN_2 \
-        (LM78_INIT_IN_2 - LM78_INIT_IN_2 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_2 \
-        (LM78_INIT_IN_2 + LM78_INIT_IN_2 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MIN_3 \
-        (LM78_INIT_IN_3 - LM78_INIT_IN_3 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_3 \
-        (LM78_INIT_IN_3 + LM78_INIT_IN_3 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MIN_4 \
-        (LM78_INIT_IN_4 - LM78_INIT_IN_4 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_4 \
-        (LM78_INIT_IN_4 + LM78_INIT_IN_4 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MIN_5 \
-        (LM78_INIT_IN_5 - LM78_INIT_IN_5 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_5 \
-        (LM78_INIT_IN_5 + LM78_INIT_IN_5 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MIN_6 \
-        (LM78_INIT_IN_6 - LM78_INIT_IN_6 * LM78_INIT_IN_PERCENTAGE / 100)
-#define LM78_INIT_IN_MAX_6 \
-        (LM78_INIT_IN_6 + LM78_INIT_IN_6 * LM78_INIT_IN_PERCENTAGE / 100)
-
-#define LM78_INIT_FAN_MIN_1 3000
-#define LM78_INIT_FAN_MIN_2 3000
-#define LM78_INIT_FAN_MIN_3 3000
-
-#define LM78_INIT_TEMP_OVER 60000
-#define LM78_INIT_TEMP_HYST 50000
-
 /* There are some complications in a module like this. First off, LM78 chips
    may be both present on the SMBus and the ISA bus, and we have to handle
    those cases separately at some places. Second, there might be several

@@ -755,45 +706,6 @@
 	else
 		vid |= 0x10;
 	vid = VID_FROM_REG(vid);
-
-	lm78_write_value(client, LM78_REG_IN_MIN(0),
-			 IN_TO_REG(LM78_INIT_IN_MIN_0(vid)));
-	lm78_write_value(client, LM78_REG_IN_MAX(0),
-			 IN_TO_REG(LM78_INIT_IN_MAX_0(vid)));
-	lm78_write_value(client, LM78_REG_IN_MIN(1),
-			 IN_TO_REG(LM78_INIT_IN_MIN_1(vid)));
-	lm78_write_value(client, LM78_REG_IN_MAX(1),
-			 IN_TO_REG(LM78_INIT_IN_MAX_1(vid)));
-	lm78_write_value(client, LM78_REG_IN_MIN(2),
-			 IN_TO_REG(LM78_INIT_IN_MIN_2));
-	lm78_write_value(client, LM78_REG_IN_MAX(2),
-			 IN_TO_REG(LM78_INIT_IN_MAX_2));
-	lm78_write_value(client, LM78_REG_IN_MIN(3),
-			 IN_TO_REG(LM78_INIT_IN_MIN_3));
-	lm78_write_value(client, LM78_REG_IN_MAX(3),
-			 IN_TO_REG(LM78_INIT_IN_MAX_3));
-	lm78_write_value(client, LM78_REG_IN_MIN(4),
-			 IN_TO_REG(LM78_INIT_IN_MIN_4));
-	lm78_write_value(client, LM78_REG_IN_MAX(4),
-			 IN_TO_REG(LM78_INIT_IN_MAX_4));
-	lm78_write_value(client, LM78_REG_IN_MIN(5),
-			 IN_TO_REG(LM78_INIT_IN_MIN_5));
-	lm78_write_value(client, LM78_REG_IN_MAX(5),
-			 IN_TO_REG(LM78_INIT_IN_MAX_5));
-	lm78_write_value(client, LM78_REG_IN_MIN(6),
-			 IN_TO_REG(LM78_INIT_IN_MIN_6));
-	lm78_write_value(client, LM78_REG_IN_MAX(6),
-			 IN_TO_REG(LM78_INIT_IN_MAX_6));
-	lm78_write_value(client, LM78_REG_FAN_MIN(0),
-			 FAN_TO_REG(LM78_INIT_FAN_MIN_1, 2));
-	lm78_write_value(client, LM78_REG_FAN_MIN(1),
-			 FAN_TO_REG(LM78_INIT_FAN_MIN_2, 2));
-	lm78_write_value(client, LM78_REG_FAN_MIN(2),
-			 FAN_TO_REG(LM78_INIT_FAN_MIN_3, 2));
-	lm78_write_value(client, LM78_REG_TEMP_OVER,
-			 TEMP_TO_REG(LM78_INIT_TEMP_OVER));
-	lm78_write_value(client, LM78_REG_TEMP_HYST,
-			 TEMP_TO_REG(LM78_INIT_TEMP_HYST));
 
 	/* Start monitoring */
 	lm78_write_value(client, LM78_REG_CONFIG,

ChangeSet 1.1784.13.14, 2004/07/14 11:51:29-07:00, [email protected]

[PATCH] I2C: Refine detection of LM75 chips

The LM75 detection method was a bit loose so far and would accept non-LM75-compatible chips from times to times. It should be better now. Additionally, the help for the lm75 driver was reworked because we now know that the LM75 and the LM77 are not compatible.

 drivers/i2c/chips/Kconfig |    8 ++++++--
 drivers/i2c/chips/lm75.c  |   37 +++++++++++++++++++++++++++++++------
 2 files changed, 37 insertions(+), 8 deletions(-)

diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
@@ -103,8 +103,12 @@
 	select I2C_SENSOR
 	help
 	  If you say yes here you get support for National Semiconductor LM75
-	  sensor chips and clones: Dallas Semi DS75 and DS1775, TelCon
-	  TCN75, and National Semiconductor LM77.
+	  sensor chips and clones: Dallas Semiconductor DS75 and DS1775 (in
+	  9-bit precision mode), and TelCom (now Microchip) TCN75.
+
+	  The DS75 and DS1775 in 10- to 12-bit precision modes will require
+	  a force module parameter. The driver will not handle the extra
+	  precision anyhow.
 
 	  This driver can also be built as a module.  If so, the module
 	  will be called lm75.

diff -Nru a/drivers/i2c/chips/lm75.c b/drivers/i2c/chips/lm75.c
@@ -113,7 +113,7 @@
 /* This function is called by i2c_detect */
 static int lm75_detect(struct i2c_adapter *adapter, int address, int kind)
 {
-	int i, cur, conf, hyst, os;
+	int i;
 	struct i2c_client *new_client;
 	struct lm75_data *data;
 	int err = 0;

@@ -149,16 +149,41 @@
 	new_client->driver = &lm75_driver;
 	new_client->flags = 0;
 
-	/* Now, we do the remaining detection. It is lousy. */
+	/* Now, we do the remaining detection. There is no identification-
+	   dedicated register so we have to rely on several tricks:
+	   unused bits, registers cycling over 8-address boundaries,
+	   addresses 0x04-0x07 returning the last read value.
+	   The cycling+unused addresses combination is not tested,
+	   since it would significantly slow the detection down and would
+	   hardly add any value. */
 	if (kind < 0) {
+		int cur, conf, hyst, os;
+
+		/* Unused addresses */
 		cur = i2c_smbus_read_word_data(new_client, 0);
 		conf = i2c_smbus_read_byte_data(new_client, 1);
 		hyst = i2c_smbus_read_word_data(new_client, 2);
+		if (i2c_smbus_read_word_data(new_client, 4) != hyst
+		 || i2c_smbus_read_word_data(new_client, 5) != hyst
+		 || i2c_smbus_read_word_data(new_client, 6) != hyst
+		 || i2c_smbus_read_word_data(new_client, 7) != hyst)
+		 	goto exit_free;
 		os = i2c_smbus_read_word_data(new_client, 3);
-		for (i = 0; i <= 0x1f; i++)
-			if ((i2c_smbus_read_byte_data(new_client, i * 8 + 1) != conf) ||
-			    (i2c_smbus_read_word_data(new_client, i * 8 + 2) != hyst) ||
-			    (i2c_smbus_read_word_data(new_client, i * 8 + 3) != os))
+		if (i2c_smbus_read_word_data(new_client, 4) != os
+		 || i2c_smbus_read_word_data(new_client, 5) != os
+		 || i2c_smbus_read_word_data(new_client, 6) != os
+		 || i2c_smbus_read_word_data(new_client, 7) != os)
+		 	goto exit_free;
+
+		/* Unused bits */
+		if (conf & 0xe0)
+		 	goto exit_free;
+
+		/* Addresses cycling */
+		for (i = 8; i < 0xff; i += 8)
+			if (i2c_smbus_read_byte_data(new_client, i + 1) != conf
+			 || i2c_smbus_read_word_data(new_client, i + 2) != hyst
+			 || i2c_smbus_read_word_data(new_client, i + 3) != os)
 				goto exit_free;
 	}
 

ChangeSet 1.1784.1.96, 2004/07/14 16:04:27-07:00, [email protected]

[PATCH] I2C: patch quirks.c - SMBus hidden on hp laptop

This patch unhides the SMBus on the hp nc8000 and nc6000 laptops. The patch has been co-written by Jean Delvare and Rudolf Marek. I've only tested this on nc8000, but it should work for the nc6000 too.

Unfortunatley, we had to little information to fix the problem described in the reported bug below, as is probably the same problem. But if we're very lucky it might solve it too.
http://bugzilla.kernel.org/show_bug.cgi?id=2976

 drivers/pci/quirks.c |   58 ++++++++++++++++++++++++++++++---------------------
 1 files changed, 35 insertions(+), 23 deletions(-)

diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
@@ -694,29 +694,38 @@
 
 static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
 {
-	if (likely(dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK))
-		return;
-
-	if (dev->device == PCI_DEVICE_ID_INTEL_82845_HB)
-		switch(dev->subsystem_device) {
-		case 0x8070: /* P4B */
-	    	case 0x8088: /* P4B533 */
-			asus_hides_smbus = 1;
-		}
-	if (dev->device == PCI_DEVICE_ID_INTEL_82845G_HB)
-		switch(dev->subsystem_device) {
- 		case 0x80b1: /* P4GE-V */
-		case 0x80b2: /* P4PE */
- 		case 0x8093: /* P4B533-V */
-			asus_hides_smbus = 1;
-		}
-	if ((dev->device == PCI_DEVICE_ID_INTEL_82850_HB) &&
-	    (dev->subsystem_device == 0x8030)) /* P4T533 */
-		asus_hides_smbus = 1;
-	if ((dev->device == PCI_DEVICE_ID_INTEL_7205_0) &&
-	    (dev->subsystem_device == 0x8070)) /* P4G8X Deluxe */
-		asus_hides_smbus = 1;
-	return;
+	if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK)) {
+		if (dev->device == PCI_DEVICE_ID_INTEL_82845_HB)
+			switch(dev->subsystem_device) {
+			case 0x8070: /* P4B */
+			case 0x8088: /* P4B533 */
+				asus_hides_smbus = 1;
+			}
+		if (dev->device == PCI_DEVICE_ID_INTEL_82845G_HB)
+			switch(dev->subsystem_device) {
+			case 0x80b1: /* P4GE-V */
+			case 0x80b2: /* P4PE */
+			case 0x8093: /* P4B533-V */
+				asus_hides_smbus = 1;
+			}
+		if (dev->device == PCI_DEVICE_ID_INTEL_82850_HB)
+			switch(dev->subsystem_device) {
+			case 0x8030: /* P4T533 */
+				asus_hides_smbus = 1;
+			}
+		if (dev->device == PCI_DEVICE_ID_INTEL_7205_0)
+			switch (dev->subsystem_device) {
+			case 0x8070: /* P4G8X Deluxe */
+				asus_hides_smbus = 1;
+			}
+	} else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_HP)) {
+		if (dev->device ==  PCI_DEVICE_ID_INTEL_82855PM_HB)
+			switch(dev->subsystem_device) {
+			case 0x088C: /* HP Compaq nc8000 */
+			case 0x0890: /* HP Compaq nc6000 */
+				asus_hides_smbus = 1;
+			}
+	}
 }
 
 static void __init asus_hides_smbus_lpc(struct pci_dev *dev)

@@ -987,13 +996,16 @@
 
 	/*
 	 * on Asus P4B boards, the i801SMBus device is disabled at startup.
+	 * this also goes for boards in HP Compaq nc6000 and nc8000 notebooks.
 	 */
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82845_HB,	asus_hides_smbus_hostbridge },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82845G_HB,	asus_hides_smbus_hostbridge },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82850_HB,	asus_hides_smbus_hostbridge },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_7205_0,	asus_hides_smbus_hostbridge },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82855PM_HB,	asus_hides_smbus_hostbridge },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801DB_0,	asus_hides_smbus_lpc },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801BA_0,	asus_hides_smbus_lpc },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82801DB_12,	asus_hides_smbus_lpc },
 
 #ifdef CONFIG_SCSI_SATA
 	/* Fixup BIOSes that configure Parallel ATA (PATA / IDE) and

Hi!

64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

I'm pretty sure it's just 1 wire, at least for the devices I've seen.

thanks,

greg k-h

<snip>

I work with these all the time - it's power & data one one pin, and some kind of a ground. They also make some in 3 terminal packages (pinouts can be had on the Maxim site). That said, I'm really pleased to see this in the kernel - as I'm in the process of developing all the firmware to port one of our product to use Linux! The application guys are way ahead of me, however...

Enjoy

Bob Riegelmann

It's GND+power&data. The device derives its power from transitions on the data line driven by the master. Consequently there are some fairly strict timing requirements on those pulses. Some devices can also be powered by a dedicated VCC line which generally allows the device to respond faster. A temperature sensor IC, for example, can usually complete a conversion cycle much faster when it has dedicated power.

--Adam

Because the compiler/linker does it already for you :)

See the kernel janitor's list for more information about why this is a good thing to change.

thanks,

greg k-h

Hm, then I want to update my i2c client porting guide to mention that?

Thanks,
Jean Delvare

It's probably not worth it, unless you want to mention to check the kernel janitor's list to make sure you aren't doing any of the things mentioned there.

thanks,

greg k-h

Is this right that we don't want to explicitly initialize the adm1031_id counter?

Why is that?
:v)

Philip Pokorny, Director of Engineering
Tel: 415-954-2823   Fax: 415-954-2899   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

Greg,

While having some fun, with the old 2.4 vt8231, ""porting"" that to the 2.6 Branche, my eyes raised some strange question, which I hope you can answer.

temp[1-4]_max Temperature max value.
Unit: Milidegrees Celsius
Read/Write value.

I far as I know, one Milidegrees is one thousand Grade Celsius.

The actual Reading, from the vt8231 inside the io space is an 8 bit value. It contains for example a number "78" in "Celsius" for de 1f CPU temp location.

Now, from various documentations floating around, for some undocumented or well hidden reason, this mostly is multiplied by 0.88 giving a reading of 68.84

I assume somebody thought about it and calculated that m that was a nice correction value.

Converting it to the required units, would be 68.84*1000 = 68840 Or, to avoid Floating points: ( (68*1000)*880)/1000 = 68840 Milidegrees Celsius

That was, when life was easy.

However, my bet is somebody figured out, that bit 7 till 6 in the reserved area from area 4b, contains also bits of temperature information. (Although the datasheet I have, describe that area as "Reserved")

The value is readed, Anded with 192, then shifted to right by 6 to get the reading. "0,1,2,3". We assume the value is 3.

Assuming that, this Value is stored in the same Magic Celsius Value, Multiplied by 880, this gives a correction of 2640 Milidegrees.

That is, if it where separate 8 and 2 bit values. But As I can see, from the original code, it assumed as 1 10bit value.

Thus the first value 79 is shifted to left by 2, and the second value is orred into it. Which gives (79>>2) = 316.
Plus the low value "3" = 319

Returning, this, in the old version, to Human readable format, it was multiplied by 10, and then divided by 4. Giving 797.5

I assume, that something has changed, with the sensor output format. Thus, the new return formula would be:

	Multi by 1000, divide by 4.

Now we have 79750.

Throwing in the 0.088 Correction Factor the final result is:
79750* 0.088 = 70180 Milidegrees Celsius

Or 319 * 880 /4 = 70180

Or 319 * 220 = 70180

If this was "temp3" , it would result in 1 sensors.conf line:

Compute temp3 @

Is my final concussing Right?

If so, I will move on to the voltage part :) If not, I Hope somebody can point me out where to go...

http://tser.org/vt8231/

Regards
Reinder Kraaij.

Hm, Greg must be on virtual holiday.

Yoo-hoo?

Anyone else, then alive?

I hope open source doesn't mean "Closed community :)"
Here I am. I want to contribute some code. But I need some help, because not everything can be done alone on this planet. Sometimes you need guidance.

It's better to talk, and send people away on a search, then to ignore people.

And all I want is some small help with i2c.

Reinder.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Reinder
Sent: Saturday, July 17, 2004 16:30
To: [email protected]
Subject: Greg (or anyone else) one small i2c question.

Greg,

While having some fun, with the old 2.4 vt8231, ""porting"" that to the 2.6 Branche, my eyes raised some strange question, which I hope you can answer.

temp[1-4]_max Temperature max value.
Unit: Milidegrees Celsius
Read/Write value.

I far as I know, one Milidegrees is one thousand Grade Celsius.

The actual Reading, from the vt8231 inside the io space is an 8 bit value. It contains for example a number "78" in "Celsius" for de 1f CPU temp location.

Now, from various documentations floating around, for some undocumented or well hidden reason, this mostly is multiplied by 0.88 giving a reading of 68.84

I assume somebody thought about it and calculated that m that was a nice correction value.

Converting it to the required units, would be 68.84*1000 = 68840 Or, to avoid Floating points: ( (68*1000)*880)/1000 = 68840 Milidegrees Celsius

That was, when life was easy.

However, my bet is somebody figured out, that bit 7 till 6 in the reserved area from area 4b, contains also bits of temperature information. (Although the datasheet I have, describe that area as "Reserved")

The value is readed, Anded with 192, then shifted to right by 6 to get the reading. "0,1,2,3". We assume the value is 3.

Assuming that, this Value is stored in the same Magic Celsius Value, Multiplied by 880, this gives a correction of 2640 Milidegrees.

That is, if it where separate 8 and 2 bit values. But As I can see, from the original code, it assumed as 1 10bit value.

Thus the first value 79 is shifted to left by 2, and the second value is orred into it. Which gives (79>>2) = 316.
Plus the low value "3" = 319

Returning, this, in the old version, to Human readable format, it was multiplied by 10, and then divided by 4. Giving 797.5

I assume, that something has changed, with the sensor output format. Thus, the new return formula would be:

	Multi by 1000, divide by 4.

Now we have 79750.

Throwing in the 0.088 Correction Factor the final result is:
79750* 0.088 = 70180 Milidegrees Celsius

Or 319 * 880 /4 = 70180

Or 319 * 220 = 70180

If this was "temp3" , it would result in 1 sensors.conf line:

Compute temp3 @

Is my final concussing Right?

If so, I will move on to the voltage part :) If not, I Hope somebody can point me out where to go...

http://tser.org/vt8231/

Regards
Reinder Kraaij.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

We're not closed :)

However, this does not mean that each and every mail is answered here.

Sorry, I don't have any experience with 12c.
--
vda

Hm, try asking this on the sensors mailing list, they should be able to help you out better than I about this topic.

thanks,

greg k-h

This particular patch, along w/ the new 20040715 ACPI drop has made
my nc6000 laptop unusable. The problem is we're exposing a device that firmware considers hidden. The new motherboard driver in ACPI goes out and tries to claim resources to prevent them from being stepped on. It rightfully considers the hidden SMBus device a motherboard resource. The PCI code then stumbles onto this device, sees that the BAR it's using is unavailable and moves it somewhere else in the address space. At this point, I lose two for the three thermal zones on the laptop because the AML that deals with them assumes they haven't moved.

I'm not sure what the point on un-hiding this devices it. ACPI sets
up an OpRegion to access this device and should have exclusive access to that region. Letting a sensor driver poke at it may be fun, but I'd rather not fry my laptop. Can we drop the un-hiding of the SMBus for this laptop (probably the nc8000 too), or is there some way to make the ACPI motherboard driver and this quirk live together? Thanks,

Alex

Alex Williamson                             HP Linux & Open Source Lab

See the bugzilla.kernel.org bug #3191 for more information.

If someone can come up with a patch that works for everyone, I'll be glad to apply it.

thanks,

greg k-h

Hmm.. Why exactly does the PCI layer re-locate the IO ports?

Afaik, ACPI requesting the region shouldn't matter. The "request_resource()" should still be happy..

Ahh. I see the problem. Because the ACPI code allocates the sub-resources, the request_resource thing is indeed not happy.

How about this _trivial_ change? Does that fix things for you guys? Can you send the /proc/ioport output if this works out for you, just so that we can see?

(The difference between "request_resource()" and "insert_resource()" is that the latter accepts pre-existing sub-resources that the firmware might have allocated within the resource we have..)

Linus

===== arch/i386/pci/i386.c 1.16 vs edited =====

@@ -142,7 +142,7 @@
 				DBG("PCI: Resource %08lx-%08lx (f=%lx, d=%d, p=%d)\n",
 				    r->start, r->end, r->flags, disabled, pass);
 				pr = pci_find_parent_resource(dev, r);
-				if (!pr || request_resource(pr, r) < 0) {
+				if (!pr || insert_resource(pr, r) < 0) {
 					printk(KERN_ERR "PCI: Cannot allocate resource region %d of device %s\n", idx, pci_name(dev));
 					/* We'll assign a new address later */
 					r->end -= r->start;

Yes, this works. Please commit. I still have reservations about
exposing this device (that firmware owns and we can't possibly synchronize access to), but this is a big improvement over the unusable state w/o this change. Here's my /proc/ioports:

0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
03c0-03df : vga+
03e8-03ef : serial
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
1000-107f : motherboard

    1000-1003 : PM1a_EVT_BLK
    1004-1005 : PM1a_CNT_BLK
    1008-100b : PM_TMR
    1010-1015 : ACPI CPU throttle
    1020-1020 : PM2_CNT_BLK
    1028-102f : GPE0_BLK

1100-113f : 0000:00:1f.0
1100-113f : motherboard
1200-121f : motherboard
1200-121f : 0000:00:1f.3
2000-2fff : PCI Bus #01
2000-20ff : 0000:01:00.0

    2000-20ff : radeonfb

3000-30ff : 0000:00:1f.5
3400-34ff : 0000:00:1f.6
3400-34ff : Intel 82801DB-ICH4 Modem - AC'97
3800-387f : 0000:00:1f.6
3800-387f : Intel 82801DB-ICH4 Modem - Controller
3880-38bf : 0000:00:1f.5
38c0-38df : 0000:00:1d.0
38c0-38df : uhci_hcd
38e0-38ff : 0000:00:1d.1
38e0-38ff : uhci_hcd
3c00-3c1f : 0000:00:1d.2
3c00-3c1f : uhci_hcd
3c20-3c2f : 0000:00:1f.1
3c20-3c27 : ide0
3c28-3c2f : ide1
4000-40ff : PCI CardBus #03
4400-44ff : PCI CardBus #03
4800-48ff : PCI CardBus #07
4c00-4cff : PCI CardBus #07
5000-50ff : PCI CardBus #0b
5400-54ff : PCI CardBus #0b

Thanks,

Alex

Alex Williamson                             HP Linux & Open Source Lab

BTW, this is the resource that was in conflict. Thanks,

Alex

Alex Williamson                             HP Linux & Open Source Lab

Greg? Opinions? I'll happily commit it, since it's almost certainly bound to be better than what we have now, but I have to admit that I could also see it causing confusion if two devices are set up by the BIOS to be on top of each other (since insert_resource() would indeed allow that).

Now, admittedly, that would be a VERY broken BIOS, and likely such a situation wouldn't have worked _anyway_, but you're the PCI maintainer, so you get to sit in the hot seat and say aye or nay.

In general, it's always a good idea to expose the devices, because if you don't, other device drivers may end up thinking part of the addresses are free for the taking. Which is why we have ACPI do it's things too.

Nice and readable.

Same.

This is apparently the one that used to cause trouble, and you can see it from the nesting level: the device nests inside the description, rather than the other way around.

This does bring up an alternate fix: namely to do the PCI quirks _earlier_.

If we had done the PCI quirk handling and probing for this device _before_ ACPI populated the IO stuff, and we'd never have seen this problem. Why did we let ACPI come in first in the first place? Greg? Len?

The right order (I think) should be:
- walk the existing PCI setup, do the header quirks, populate the device and resource trees..
- _than_ do the ACPI resources

The allocation of new PCI resources will happen much later - if/when the device is actually enabled.

Or am I missing something?

Linus

It looks correct to me, please apply it. If it breaks people's boxes that used to work, I'm sure I'll hear about it :)

I don't really know, I think that happened before both Len and I took over this code base. I don't have a problem with doing it in this order, but I'm sure there's some ACPI issue that I'm not aware of that needs to be run first.

For a box such as this one, it would make sense to do it in this order, I agree.

thanks,

greg k-h

It didn't break my finicky little laptop, so it's fine with me.

thanks,

greg k-h