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: Wed, 28 Jul 2021 20:47:26 +0200 [thread overview] Message-ID: <d70b569d-a0e3-81b0-a553-ed88423924f7@denx.de> (raw) In-Reply-To: <SN6PR02MB4093ACD6E6A349BA9740ABB9CAEA9@SN6PR02MB4093.namprd02.prod.outlook.com> On 7/28/21 12:11 PM, Raviteja Narayanam wrote: [...] >>>>>>> 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 ? > > Above code is just one part. > We are doing read/writes to all devices present on this board https://www.xilinx.com/support/documentation/boards_and_kits/zcu102/ug1182-zcu102-eval-bd.pdf Can you share details of how those tests were performed ? >>> 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. > > Ok, I will do longer writes (in the range of 255) on supported slave devices. 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: Wed, 28 Jul 2021 20:47:26 +0200 [thread overview] Message-ID: <d70b569d-a0e3-81b0-a553-ed88423924f7@denx.de> (raw) In-Reply-To: <SN6PR02MB4093ACD6E6A349BA9740ABB9CAEA9@SN6PR02MB4093.namprd02.prod.outlook.com> On 7/28/21 12:11 PM, Raviteja Narayanam wrote: [...] >>>>>>> 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 ? > > Above code is just one part. > We are doing read/writes to all devices present on this board https://www.xilinx.com/support/documentation/boards_and_kits/zcu102/ug1182-zcu102-eval-bd.pdf Can you share details of how those tests were performed ? >>> 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. > > Ok, I will do longer writes (in the range of 255) on supported slave devices. Thank you _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-28 18:47 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 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 [this message] 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=d70b569d-a0e3-81b0-a553-ed88423924f7@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: linkBe 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.