Need advice, writing new driver.

[Mark Studebaker]

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