Re: I2C block reads with i2c-viapro: testers wanted

[Jean Delvare <khali@linux-fr.org>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/