From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver References: <20210830064527.18206-1-hongzhan.chen@intel.com> <4ca7072b-b386-25b7-3a01-8a3baea1290c@siemens.com> <6dbc0237-c348-f787-775c-aa83b64782cd@siemens.com> <5c2282c2-dbd3-016b-21f0-678428ad0164@siemens.com> <10a67496-523f-05f4-1a17-b690f28b4c56@siemens.com> From: Jan Kiszka Message-ID: <65c64cf8-3a00-def1-4029-177ba3f0a7d9@siemens.com> Date: Thu, 2 Sep 2021 08:44:17 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Hongzhan" , "xenomai@xenomai.org" On 02.09.21 08:24, Chen, Hongzhan wrote: > > >> -----Original Message----- >> From: Jan Kiszka >> Sent: Thursday, September 2, 2021 2:11 PM >> To: Chen, Hongzhan ; xenomai@xenomai.org >> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver >> >> On 02.09.21 02:42, Chen, Hongzhan wrote: >>> >>> >>>> -----Original Message----- >>>> From: Jan Kiszka >>>> Sent: Wednesday, September 1, 2021 10:27 PM >>>> To: Chen, Hongzhan ; xenomai@xenomai.org >>>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver >>>> >>>> On 31.08.21 08:36, Chen, Hongzhan wrote: >>>>>>> -----Original Message----- >>>>>>>> From: Jan Kiszka >>>>>>>> Sent: Tuesday, August 31, 2021 1:59 PM >>>>>>>> To: Chen, Hongzhan ; xenomai@xenomai.org >>>>>>>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver >>>>>>>> >>>>>>>> On 31.08.21 03:35, Chen, Hongzhan wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Jan Kiszka >>>>>>>>>> Sent: Monday, August 30, 2021 3:37 PM >>>>>>>>>> To: Chen, Hongzhan ; xenomai@xenomai.org >>>>>>>>>> Subject: Re: [PATCH 0/3] add support for cherryview gpio controller driver >>>>>>>>>> >>>>>>>>>> On 30.08.21 08:45, Hongzhan Chen via Xenomai wrote: >>>>>>>>>>> 1. move out of OF config conditional compilation so that non-OF platform >>>>>>>>>>> call same API to remove rtdm gpio chip device. >>>>>>>>>>> 2. Introduce helper to find gpiochip as referring to pair of >>>>>>>>>>> rtdm_gpiochip_scan_of and rtdm_gpiochip_scan_array_of. >>>>>>>>>>> 3. Add Intel Cherryview pinctrl driver based on on 1 and 2. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Looks good, except for that naming issue. >>>>>>>>>> >>>>>>>>>>> I also did following tests with this patchset: >>>>>>>>>>> 1. run /usr/lib/xenomai/testsuite/gpiobench -i 334 -i 335 -c INT33FF:02 >>>>>>>>>>> to validate patch 9afea5ff2d7ba97db96b22a005a9a7fcf5f2d892 when >>>>>>>>>>> setting GPIO_RTIOC_TS >>>>>>>>>>> 2. apply following patch, and rerun 1. >>>>>>>>>>> >>>>>>>>>>> index f83d7689f..50afbd418 100644 >>>>>>>>>>> --- a/testsuite/gpiobench/gpiobench.c >>>>>>>>>>> +++ b/testsuite/gpiobench/gpiobench.c >>>>>>>>>>> @@ -619,7 +619,7 @@ int main(int argc, char **argv) >>>>>>>>>>> goto out; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> - ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS, &value); >>>>>>>>>>> + ret = ioctl(ti.fd_dev_intr, GPIO_RTIOC_TS_MONO, &value); >>>>>>>>>>> if (ret) { >>>>>>>>>>> printf("ioctl gpio port ts, failed\n"); >>>>>>>>>>> goto out; >>>>>>>>>>> >>>>>>>>>>> Hardware env: >>>>>>>>>>> 1. Rock PI X V1.4. >>>>>>>>>>> 2. GPIO loopback connection between GPIO 334 and 335. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Did you check if timestamps are as expected (different)? >>>>>>>>> >>>>>>>>> According to output of gpiobench, the inner Avg Latency would be vary large like ( 2814377.00000) after switch to MONO. >>>>>>>>> But it is only about 16.879997 when we set REALTIME. >>>>>>>>> >>>>>>>> >>>>>>>> gpiobench takes timestamps from CLOCK_MONOTONIC (see clock_gettime >>>>>>>> calls)). If you compare them to REALTIME, that will give an offset. But >>>>>>>> you report just the opposite, this confuses me now... >>>>>>> >>>>>>> The test is running on dovetail based 5.10. >>>>>>> >>>>>> >>>>>> I missed one case in gpio_pin_interrupt where I need to check >>>>>> monotonic_timestamp - but, again, mono is what should remain fine, >>>>>> GPIO_RTIOC_TS_REAL (or GPIO_RTIOC_TS, the default) should give a delta. >>>>> >>>>> I found there is one obvious gap for my comparison test. >>>>> >>>>> For REALTEIM , it totally run 999999 like [1] till test normally exit. But for MONO, I force to quit during running >>>>> because it may take several hours to finish and I can not wait like [2]. Let me rerun test and wait till it normally exit and >>>>> get result to check. >>>>> >>>>> [1]: >>>>> # Total: 000999999 >>>>> # Min Latencies: 00013 >>>>> # Avg Latencies: 16.879997 >>>>> # Max Latencies: 00043 >>>>> [2]: >>>>> # Total: 000083988 >>>>> # Min Latencies: 00012 >>>>> # Avg Latencies: 2814377.000000 >>>>> # Max Latencies: 00041 >>>>> >>>> >>>> Were you able to resolve this mystery over latest next? >>> >>> Yes. Firstly , I am doing complete test with passing MONO or REALTIME to check if this mystery large AVG latency >>> still happen till gpiobench normally exit and do comparison test based on updated next code. And then figure out >>> why it happen when gpiobench is interrupted during running and fix it if it is problem caused by timestamp. >>> >> >> So, you WILL do this, right? I'm asking because this is blocking -rc1, >> and I can't test here. > > Yes. I already found the root cause. It is caused by gpiobench itself. Because > It do not execute "ti.ts.inner_avg /= (ti.total_cycles * 2) when I use Ctrl+C to force the gpiobench to quit and inner_avg keep > all sum of latency so that it is very large number. I will submit patch to review after I validate it. > Ah, perfect, TIA! Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux