Messages in this thread |  | | Subject | Re: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes. | From | Marek Vasut <> | Date | Mon, 26 Jul 2021 15:12:44 +0200 |
| |
On 7/26/21 7:26 AM, 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 ? > > There are transfers to other devices as well.
The above test only accesses device at address 0x54, right ?
> Our board has multiple power monitors, eeprom and other misc devices that > are accessed through the same driver and are working fine.
That does not seem to be what the test above does .
>> Do you also test writes which are not 1 byte long ? >> > > Yes, like for eeprom 1 page (16 bytes) is written.
I suspect the atmel mxt does much longer writes, try 255 bytes or so.
>>> 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 ? >> > > Yes, that is true because all our tests are going through the i2c-core only > and there is a lock at adapter level in the core. > It has to be reproducible through the i2c standard interface, which is not > happening at our setup. > > I can take your patches that are targeted for this issue, rebase, test > and send them.
I think you and Michal talked about getting the atmel mxt touchscreen, so you can test that yourself as well.
|  |