i2c-xiic: An error occurs while handling RX irq

[Jeaho Hwang]

>
> Hello xilinx and arm linux experts.
> We are testing periodic send & recv i2c msgs on zynq7000 based target
> board. It shows -5(EIO) errors rarely and works fine again from the
> next period.
> We use the Linux kernel 5.4.0 provided by Petalinux 2021.2, with
> RT-patch. Investigating the code I think the RT patch would not affect
> this symptom. We will also try to reproduce it with non-preempt-RT
> configuration.
> The debug log is attached below.

Hello. We investigated more and got the reason for the error return.

In general cases, 3 interrupts were raised for one i2c read as following log.

xiic_start_recv entry, ISR: 0xd0, CR: 0x1
xiic_isr entry
xiic_process: IER: 0x1b, ISR: 0xd0, pend: 0x10
xiic_process: SR: 0x8c, msg: f14e832a, nmsgs: 1
xiic_process, ISR: 0xca, CR: 0x1
xiic_process clr: 0x0
-------------------------------------------------------------------
the first irq handler was called by ISR(4): BUS NOT BUSY.
BC xiic_start_recv enabled interrupt but slave didn't start transmission yet.
This is unnecessary and the handler disables the BNB bit and ignores it.

xiic_isr entry
xiic_process: IER: 0x1b, ISR: 0xca, pend: 0xa
xiic_process: SR: 0x8c, msg: f14e832a, nmsgs: 1
xiic_process, ISR: 0xca, CR: 0x1
xiic_read_rx entry, bytes in fifo: 2, rem: 2, SR: 0x8c, CR: 0x1
xiic_process end of message, nmsgs: 1
xiic_process clr: 0xa
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The second irq handler works the real thing.

xiic_isr entry
xiic_process: IER: 0x1b, ISR: 0xd0, pend: 0x10
xiic_process: SR: 0xc8, msg: f14e832a, nmsgs: 1
xiic_process, ISR: 0xd0, CR: 0x1
xiic_process clr: 0x10

the third is raised BC the bus is idle but BNB is still enabled.

sometimes the threaded irq handler for the first irq could be delayed
so ISR could be read as 0xca.
Rarely, ISR could be read 0xC2 if the timing was between TXCOMP set
and RXFULL set.
AS PG090, pp14, RXFULL bit  is not set at the same time as Transmit
Complete bit.

In order to prevent this malfunction, We believe the best option is to
prevent the first irq. Is it possible?
The second option could be the consideration of this timing issue: the
walkaround.
We temporarily implemented the second read of ISR for the case
0x?A(TXCOMP && !RXFULL) and found that it works well.

Do you have better suggestions for this issue?

Happy new year!
Jeaho Hwang

>
> [   95.115539] i2c-dev: i2c-1 reading 2 bytes.
> [   95.115552] xiic-i2c 40700000.i2c: xiic_xfer entry SR: 0xc0
> [   95.115562] xiic-i2c 40700000.i2c: xiic_setclk entry,
> i2c->input_clk: 100000000, i2c->i2c_clk: 0
> [   95.115576] xiic-i2c 40700000.i2c: __xiic_start_xfer entry, msg:
> f14e832a, fifos space: 15
> [   95.115588] xiic-i2c 40700000.i2c: xiic_start_recv entry, ISR: 0xd0, CR: 0x1
> [   95.115605] xiic-i2c 40700000.i2c: xiic_isr entry
> [   95.115674] xiic-i2c 40700000.i2c: xiic_process: IER: 0x1b, ISR:
> 0xc2, pend: 0x2
>
>                            ~~~~~~~~
> [   95.115685] xiic-i2c 40700000.i2c: xiic_process: SR: 0x8c, msg:
> f14e832a, nmsgs: 1
> [   95.115698] xiic-i2c 40700000.i2c: xiic_process, ISR: 0xca, CR: 0x1
>
>          ~~~~~~~~
> [   95.115706] xiic-i2c 40700000.i2c: xiic_process error
>
> BC pend calculated was 0x2(XIIC_INTR_TX_ERROR_MASK without
> RX_FULL_MASK) this pended value is handled as an error. But the latter
> read value of ISR was 0xca, which means normal RX completion. It seems
> that reading ISR is too earlier or updating RXFULL bit is delayed.
>
> I found the second ISR print is added from commit
> a6183c1688142adcf55b11baff95222b47792644, by Raviteja. I wonder this
> or similar cases have been considered before. I also wonder if we
> should add the second chance of reading ISR in similar cases inside
> the irq handler (e.g. drivers/i2c/busses/i2c-xiic.c:635)
>
> Best regards.
> Jeaho Hwang.
> --
> 황재호, Jay Hwang, linux team manager of RTst



-- 
황재호, Jay Hwang, linux team manager of RTst
010-7242-1593