SMBus process call, block process call and PEC are not supported in raspberry pi 5

[davesliu]

Describe the bug

Hello,

I found that raspberry pi 5 use the Synopsys designware i2c adapter, but it seems that this i2c adapter doesn't support SMBus process call, block process call and PEC as shown in below macro definition.

https://github.com/raspberrypi/linux/blob/ccf75f2a6f4045484c4539f7d47264f8f6b8453c/drivers/i2c/busses/i2c-designware-core.h#L21

Per my understanding, there should be no difficulty to implement SMBus process call as the data sequence is fixed. And for SMBus block process call, it combines the SMBus block writing and block reading. As it already supports SMBus block reading now compared with rpi4.

So it is possible to implement these features for rpi-5?

Thanks

Steps to reproduce the behaviour

Run the i2cdtect command and it shows the SMBus Process Call, SMBus Block Process Call and SMBus PEC are not supported.

$ i2cdetect -F 1 Functionalities implemented by /dev/i2c-1: I2C yes SMBus Quick Command yes SMBus Send Byte yes SMBus Receive Byte yes SMBus Write Byte yes SMBus Read Byte yes SMBus Write Word yes SMBus Read Word yes SMBus Process Call no SMBus Block Write yes SMBus Block Read yes SMBus Block Process Call no SMBus PEC no I2C Block Write yes I2C Block Read yes

Device (s)

Other

System

on raspberry pi 5

Logs

No response

Additional context

No response

[P33M]

The I2C block on RP1 supports SMBUS Process Call and Block Process Call. It's a matter of adding driver support. In master mode, software generates the PEC byte and appends it to the write data, or reads it out of the FIFO and verifies it. The block doesn't support auto-checking of the PEC byte in slave mode.

[6by9]

Pi0-4 get that functionality via I2C_FUNC_SMBUS_EMUL providing the emulation on top of an I2C driver.

Pi5 isn't using that, but also isn't providing the same function in the driver. It should be possible to largely just lift the emulation code into the driver. It may be that just adding the relevant flags to the functionality means that the emulation takes over the bits that it needs to - I haven't followed that through yet.

[P33M]

There shouldn't be a need to add a layer of I2C to SMBUS emulation - the SMBUS access methods are explicitly supported in hardware.

[davesliu]

@P33M and @6by9 Thank you for your comments.

So can I just modify the line https://github.com/raspberrypi/linux/blob/ccf75f2a6f4045484c4539f7d47264f8f6b8453c/drivers/i2c/busses/i2c-designware-core.h#L21 to add the I2C_FUNC_SMBUS_PROC_CALL and I2C_FUNC_SMBUS_BLOCK_PROC_CALL to enable the function?

Or do I need to do extra work?

As it seems that there is no documentation for the Synopsys designware I2C adapter for https://github.com/raspberrypi/linux/blob/ccf75f2a6f4045484c4539f7d47264f8f6b8453c/drivers/i2c/busses/i2c-designware-master.c, not sure if just update above macro definition is enough or not....

[pelwell]

This may be something we can add to the dwc-i2c driver, but it is not likely to be a high priority.

[davesliu]

@pelwell Currently we use the I2C-GPIO to simulate the fully SMBus protocol but it's not perfect due to the clock period is not accurate enough as we can't set float type time delay for 400K bit/s and it can't support 1M bit/s when using I2C-GPIO to simulate the SMBus communication. We want to use rpi-5's block hardware I2C controller as its clock period is accurate and can support 400K bit/s and 1Mbit/s

In fact, we mainly use the PMBus command sets, some PMBus command are based on SMBus block process call, so that' why we want the feature of Synopsys designware i2c adapter

[pelwell]

It's on the list of things to do - just don't hold your breath...

[pelwell]

Do you have any kind of simple example code that demonstrates the use of the SMBus/PMBus commands?

[davesliu]

@pelwell

Below snapshot is an example of SMBus block process call and data sequence.

Take the use of function   extern s32 i2c_smbus_block_process_call(int file, u8 command, u8 length, u8 *values); that defined in i2c-tools header files as example https://kernel.googlesource.com/pub/scm/utils/i2c-tools/i2c-tools/+/refs/heads/master/include/i2c/smbus.h

In function i2c_smbus_block_process_call(), the parameter setting are: file=the handle of I2C controller, command=0x6, length=2,
*value= {0x00, 0x21}

These values will be written to SMBus slave device as shown in above sequence. And it returns a block of data ( the first byte is the read length 0x2, the second and third byte are data 0 and data 1 that read from SMBus slave device.

[pelwell]

Thanks. Can you suggest some simple, cheap devices (ideally on modules) that implement the calls you are interested in?

[davesliu]

we foucus on power chips related software that to B customer (not to C customer), so to be honest I don't know other simple cheap devices that will use smbus block process call.

But for power chips that support PMBus commands set (PMBus can be considered as applications of SMBus protocol ), some pmbus command such as "read page plus" or "read page plus" that needs the SMBus block process call feature.

[davesliu]

@pelwell

I tried the SMBus block process call functions on Linux application level and it failed at the block reading part as I2C adapter truncate the reading by send NACK after it gets the data length 0x2 and first data content 0x00.

The real root cause is SMBus block reading bug of the Synopsys DesignWare I2C adapter as I submitted in https://github.com/raspberrypi/linux/issues/5796

If that bug is fixed. I think the SMBus block process call feature will work automatically.