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 time). I don't see any way to get block reads w/ two-byte addresses to work on the 801. 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 read) - 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 - test - 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? > > Background: > 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 > designs). > > 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 > generator. > > 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
