2005-06-03 21:03:27 +04:00
Kernel driver max6875
=====================
Supported chips:
2005-06-24 01:37:53 +04:00
* Maxim MAX6874, MAX6875
Prefix: 'max6875'
2005-07-12 22:21:50 +04:00
Addresses scanned: None (see below)
2005-06-24 01:37:53 +04:00
Datasheet:
2005-06-03 21:03:27 +04:00
http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
Author: Ben Gardner <bgardner@wabtec.com>
Description
-----------
2005-06-24 01:37:53 +04:00
The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
2005-06-03 21:03:27 +04:00
It provides timed outputs that can be used as a watchdog, if properly wired.
It also provides 512 bytes of user EEPROM.
2005-06-24 01:37:53 +04:00
At reset, the MAX6875 reads the configuration EEPROM into its configuration
2005-06-03 21:03:27 +04:00
registers. The chip then begins to operate according to the values in the
registers.
2005-06-24 01:37:53 +04:00
The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
and outputs:
vin gpi vout
MAX6874 6 4 8
MAX6875 4 3 5
2005-07-12 22:21:50 +04:00
See the datasheet for more information.
2005-06-03 21:03:27 +04:00
Sysfs entries
-------------
2005-07-12 22:21:50 +04:00
eeprom - 512 bytes of user-defined EEPROM space.
2005-06-03 21:03:27 +04:00
General Remarks
---------------
2005-07-12 22:21:50 +04:00
Valid addresses for the MAX6875 are 0x50 and 0x52.
Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56.
The driver does not probe any address, so you must force the address.
Example:
$ modprobe max6875 force=0,0x50
The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
addresses. For example, for address 0x50, it also reserves 0x51.
2005-07-27 21:43:21 +04:00
The even-address instance is called 'max6875', the odd one is 'max6875 subclient'.
2005-07-12 22:21:50 +04:00
Programming the chip using i2c-dev
----------------------------------
Use the i2c-dev interface to access and program the chips.
2005-07-27 21:43:21 +04:00
Reads and writes are performed differently depending on the address range.
2005-07-12 22:21:50 +04:00
The configuration registers are at addresses 0x00 - 0x45.
Use i2c_smbus_write_byte_data() to write a register and
i2c_smbus_read_byte_data() to read a register.
The command is the register number.
Examples:
To write a 1 to register 0x45:
i2c_smbus_write_byte_data(fd, 0x45, 1);
To read register 0x45:
value = i2c_smbus_read_byte_data(fd, 0x45);
The configuration EEPROM is at addresses 0x8000 - 0x8045.
The user EEPROM is at addresses 0x8100 - 0x82ff.
Use i2c_smbus_write_word_data() to write a byte to EEPROM.
The command is the upper byte of the address: 0x80, 0x81, or 0x82.
The data word is the lower part of the address or'd with data << 8.
cmd = address >> 8;
val = (address & 0xff) | (data << 8);
Example:
To write 0x5a to address 0x8003:
i2c_smbus_write_word_data(fd, 0x80, 0x5a03);
Reading data from the EEPROM is a little more complicated.
Use i2c_smbus_write_byte_data() to set the read address and then
i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data.
Example:
To read data starting at offset 0x8100, first set the address:
i2c_smbus_write_byte_data(fd, 0x81, 0x00);
And then read the data
value = i2c_smbus_read_byte(fd);
or
i2c: Fix the i2c_smbus_read_i2c_block_data() prototype
Let the drivers specify how many bytes they want to read with
i2c_smbus_read_i2c_block_data(). So far, the block count was
hard-coded to I2C_SMBUS_BLOCK_MAX (32), which did not make much sense.
Many driver authors complained about this before, and I believe it's
about time to fix it. Right now, authors have to do technically stupid
things, such as individual byte reads or full-fledged I2C messaging,
to work around the problem. We do not want to encourage that.
I even found that some bus drivers (e.g. i2c-amd8111) already
implemented I2C block read the "right" way, that is, they didn't
follow the old, broken standard. The fact that it was never noticed
before just shows how little i2c_smbus_read_i2c_block_data() was used,
which isn't that surprising given how broken its prototype was so far.
There are some obvious compatiblity considerations:
* This changes the i2c_smbus_read_i2c_block_data() prototype. Users
outside the kernel tree will notice at compilation time, and will
have to update their code.
* User-space has access to i2c_smbus_xfer() directly using i2c-dev, so
the changed expectations would affect tools such as i2cdump. In order
to preserve binary compatibility, we give I2C_SMBUS_I2C_BLOCK_DATA
a new numeric value, and define I2C_SMBUS_I2C_BLOCK_BROKEN with the
old numeric value. When i2c-dev receives a transaction with the
old value, it can convert it to the new format on the fly.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2007-07-12 16:12:29 +04:00
count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer);
2005-07-12 22:21:50 +04:00
The block read should read 16 bytes.
0x84 is the block read command.
See the datasheet for more details.
2005-06-03 21:03:27 +04:00