Need advice, writing new driver.
mds at paradyne.com
Sun Dec 14 01:56:06 CET 2003
Most likely you do this by setting the 801 to i2c mode and using
what 801 calls the i2c variant of the process call. (two bytes at a
I don't see any way to get block reads w/ two-byte addresses to work on
If you see any other way to do it let us know.
In either case the steps to follow would be:
- define new functionality in i2c.h (already done for 2-byte block
- define new transaction type in i2c.h
- add support for the transaction to i2c-i801
- add support for the transaction to i2c-core
- (extra credit) add support for smbus emulation of the transaction
on i2c adapters to i2c-core.
- decide how to access the data - mods to eeprom or new driver,
mods to i2cdump, mods to i2c-dev.h, ... (see
doc/developers/applications for your options)
- implement whatever you decide
- send us a patch
Sean S Fendt wrote:
> Hello all,
> My name is Sean Fendt, I'm employed by Octagon Systems to provide Linux
> support on their line of industrial single board computers and expansion
> cards. Right now, I'm working on the model PC770, an EBX Formfactor Pentium
> 3, based on the Intel 815 chipset.
> I need to support a MicroChip 24LC32A (24C32) EEPROM on the SM Bus. How
> should I proceed?
> Octagon includes in their CPU boards, an Octagon Specific Serial EEPROM.
> This has several purposes:
> 1. As an industrial PC, the system BIOS is modified to store all setup
> configuration in the serial EEPROM, so no battery is required for retention
> of configuration data.
> 2. Production test results, custom configurations, serial numbers, PO
> numbers, and much other production data is also stored in this device.
> 3. (The one I care about). The top 50% of the EEPROM is available for USER
> DATA. The user can do whatever they want with it. I intend to provide a
> driver that only accesses this space.
> In past products, I've either had a regular I2C controller (I wrote a full
> kernel I2C driver for the ZF Mach's Access Bus), or a bit-bang interface
> created out of a few chipset GPIO lines (done on all of Octagon's GX1
> Now, however, in the i815 chipset has an SM Bus. So, the hardware group
> decided to connect our EEPROM to the SM Bus, along with our standard DS1775
> Temp Sensor, the EEPROM interface on the SDRAM socket, and the clock
> Our EEPROM is hardwired to address 0x51, as to not conflict with the SDRAM's
> EEPROM at 0x50. The DS1775 works fine with the lm75 driver, and the click
> generator is something we don't want to give users easy access to anyhow.
> The following, I already know:
> The group doing octagon's extended BIOS functions (extended int 17 calls) can
> access the device on the SM Bus, so the hardware is capable of the necessary
> commands. (They have discovered, however, they must do a block write, not a
> byte or word write for it to function correctly).
> The i801 driver which supports the SM Bus on our board, does not support
> i2c-level commands. How much trouble will I have if I decide to extend this
> driver to allow at least some i2c-level commands?
> Is there some other way I can support the 2-byte address EEPROMs without
> extending the driver to allow i2c-level commands?
> Would I be better off to just start over from scratch, write my own bus
> driver, and use my old EEPROM and DS1775 drivers (which are not lm-sensors
> compatable)? I have permission from the company to submit my work in this
> area to the lm sensors project, which I'd rather do, but if it just doesn't
> make sens, I could start a completely new bus driver.
> -- Sean Fendt
> sfendt at octagonsystems.com
> Ph: 303 430 1500 Ext 3048
More information about the lm-sensors