Messages in this thread | | | Subject | Re: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes. | From | Marek Vasut <> | Date | Tue, 20 Jul 2021 23:43:54 +0200 |
| |
On 7/20/21 4:19 PM, Raviteja Narayanam wrote:
Hi,
[...]
>>> I have tested this again on our boards with eeprom and other sensors, this >> is working fine for us. >> >> Can you share details of how those tests were performed ? > > Stress test - 1: > Heavy ethernet traffic running in the background. > I2c commands script (like below) running. We can see visible stutter in the output as expected, but nothing failed. > > i=0 > while [ 1 ] > do > i2ctransfer -y -f 2 w1@0X54 0X00 r31@0X54 > i2ctransfer -y -f 2 w1@0X54 0X00 r32@0X54 > i2ctransfer -y -f 2 w1@0X54 0X00 r255@0X54 > i2ctransfer -y -f 2 w1@0X54 0X00 r273@0X54 > i2ctransfer -y -f 2 w1@0X54 0X00 r1@0X54
Could it be that you never see the problem because you always talk to one single device ?
Do you also test writes which are not 1 byte long ?
> i=$(expr $i + 1) > echo "$i" > done > > Stress test - 2: > Two i2c scripts running in parallel with commands as shown above with different bus numbers (as a result of mux), but going into same XIIC adapter. > This is also working fine.
Could it be the i2c-dev serializes each of those transfers , so no race can be triggered ?
> Stress test - 3: > Two i2c scripts running in parallel with same commands in separate terminals. This is also working fine. > > From your log, the race condition is occurring at boot time during i2c clients registration. I am starting a similar test at my setup > to reproduce this issue at boot time.
Thank you
| |