i2c-xiic: An error occurs while handling RX irq

[Michal Simek]

++




On 1/7/22 08:18, Jeaho Hwang wrote:
>>
>> 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)
>>

Shubhrajyoti: Please take a look at it.

M