0

The latest SMBus spec V3.0 20th Dec 2014 shows only one type of block write/read (excluding block process call):

6.5.7 Block Write/Read
Write: Address(Wr), Command, Count = N, Byte 1, Byte 2, ..., Byte N [, PEC]
Read:  Address(Wr), Command, Address(Rd), Count = N, Byte 1, Byte 2, ..., Byte N [, PEC]

However, looking at the Linux user-space interface, there are 3 block transaction types to use with ioctl I2C_SMBUS from uapi/linux/i2c.h: 

#define I2C_SMBUS_BLOCK_DATA        5
#define I2C_SMBUS_I2C_BLOCK_BROKEN  6
#define I2C_SMBUS_I2C_BLOCK_DATA    8

Following the code under drivers/i2c/* it delegates to smbus_xfer/master_xfer(if emulated) in i2c_algorithm, which is specific to an adapter/device.

1. Do all these transaction types end up following the block wire spec for SMBus 3.0?
2. And how would I decide which one I need to use?

I am creating a Java JNA interface on Raspbian GNU/Linux 10 (buster)

boot-and-bonnet
  • 731
  • 2
  • 5
  • 16
  • `I2C_FUNCS` ioctl returned `I2C_FUNC_SMBUS_WRITE_BLOCK_DATA, I2C_FUNC_SMBUS_READ_I2C_BLOCK, I2C_FUNC_SMBUS_WRITE_I2C_BLOCK` so I guess I only have one choice for block reads. 2 choices for writes though. – boot-and-bonnet May 05 '20 at 07:44

1 Answers1

1
  1. Do all these transaction types end up following the block wire spec for SMBus 3.0?

At the moment I'm writing the answer, I2C module within Linux kernel still doesn't support SMBus 3.0/3.1. It implements SMBus 2.0 communication.

And for the 3 types - this can't be answered. I guess no. To learn how these commands work, look into KMD sources. For example, I2C_SMBUS_I2C_BLOCK_BROKEN gets converted into I2C_SMBUS_I2C_BLOCK_DATA with the following comment:

        /* Convert old I2C block commands to the new
       convention. This preserves binary compatibility. */

And whether I2C_SMBUS_I2C_BLOCK_DATA follows block data protocol - it's up to the user. The command which does enforce the protocol is I2C_SMBUS_BLOCK_DATA.

  1. And how would I decide which one I need to use?

If you want to just use block protocol, then just use I2C_SMBUS_BLOCK_DATA.

If you want more control, or want to overcome restrictions from SMBus 2.0, you'll have to use I2C_SMBUS_I2C_BLOCK_DATA. Though in these cases you will likely have to move to constructing SMBus messages manually, as I2C_SMBUS_I2C_BLOCK_DATA still keeps you quite restricted - you'll get one more byte in max message length, but it's still far from 255.

If you're writing according to SMBus 1 spec, use I2C_SMBUS_I2C_BLOCK_BROKEN when appropriate.

mefistotelis
  • 170
  • 1
  • 5