On 8/14/26 04:08, Jamin Lin wrote:
An SMBus block read takes the block length from the first byte of the
transfer, and firmware reads that byte back from a register rather than
from the transfer buffer. The receive paths never updated those
registers, so block reads reported a bogus length.

On AST2600 the driver reads the length from the receive byte buffer,
I2CC_MS_TXRX_BYTE_BUF[15:8]. The datasheet documents that field as valid
while the DMA buffer is not enabled. The byte mode receive path already
updated it, but the pool buffer path did not, and the driver selects
buffer mode by default.

On AST2700 the driver reads the length from offset 0x84 instead.

Add I2CC_BYTE_DATA_LOG at 0x84 and latch received bytes into it. The pool
buffer, DMA-to-pool and DMA-to-DRAM paths latch their first byte, the byte
mode path latches every byte. Each latch also updates the receive byte
buffer unless RX_DMA_EN is set, which is the datasheet condition and does
not depend on FUNC_CFG_DMA_EN. The byte data log only exists on AST2700
and AST1040, so it is gated on a class flag.

Signed-off-by: Jamin Lin <[email protected]>
Tested-by: Mikail Sadic <[email protected]>
---
  hw/i2c/aspeed_i2c.c         | 38 +++++++++++++++++++++++++++++++++++--
  include/hw/i2c/aspeed_i2c.h |  3 +++
  2 files changed, 39 insertions(+), 2 deletions(-)
Applied to

    https://github.com/legoater/qemu aspeed-next

Thanks,

C.



Reply via email to