Ian Campbell wrote:
> On Sun, 2004-12-05 at 13:53 +0100, Jean Delvare wrote:
>
>>Also, I think that what you do with i2c_transfer is similar to
>>I2C_FUNC_SMBUS_READ_I2C_BLOCK, which is supported by some SMBus
>>(non-I2C) masters.
>
>
> I've checked it out and I don't think they are similar enough, however I
> would appreciate your input.
>
> The ds1338 (same i2c interface as ds1307 and I just happen to have the
> data sheet in front of me) expects a write (slave receiving) to look
> like this (I hope my notation makes sense...)
>
> S <slave addr> W ACK <address(n)> A <data(n)> A <data(n+1)> A <....> A P
>
> Where address(n) sets the register address to start writing at. There
> are then as many data bytes as you like, each acknowledged, followed by
> the stop bit.
>
> SMBUS block write is
>
> S <slave_addr> W A <command> A <count> A <data(1)> A <....> <data(count)> A P
>
> The SMBUS <command> could be considered to be the ds1338 <address(n)>
> but then there is an extra byte in the smbus for the count.
>
> The read commands follow the same basic scheme in both cases.
>
> I can't see another SMBUS transfer that would fit, unless there is some
> sort of 'repeated send byte' that I haven't spotted.
>
The I2C_FUNC_SMBUS_{READ|WRITE}_I2C_BLOCK functionalities are "true" i2c block transfers,
not smbus transfers; don't let the name fool you.
> On a separate thread -- I had a thought that perhaps I2C_FUNC_I2C should
> include the SMBUS_EMUL definitions since (I think you said) that any i2c
> device can emulate smbus...
I2C_FUNC_I2C was defined at the very beginnning (and documented in doc/functionality in the i2c tree)
but never used by anything in the i2c or sensors tree; it looks pretty much forgotten.
So chip drivers looking for that functionality bit won't find it anywhere.
I think the best way to fix it is to add I2C_FUNC_I2C to the I2C_FUNC_SMBUS_EMUL bitmask in i2c.h.
Then everyone should be happy.
comments?
