eeprom chip driver for 2.6
PATCH 1/1 eeprom chip driver for 2.6
Ok, I finally got the sysfs binary file interface hooked up to the eeprom driver in 2.6. Turned out to be easier than I thought. Below is the patch that I'll be sending to Linus in a bit. If anyone has any comments on it, I'd appreciate it.
thanks,
greg k-h
p.s. I added the Viao check too :)
# I2C: add eeprom i2c chip driver.
#
# This is based on the i2c cvs driver, but ported to 2.6 and rewritten
# to use the sysfs binary file interface.
Documentation/i2c/sysfs-interface +4 -1
@@ -77,7 +77,10 @@ curr_input[1-n] Current input value Fixed point XXXXX, divide by 1000 to get Amps. Read only. - + +eeprom Raw EEPROM data in binary form. + Read only. + fan_min[1-3] Fan minimum value Integer value indicating RPM Read/Write.
drivers/i2c/chips/Kconfig +12 -0
@@ -21,6 +21,18 @@ This driver can also be built as a module. If so, the module will be called adm1021. +config SENSORS_EEPROM + tristate "EEPROM (DIMM) reader" + depends on I2C && EXPERIMENTAL + select I2C_SENSOR + help + If you say yes here you get read-only access to the EEPROM data + available on modern memory DIMMs, and which could theoretically + also be available on other devices. + + This driver can also be built as a module. If so, the module + will be called eeprom. + config SENSORS_IT87 tristate "National Semiconductors IT87 and compatibles" depends on I2C && EXPERIMENTAL
drivers/i2c/chips/Makefile +1 -0
@@ -6,6 +6,7 @@ obj-$(CONFIG_SENSORS_W83781D) += w83781d.o obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o +obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_IT87) += it87.o obj-$(CONFIG_SENSORS_LM75) += lm75.o obj-$(CONFIG_SENSORS_LM78) += lm78.o
drivers/i2c/chips/eeprom.c new file +283 -0
283 lines not on this page · raw message
PATCH 1/1 eeprom chip driver for 2.6
Quoted 7 lines
Ok, I finally got the sysfs binary file interface hooked up to the eeprom driver in 2.6. Turned out to be easier than I thought. Below is the patch that I'll be sending to Linus in a bit. If anyone has any comments on it, I'd appreciate it.
p.s. I added the Viao check too :)
Thanks :) BTW, where is my name? ;)) (just kidding)
Overall, it's OK for me. I'm still concerned by the performance issue. This driver will be far "slower" than current CVS' one (from sensors' point of view) but this has already been discussed and I have no concrete solution to propose, so let's forget about it.
drivers/i2c/chips/eeprom.c line 55
Quoted 7 lines
drivers/i2c/chips/eeprom.c new file +6
-0+/* EEPROM memory types: */ +#define ONE_K 1 +#define TWO_K 2 +#define FOUR_K 3 +#define EIGHT_K 4 +#define SIXTEEN_K 5
This could go away, the defines are unused as far as I can tell.
Signature · 5 lines
Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHQuoted 3 lines
Ah, yeah, that probably will not work now.
Oh well, we don't really need to worry about speed here :)
I do, but I am obviously the only one ;) (well, all I2C devices I have in my laptop are two EEPROMS, that may be why). But I admit it is not really important.
Still I believe that a slow eeprom driver means that we should not handle eeproms in the sensors program. There are special scripts to decode eeproms, that do a much better job.
Signature · 5 lines
Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHQuoted 6 lines · Jean Delvare
Quoted 5 lines
Ok, I finally got the sysfs binary file interface hooked up to the eeprom driver in 2.6. Turned out to be easier than I thought. Below is the patch that I'll be sending to Linus in a bit. If anyone has any comments on it, I'd appreciate it.
Quoted 8 lines
Quoted 1 line
p.s. I added the Viao check too :)
Thanks :) BTW, where is my name? ;)) (just kidding)
Overall, it's OK for me. I'm still concerned by the performance issue. This driver will be far "slower" than current CVS' one (from sensors' point of view) but this has already been discussed and I have no concrete solution to propose, so let's forget about it.
Ah, missed that part of your change to the driver. Patches are always welcome :)
Quoted 9 lines
drivers/i2c/chips/eeprom.c line 55
Quoted 7 lines
drivers/i2c/chips/eeprom.c new file +6
-0+/* EEPROM memory types: */ +#define ONE_K 1 +#define TWO_K 2 +#define FOUR_K 3 +#define EIGHT_K 4 +#define SIXTEEN_K 5This could go away, the defines are unused as far as I can tell.
Looks that way, thanks. Same thing for the cvs version too...
greg k-h
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHQuoted 9 lines · Philip Pokorny
In the following loop:
+ for (i=0; i <
EEPROM_SIZE; i +=I2C_SMBUS_I2C_BLOCK_MAX)(quoted diff) +1
-0+ if (i2c_smbus_read_i2c_block_data(client, i, data->data + i) !=
I2C_SMBUS_I2C_BLOCK_MAX)Is it possible that
EEPROM_SIZEmight not be a multiple of the SMBus block size? Is there a way to read less than a full block of data other than a byte at a time?
Probably, I left this alone from what used to be in the cvs tree. Now it looks like it's been changed.
Quoted 4 lines
Should
EEPROM_SIZEbe configurable? Or is the limitation that addresses must be a single byte? I recall that being a problem when I wanted to address the EEPROM memory included in one of the monitoring chip drivers I wrote.
I thought I remembered some mention of different sized eeproms. And yes, it could be made configurable if people need that in the future.
thanks for taking a look at it.
greg k-h
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHQuoted 9 lines · Jean Delvare
Quoted 8 lines
Quoted 5 lines
Overall, it's OK for me. I'm still concerned by the performance issue. This driver will be far "slower" than current CVS' one (from sensors' point of view) but this has already been discussed and I have no concrete solution to propose, so let's forget about it.
Ah, missed that part of your change to the driver. Patches are always welcome :)
Quoted 8 lines
I'm not sure something can be done. If I understood it correctly, you now have one single binary file. The trick I introduced in the CVS driver was to refresh the EEPROM contents by rows (32 bytes) instead of reading it all at once. It allowed faster response on "queries" that were only affecting one part of the EEPROM. It fitted our driver structure rather well because the EEPROM is split over 16 16-value files. Now that there is a single file, I suppose that nothing similar can be done. Of course, if you do have an idea, let us know.
Ah, yeah, that probably will not work now.
Oh well, we don't really need to worry about speed here :)
thanks,
greg k-h
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHQuoted 8 lines
Quoted 5 lines
Overall, it's OK for me. I'm still concerned by the performance issue. This driver will be far "slower" than current CVS' one (from sensors' point of view) but this has already been discussed and I have no concrete solution to propose, so let's forget about it.
Ah, missed that part of your change to the driver. Patches are always welcome :)
I'm not sure something can be done. If I understood it correctly, you now have one single binary file. The trick I introduced in the CVS driver was to refresh the EEPROM contents by rows (32 bytes) instead of reading it all at once. It allowed faster response on "queries" that were only affecting one part of the EEPROM. It fitted our driver structure rather well because the EEPROM is split over 16 16-value files. Now that there is a single file, I suppose that nothing similar can be done. Of course, if you do have an idea, let us know.
Quoted 11 lines
Quoted 9 lines
drivers/i2c/chips/eeprom.c line 55
Quoted 7 lines
drivers/i2c/chips/eeprom.c new file +6
-0+/* EEPROM memory types: */ +#define ONE_K 1 +#define TWO_K 2 +#define FOUR_K 3 +#define EIGHT_K 4 +#define SIXTEEN_K 5This could go away, the defines are unused as far as I can tell.
Looks that way, thanks. Same thing for the cvs version too...
Done.
Signature · 2 lines
Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
PATCH 1/1 eeprom chip driver for 2.6
In reply to Greg KHIn the following loop:
+ for (i=0; i < EEPROM_SIZE; i += I2C_SMBUS_I2C_BLOCK_MAX)
+ if (i2c_smbus_read_i2c_block_data(client, i, data->data + i) !=I2C_SMBUS_I2C_BLOCK_MAX)
Is it possible that EEPROM_SIZE might not be a multiple of the SMBus block size? Is there a way to read less than a full block of data other than a byte at a time?
Should EEPROM_SIZE be configurable? Or is the limitation that addresses must be a single byte? I recall that being a problem when I wanted to address the EEPROM memory included in one of the monitoring chip drivers I wrote.
:v)
Quoted 15 lines · Greg KH
Ok, I finally got the sysfs binary file interface hooked up to the eeprom driver in 2.6. Turned out to be easier than I thought. Below is the patch that I'll be sending to Linus in a bit. If anyone has any comments on it, I'd appreciate it.
thanks,
greg k-h
p.s. I added the Viao check too :)
# I2C: add eeprom i2c chip driver.
#
# This is based on the i2c cvs driver, but ported to 2.6 and rewritten# to use the sysfs binary file interface.
Signature · 4 lines
Philip Pokorny, Director of Engineering Tel: 415-358-2635 Fax: 415-358-2646 Toll Free: 888-PENGUIN PENGUIN COMPUTING, INC. www.penguincomputing.com