All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Raviteja Narayanam <rna@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	git <git@xilinx.com>, "joe@perches.com" <joe@perches.com>
Subject: Re: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes.
Date: Tue, 20 Jul 2021 23:43:54 +0200	[thread overview]
Message-ID: <328f6c4e-ff0b-c88f-d246-75b493b67a9a@denx.de> (raw)
In-Reply-To: <SN6PR02MB4093C7F2EB59D854D8753A01CAE29@SN6PR02MB4093.namprd02.prod.outlook.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Raviteja Narayanam <rna@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	git <git@xilinx.com>, "joe@perches.com" <joe@perches.com>
Subject: Re: [PATCH v2 00/10] i2c: xiic: Add features, bug fixes.
Date: Tue, 20 Jul 2021 23:43:54 +0200	[thread overview]
Message-ID: <328f6c4e-ff0b-c88f-d246-75b493b67a9a@denx.de> (raw)
In-Reply-To: <SN6PR02MB4093C7F2EB59D854D8753A01CAE29@SN6PR02MB4093.namprd02.prod.outlook.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-20 21:44 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26 10:27 [PATCH v2 00/10] i2c: xiic: Add features, bug fixes Raviteja Narayanam
2021-06-26 10:27 ` Raviteja Narayanam
2021-06-26 10:27 ` [PATCH v2 01/10] i2c: xiic: Fix Tx Interrupt path for grouped messages Raviteja Narayanam
2021-06-26 10:27   ` Raviteja Narayanam
2021-06-26 10:27 ` [PATCH v2 02/10] i2c: xiic: Add standard mode support for > 255 byte read transfers Raviteja Narayanam
2021-06-26 10:27   ` Raviteja Narayanam
2022-06-29 11:02   ` Krzysztof Adamski
2022-06-29 11:02     ` Krzysztof Adamski
2022-06-29 11:39     ` Michal Simek
2022-06-29 11:39       ` Michal Simek
2022-06-29 12:07       ` Krzysztof Adamski
2022-06-29 12:07         ` Krzysztof Adamski
2021-06-26 10:27 ` [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for i2c-read Raviteja Narayanam
2021-06-26 10:27   ` Raviteja Narayanam
2022-06-29 12:47   ` Krzysztof Adamski
2022-06-29 12:47     ` Krzysztof Adamski
2022-06-29 14:05     ` Marek Vasut
2022-06-29 14:05       ` Marek Vasut
2022-06-29 14:09       ` Krzysztof Adamski
2022-06-29 14:09         ` Krzysztof Adamski
2022-06-29 14:34         ` Marek Vasut
2022-06-29 14:34           ` Marek Vasut
2022-06-30  8:23         ` Datta, Shubhrajyoti
2022-06-30  8:23           ` Datta, Shubhrajyoti
2022-07-01  7:01           ` Krzysztof Adamski
2022-07-01  7:01             ` Krzysztof Adamski
2022-07-04  5:45             ` Datta, Shubhrajyoti
2022-07-04  5:45               ` Datta, Shubhrajyoti
2021-06-26 10:28 ` [PATCH v2 04/10] i2c: xiic: Remove interrupt enable/disable in Rx path Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 05/10] dt-bindings: i2c: xiic: Add 'xlnx,axi-iic-2.1' to compatible Raviteja Narayanam
2021-06-26 10:28   ` [PATCH v2 05/10] dt-bindings: i2c: xiic: Add 'xlnx, axi-iic-2.1' " Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 06/10] i2c: xiic: Update compatible with new IP version Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 07/10] i2c: xiic: Return value of xiic_reinit Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 08/10] i2c: xiic: Fix the type check for xiic_wakeup Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 09/10] i2c: xiic: Fix coding style issues Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 10/10] i2c: xiic: Add smbus_block_read functionality Raviteja Narayanam
2021-06-26 10:28   ` Raviteja Narayanam
2021-06-28  7:23 ` [PATCH v2 00/10] i2c: xiic: Add features, bug fixes Michal Simek
2021-06-28  7:23   ` Michal Simek
2021-07-16 16:01   ` Marek Vasut
2021-07-16 16:01     ` Marek Vasut
2021-07-19 10:09     ` Raviteja Narayanam
2021-07-19 10:09       ` Raviteja Narayanam
2021-07-19 18:00       ` Marek Vasut
2021-07-19 18:00         ` Marek Vasut
2021-07-20 14:19         ` Raviteja Narayanam
2021-07-20 14:19           ` Raviteja Narayanam
2021-07-20 21:43           ` Marek Vasut [this message]
2021-07-20 21:43             ` Marek Vasut
2021-07-26  5:26             ` Raviteja Narayanam
2021-07-26  5:26               ` Raviteja Narayanam
2021-07-26 13:12               ` Marek Vasut
2021-07-26 13:12                 ` Marek Vasut
2021-07-28 10:11                 ` Raviteja Narayanam
2021-07-28 10:11                   ` Raviteja Narayanam
2021-07-28 18:47                   ` Marek Vasut
2021-07-28 18:47                     ` Marek Vasut
2022-06-28  7:50                     ` Guntupalli, Manikanta
2022-06-28  7:50                       ` Guntupalli, Manikanta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=328f6c4e-ff0b-c88f-d246-75b493b67a9a@denx.de \
    --to=marex@denx.de \
    --cc=git@xilinx.com \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michals@xilinx.com \
    --cc=rna@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.