[PATCH 2.6] i2c-algo-bit should support I2C_FUNC_I2C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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...

Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux