Hi Krzysztof, > Forgive my ignorance, but does it depend on the south bridge at all? > Isn't the block read capability just a function of EEPROM chip on > (I assume) RAM module? EEPROMs can be read using three different access modes: data byte reads (each transaction asks for one byte at a given offset), continuous byte reads (first transaction sets offset to 0, each subsequent transaction reads one byte and the offset auto-increments), and I2C block reads (one single transaction sets the initial offset and reads the whole block [1]). Now, just because most EEPROMs support these three modes doesn't mean you can always use them. It depends on which bus the EEPROM is sitting on, and which driver is used to control that bus. If the bus is a true I2C bus, most of which are known as bit-banging and are driven by the i2c-algo-bit driver, then all three types of accesses will work, and we'll use I2C block reads because it's faster. However, EEPROMs are also often found on SMBus busses, those controller only implement a subset of all possible I2C commands. Where this subset includes I2C block reads, we can implement it in the driver and use it. This is exactly what I am doing with i2c-viapro right now. More generally, for an I2C/SMBus command to be usable, both the target chip and the bus controller must support it, and the bus controller driver must implement it. I hope it's clearer now :) [1] Due to an internal limitation in the Linux kernel, the maximum block size that can be read is actually 32 bytes, so several block reads are needed to retrieve larger chunks of data. -- Jean Delvare
