[PATCH 0/2]GPIO Loopback Benchmark Tool

[PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

In general, we use cyclictest and latency to evaluate the determinism of our real
time system. As we know, cyclictest and latency use hrtimer to set up a timer and
calculate jitter by comparing expected wakeup time and real wakeup time.

Besides that, we can also use GPIO to evaluate more modules in different scenarios. 
In this case, i apply 2 GPIO ports, one is set as output, the other is interrupt, 
at the same time, connect them with a cable. Once an signal is sent from output pin,
an interrupt will be raised in interrupt pin immediately.

Timestamps are recorded before gpio_set_value and interrupt handler respectively, the
diff between them is jitter.

There is also an RT task running in the user space, which collects the information and
output the summary at the end of the test. What's more, it also records the timestamps
in user space, syscall overhead is included.

Further, Making a little change will enable the tool working with latency box,once a
signal from latency box is received in interrupt pin, the tool can send a signal at
output pin as response. (I haven't got the latency box, so this function is not in 
place yet)

chensong (2):
  demo/posix/cobalt: App of gpio loopback benchmark
  kernel/driver/testing: Driver of gpio loopback benchmark

 demo/posix/cobalt/Makefile.am      |   6 +
 demo/posix/cobalt/gpioloop.c       | 516 +++++++++++++++++++++++++++++++++++++
 kernel/drivers/testing/Kconfig     |   7 +
 kernel/drivers/testing/Makefile    |   3 +
 kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
 5 files changed, 820 insertions(+)
 create mode 100644 demo/posix/cobalt/gpioloop.c
 create mode 100644 kernel/drivers/testing/gpiobench.c

-- 
2.7.4

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[Jan Kiszka]

On 03.07.20 08:37, chensong via Xenomai wrote:
> In general, we use cyclictest and latency to evaluate the determinism of our real
> time system. As we know, cyclictest and latency use hrtimer to set up a timer and
> calculate jitter by comparing expected wakeup time and real wakeup time.
> 
> Besides that, we can also use GPIO to evaluate more modules in different scenarios.
> In this case, i apply 2 GPIO ports, one is set as output, the other is interrupt,
> at the same time, connect them with a cable. Once an signal is sent from output pin,
> an interrupt will be raised in interrupt pin immediately.
> 
> Timestamps are recorded before gpio_set_value and interrupt handler respectively, the
> diff between them is jitter.
> 
> There is also an RT task running in the user space, which collects the information and
> output the summary at the end of the test. What's more, it also records the timestamps
> in user space, syscall overhead is included.
> 
> Further, Making a little change will enable the tool working with latency box,once a
> signal from latency box is received in interrupt pin, the tool can send a signal at
> output pin as response. (I haven't got the latency box, so this function is not in
> place yet)
> 
> chensong (2):
>    demo/posix/cobalt: App of gpio loopback benchmark
>    kernel/driver/testing: Driver of gpio loopback benchmark
> 
>   demo/posix/cobalt/Makefile.am      |   6 +
>   demo/posix/cobalt/gpioloop.c       | 516 +++++++++++++++++++++++++++++++++++++
>   kernel/drivers/testing/Kconfig     |   7 +
>   kernel/drivers/testing/Makefile    |   3 +
>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>   5 files changed, 820 insertions(+)
>   create mode 100644 demo/posix/cobalt/gpioloop.c
>   create mode 100644 kernel/drivers/testing/gpiobench.c
> 

That is a valuable addition! We used to have such an interrupt benchmark 
in Xenomai 2 times or so, using a null modem connection (UART signals). 
GPIOs are more generic, though.

Two things I would recommend doing differently:
  - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
    your targets)
  - build benchmark not via loopback but via cross-link
     - device-under-test receives truly asynchronous event on GPIO input
     - reacts with flipping some GPIO output
     - can run reaction either in interrupt handler or RT application
       task, to cover more real scenarios
     - latency box can also be a second device that triggers event and
       measures reaction while having interrupts off (that's how things
       worked in Xenomai 2)

The lookback scenario is too synchronous to catch realistic latencies. 
It rather measures the performance of the event path.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月03日 17:21, Jan Kiszka wrote:
> On 03.07.20 08:37, chensong via Xenomai wrote:
>> In general, we use cyclictest and latency to evaluate the determinism
>> of our real
>> time system. As we know, cyclictest and latency use hrtimer to set up
>> a timer and
>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>
>> Besides that, we can also use GPIO to evaluate more modules in
>> different scenarios.
>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>> interrupt,
>> at the same time, connect them with a cable. Once an signal is sent
>> from output pin,
>> an interrupt will be raised in interrupt pin immediately.
>>
>> Timestamps are recorded before gpio_set_value and interrupt handler
>> respectively, the
>> diff between them is jitter.
>>
>> There is also an RT task running in the user space, which collects the
>> information and
>> output the summary at the end of the test. What's more, it also
>> records the timestamps
>> in user space, syscall overhead is included.
>>
>> Further, Making a little change will enable the tool working with
>> latency box,once a
>> signal from latency box is received in interrupt pin, the tool can
>> send a signal at
>> output pin as response. (I haven't got the latency box, so this
>> function is not in
>> place yet)
>>
>> chensong (2):
>>    demo/posix/cobalt: App of gpio loopback benchmark
>>    kernel/driver/testing: Driver of gpio loopback benchmark
>>
>>   demo/posix/cobalt/Makefile.am      |   6 +
>>   demo/posix/cobalt/gpioloop.c       | 516
>> +++++++++++++++++++++++++++++++++++++
>>   kernel/drivers/testing/Kconfig     |   7 +
>>   kernel/drivers/testing/Makefile    |   3 +
>>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>   5 files changed, 820 insertions(+)
>>   create mode 100644 demo/posix/cobalt/gpioloop.c
>>   create mode 100644 kernel/drivers/testing/gpiobench.c
>>
>
> That is a valuable addition! We used to have such an interrupt benchmark
> in Xenomai 2 times or so, using a null modem connection (UART signals).
> GPIOs are more generic, though.
>
> Two things I would recommend doing differently:
>   - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>     your targets)
>   - build benchmark not via loopback but via cross-link
>      - device-under-test receives truly asynchronous event on GPIO input
>      - reacts with flipping some GPIO output
>      - can run reaction either in interrupt handler or RT application
>        task, to cover more real scenarios
>      - latency box can also be a second device that triggers event and
>        measures reaction while having interrupts off (that's how things
>        worked in Xenomai 2)
>
> The lookback scenario is too synchronous to catch realistic latencies.
> It rather measures the performance of the event path.
actually, yes, as the ftrace log, events path contributes a lot latencies.
what's more, if the app and interrupt are not running in the cpu, IPI is 
needed, and also causes latency.
but, it can also find out latency sources under different workload as 
well as cyclictest does.
>
> Jan
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月03日 17:21, Jan Kiszka wrote:
> On 03.07.20 08:37, chensong via Xenomai wrote:
>> In general, we use cyclictest and latency to evaluate the determinism
>> of our real
>> time system. As we know, cyclictest and latency use hrtimer to set up
>> a timer and
>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>
>> Besides that, we can also use GPIO to evaluate more modules in
>> different scenarios.
>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>> interrupt,
>> at the same time, connect them with a cable. Once an signal is sent
>> from output pin,
>> an interrupt will be raised in interrupt pin immediately.
>>
>> Timestamps are recorded before gpio_set_value and interrupt handler
>> respectively, the
>> diff between them is jitter.
>>
>> There is also an RT task running in the user space, which collects the
>> information and
>> output the summary at the end of the test. What's more, it also
>> records the timestamps
>> in user space, syscall overhead is included.
>>
>> Further, Making a little change will enable the tool working with
>> latency box,once a
>> signal from latency box is received in interrupt pin, the tool can
>> send a signal at
>> output pin as response. (I haven't got the latency box, so this
>> function is not in
>> place yet)
>>
>> chensong (2):
>>    demo/posix/cobalt: App of gpio loopback benchmark
>>    kernel/driver/testing: Driver of gpio loopback benchmark
>>
>>   demo/posix/cobalt/Makefile.am      |   6 +
>>   demo/posix/cobalt/gpioloop.c       | 516
>> +++++++++++++++++++++++++++++++++++++
>>   kernel/drivers/testing/Kconfig     |   7 +
>>   kernel/drivers/testing/Makefile    |   3 +
>>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>   5 files changed, 820 insertions(+)
>>   create mode 100644 demo/posix/cobalt/gpioloop.c
>>   create mode 100644 kernel/drivers/testing/gpiobench.c
>>
>
> That is a valuable addition! We used to have such an interrupt benchmark
> in Xenomai 2 times or so, using a null modem connection (UART signals).
> GPIOs are more generic, though.
>
> Two things I would recommend doing differently:
>   - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>     your targets)
gpiobench.c in patch2/2 is referring to gpio-core.c in 
kernel/driver/gpio, they use similar RTDM strcuts or APIs such as 
rtdm_driver, rtdm_dev_register.

Could you please give me a sample of RTDM GPIO device? or what kind of 
RTDM GPIO driver did i miss?

I've been very familiar with RTDM driver yet, so, a little more help is 
nedded, thanks.

>   - build benchmark not via loopback but via cross-link
>      - device-under-test receives truly asynchronous event on GPIO input
          from a latency-box likely device ?
>      - reacts with flipping some GPIO output
>      - can run reaction either in interrupt handler or RT application
>        task, to cover more real scenarios
>      - latency box can also be a second device that triggers event and
>        measures reaction while having interrupts off (that's how things
>        worked in Xenomai 2)

if i understand you correctly, via cross-link, you mean a latecy-box 
likely device is a must, it sends signal to device-under-test and 
device-under-test reacts with flipping GPIO output. is it asynchronous 
event?

In the patch1/2, i think switching read and write can make it work, like:

while(){
      read_gpio()
      //once receiving event
      write_gpio()  //as the reaction

}

>
> The lookback scenario is too synchronous to catch realistic latencies.
> It rather measures the performance of the event path.
>
> Jan
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月06日 09:35, chensong via Xenomai wrote:
>
>
> On 2020年07月03日 17:21, Jan Kiszka wrote:
>> On 03.07.20 08:37, chensong via Xenomai wrote:
>>> In general, we use cyclictest and latency to evaluate the determinism
>>> of our real
>>> time system. As we know, cyclictest and latency use hrtimer to set up
>>> a timer and
>>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>>
>>> Besides that, we can also use GPIO to evaluate more modules in
>>> different scenarios.
>>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>>> interrupt,
>>> at the same time, connect them with a cable. Once an signal is sent
>>> from output pin,
>>> an interrupt will be raised in interrupt pin immediately.
>>>
>>> Timestamps are recorded before gpio_set_value and interrupt handler
>>> respectively, the
>>> diff between them is jitter.
>>>
>>> There is also an RT task running in the user space, which collects the
>>> information and
>>> output the summary at the end of the test. What's more, it also
>>> records the timestamps
>>> in user space, syscall overhead is included.
>>>
>>> Further, Making a little change will enable the tool working with
>>> latency box,once a
>>> signal from latency box is received in interrupt pin, the tool can
>>> send a signal at
>>> output pin as response. (I haven't got the latency box, so this
>>> function is not in
>>> place yet)
>>>
>>> chensong (2):
>>>    demo/posix/cobalt: App of gpio loopback benchmark
>>>    kernel/driver/testing: Driver of gpio loopback benchmark
>>>
>>>   demo/posix/cobalt/Makefile.am      |   6 +
>>>   demo/posix/cobalt/gpioloop.c       | 516
>>> +++++++++++++++++++++++++++++++++++++
>>>   kernel/drivers/testing/Kconfig     |   7 +
>>>   kernel/drivers/testing/Makefile    |   3 +
>>>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>>   5 files changed, 820 insertions(+)
>>>   create mode 100644 demo/posix/cobalt/gpioloop.c
>>>   create mode 100644 kernel/drivers/testing/gpiobench.c
>>>
>>
>> That is a valuable addition! We used to have such an interrupt benchmark
>> in Xenomai 2 times or so, using a null modem connection (UART signals).
>> GPIOs are more generic, though.
>>
>> Two things I would recommend doing differently:
>>   - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>>     your targets)
> gpiobench.c in patch2/2 is referring to gpio-core.c in
> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
> rtdm_driver, rtdm_dev_register.
>
> Could you please give me a sample of RTDM GPIO device? or what kind of
> RTDM GPIO driver did i miss?
>
> I've been very familiar with RTDM driver yet, so, a little more help is
> nedded, thanks.
correction: I've NOT been very familiar with RTDM driver yet,sorry
>
>>   - build benchmark not via loopback but via cross-link
>>      - device-under-test receives truly asynchronous event on GPIO input
>           from a latency-box likely device ?
>>      - reacts with flipping some GPIO output
>>      - can run reaction either in interrupt handler or RT application
>>        task, to cover more real scenarios
>>      - latency box can also be a second device that triggers event and
>>        measures reaction while having interrupts off (that's how things
>>        worked in Xenomai 2)
>
> if i understand you correctly, via cross-link, you mean a latecy-box
> likely device is a must, it sends signal to device-under-test and
> device-under-test reacts with flipping GPIO output. is it asynchronous
> event?
>
> In the patch1/2, i think switching read and write can make it work, like:
>
> while(){
>       read_gpio()
>       //once receiving event
>       write_gpio()  //as the reaction
>
> }
>
>>
>> The lookback scenario is too synchronous to catch realistic latencies.
>> It rather measures the performance of the event path.
>>
>> Jan
>>
>
>
>
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[Greg Gallagher]

Hi

On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai <xenomai@xenomai.org> wrote:
>
>
>
> On 2020年07月03日 17:21, Jan Kiszka wrote:
> > On 03.07.20 08:37, chensong via Xenomai wrote:
> >> In general, we use cyclictest and latency to evaluate the determinism
> >> of our real
> >> time system. As we know, cyclictest and latency use hrtimer to set up
> >> a timer and
> >> calculate jitter by comparing expected wakeup time and real wakeup time.
> >>
> >> Besides that, we can also use GPIO to evaluate more modules in
> >> different scenarios.
> >> In this case, i apply 2 GPIO ports, one is set as output, the other is
> >> interrupt,
> >> at the same time, connect them with a cable. Once an signal is sent
> >> from output pin,
> >> an interrupt will be raised in interrupt pin immediately.
> >>
> >> Timestamps are recorded before gpio_set_value and interrupt handler
> >> respectively, the
> >> diff between them is jitter.
> >>
> >> There is also an RT task running in the user space, which collects the
> >> information and
> >> output the summary at the end of the test. What's more, it also
> >> records the timestamps
> >> in user space, syscall overhead is included.
> >>
> >> Further, Making a little change will enable the tool working with
> >> latency box,once a
> >> signal from latency box is received in interrupt pin, the tool can
> >> send a signal at
> >> output pin as response. (I haven't got the latency box, so this
> >> function is not in
> >> place yet)
> >>
> >> chensong (2):
> >>    demo/posix/cobalt: App of gpio loopback benchmark
> >>    kernel/driver/testing: Driver of gpio loopback benchmark
> >>
> >>   demo/posix/cobalt/Makefile.am      |   6 +
> >>   demo/posix/cobalt/gpioloop.c       | 516
> >> +++++++++++++++++++++++++++++++++++++
> >>   kernel/drivers/testing/Kconfig     |   7 +
> >>   kernel/drivers/testing/Makefile    |   3 +
> >>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
> >>   5 files changed, 820 insertions(+)
> >>   create mode 100644 demo/posix/cobalt/gpioloop.c
> >>   create mode 100644 kernel/drivers/testing/gpiobench.c
> >>
> >
> > That is a valuable addition! We used to have such an interrupt benchmark
> > in Xenomai 2 times or so, using a null modem connection (UART signals).
> > GPIOs are more generic, though.
> >
> > Two things I would recommend doing differently:
> >   - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
> >     your targets)
> gpiobench.c in patch2/2 is referring to gpio-core.c in
> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
> rtdm_driver, rtdm_dev_register.
>
> Could you please give me a sample of RTDM GPIO device? or what kind of
> RTDM GPIO driver did i miss?
>
You could add a proper RTDM gpio driver similar to
kernel/drivers/gpio/gpio-omap.c

They are pretty easy to add since there's a gpio framework in Xenomai
that uses some functions from gpiolib.  This commit
d4416d68082f538cdbf08579f99738adbe80d39c may help as an example on how
to add a new gpio driver. Let me know if I can help.

-Greg

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月06日 13:59, Greg Gallagher wrote:
> Hi
>
> On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai <xenomai@xenomai.org> wrote:
>>
>>
>>
>> On 2020年07月03日 17:21, Jan Kiszka wrote:
>>> On 03.07.20 08:37, chensong via Xenomai wrote:
>>>> In general, we use cyclictest and latency to evaluate the determinism
>>>> of our real
>>>> time system. As we know, cyclictest and latency use hrtimer to set up
>>>> a timer and
>>>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>>>
>>>> Besides that, we can also use GPIO to evaluate more modules in
>>>> different scenarios.
>>>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>>>> interrupt,
>>>> at the same time, connect them with a cable. Once an signal is sent
>>>> from output pin,
>>>> an interrupt will be raised in interrupt pin immediately.
>>>>
>>>> Timestamps are recorded before gpio_set_value and interrupt handler
>>>> respectively, the
>>>> diff between them is jitter.
>>>>
>>>> There is also an RT task running in the user space, which collects the
>>>> information and
>>>> output the summary at the end of the test. What's more, it also
>>>> records the timestamps
>>>> in user space, syscall overhead is included.
>>>>
>>>> Further, Making a little change will enable the tool working with
>>>> latency box,once a
>>>> signal from latency box is received in interrupt pin, the tool can
>>>> send a signal at
>>>> output pin as response. (I haven't got the latency box, so this
>>>> function is not in
>>>> place yet)
>>>>
>>>> chensong (2):
>>>>     demo/posix/cobalt: App of gpio loopback benchmark
>>>>     kernel/driver/testing: Driver of gpio loopback benchmark
>>>>
>>>>    demo/posix/cobalt/Makefile.am      |   6 +
>>>>    demo/posix/cobalt/gpioloop.c       | 516
>>>> +++++++++++++++++++++++++++++++++++++
>>>>    kernel/drivers/testing/Kconfig     |   7 +
>>>>    kernel/drivers/testing/Makefile    |   3 +
>>>>    kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>>>    5 files changed, 820 insertions(+)
>>>>    create mode 100644 demo/posix/cobalt/gpioloop.c
>>>>    create mode 100644 kernel/drivers/testing/gpiobench.c
>>>>
>>>
>>> That is a valuable addition! We used to have such an interrupt benchmark
>>> in Xenomai 2 times or so, using a null modem connection (UART signals).
>>> GPIOs are more generic, though.
>>>
>>> Two things I would recommend doing differently:
>>>    - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>>>      your targets)
>> gpiobench.c in patch2/2 is referring to gpio-core.c in
>> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
>> rtdm_driver, rtdm_dev_register.
>>
>> Could you please give me a sample of RTDM GPIO device? or what kind of
>> RTDM GPIO driver did i miss?
>>
> You could add a proper RTDM gpio driver similar to
> kernel/drivers/gpio/gpio-omap.c
>
> They are pretty easy to add since there's a gpio framework in Xenomai
> that uses some functions from gpiolib.  This commit
> d4416d68082f538cdbf08579f99738adbe80d39c may help as an example on how
> to add a new gpio driver. Let me know if I can help.
i think i understand gpio framework in gpio-omap.c and gpio-core.c, 
therefore, gpiobench.c in my patch can be replaced. what's more, a new 
file like gpio-bcm2711.c is needed.

I also looked into /testsuite/gpiotest/gpiotest.c, it's working with 
gpio-core.c and read the timestamp of gpio interrupt, however, there is 
no histogram, nor reacting to latency-box. i'm considering to add such 
functionalities in either gpiotest.c or still in gpioloop.c of my patch? 
which one would you prefer?

by the way, could you please let me know how gpiotest is triggered in 
smokey test,i read the code of smokey test and didn't manage to figure 
it out.

>
> -Greg
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[Greg Gallagher]

On Mon, Jul 6, 2020 at 5:29 AM chensong <chensong@tj.kylinos.cn> wrote:
>
>
>
> On 2020年07月06日 13:59, Greg Gallagher wrote:
> > Hi
> >
> > On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai <xenomai@xenomai.org> wrote:
> >>
> >>
> >>
> >> On 2020年07月03日 17:21, Jan Kiszka wrote:
> >>> On 03.07.20 08:37, chensong via Xenomai wrote:
> >>>> In general, we use cyclictest and latency to evaluate the determinism
> >>>> of our real
> >>>> time system. As we know, cyclictest and latency use hrtimer to set up
> >>>> a timer and
> >>>> calculate jitter by comparing expected wakeup time and real wakeup time.
> >>>>
> >>>> Besides that, we can also use GPIO to evaluate more modules in
> >>>> different scenarios.
> >>>> In this case, i apply 2 GPIO ports, one is set as output, the other is
> >>>> interrupt,
> >>>> at the same time, connect them with a cable. Once an signal is sent
> >>>> from output pin,
> >>>> an interrupt will be raised in interrupt pin immediately.
> >>>>
> >>>> Timestamps are recorded before gpio_set_value and interrupt handler
> >>>> respectively, the
> >>>> diff between them is jitter.
> >>>>
> >>>> There is also an RT task running in the user space, which collects the
> >>>> information and
> >>>> output the summary at the end of the test. What's more, it also
> >>>> records the timestamps
> >>>> in user space, syscall overhead is included.
> >>>>
> >>>> Further, Making a little change will enable the tool working with
> >>>> latency box,once a
> >>>> signal from latency box is received in interrupt pin, the tool can
> >>>> send a signal at
> >>>> output pin as response. (I haven't got the latency box, so this
> >>>> function is not in
> >>>> place yet)
> >>>>
> >>>> chensong (2):
> >>>>     demo/posix/cobalt: App of gpio loopback benchmark
> >>>>     kernel/driver/testing: Driver of gpio loopback benchmark
> >>>>
> >>>>    demo/posix/cobalt/Makefile.am      |   6 +
> >>>>    demo/posix/cobalt/gpioloop.c       | 516
> >>>> +++++++++++++++++++++++++++++++++++++
> >>>>    kernel/drivers/testing/Kconfig     |   7 +
> >>>>    kernel/drivers/testing/Makefile    |   3 +
> >>>>    kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
> >>>>    5 files changed, 820 insertions(+)
> >>>>    create mode 100644 demo/posix/cobalt/gpioloop.c
> >>>>    create mode 100644 kernel/drivers/testing/gpiobench.c
> >>>>
> >>>
> >>> That is a valuable addition! We used to have such an interrupt benchmark
> >>> in Xenomai 2 times or so, using a null modem connection (UART signals).
> >>> GPIOs are more generic, though.
> >>>
> >>> Two things I would recommend doing differently:
> >>>    - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
> >>>      your targets)
> >> gpiobench.c in patch2/2 is referring to gpio-core.c in
> >> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
> >> rtdm_driver, rtdm_dev_register.
> >>
> >> Could you please give me a sample of RTDM GPIO device? or what kind of
> >> RTDM GPIO driver did i miss?
> >>
> > You could add a proper RTDM gpio driver similar to
> > kernel/drivers/gpio/gpio-omap.c
> >
> > They are pretty easy to add since there's a gpio framework in Xenomai
> > that uses some functions from gpiolib.  This commit
> > d4416d68082f538cdbf08579f99738adbe80d39c may help as an example on how
> > to add a new gpio driver. Let me know if I can help.
> i think i understand gpio framework in gpio-omap.c and gpio-core.c,
> therefore, gpiobench.c in my patch can be replaced. what's more, a new
> file like gpio-bcm2711.c is needed.

Is this for the Raspberry pi 4?  Does that use the bcm2835 gpio
driver?  We already have that driver if that's the case.
>
> I also looked into /testsuite/gpiotest/gpiotest.c, it's working with
> gpio-core.c and read the timestamp of gpio interrupt, however, there is
> no histogram, nor reacting to latency-box. i'm considering to add such
> functionalities in either gpiotest.c or still in gpioloop.c of my patch?
> which one would you prefer?
>
> by the way, could you please let me know how gpiotest is triggered in
> smokey test,i read the code of smokey test and didn't manage to figure
> it out.
>
> >
> > -Greg
> >
>
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月07日 00:05, Greg Gallagher wrote:
> On Mon, Jul 6, 2020 at 5:29 AM chensong <chensong@tj.kylinos.cn> wrote:
>>
>>
>>
>> On 2020年07月06日 13:59, Greg Gallagher wrote:
>>> Hi
>>>
>>> On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai <xenomai@xenomai.org> wrote:
>>>>
>>>>
>>>>
>>>> On 2020年07月03日 17:21, Jan Kiszka wrote:
>>>>> On 03.07.20 08:37, chensong via Xenomai wrote:
>>>>>> In general, we use cyclictest and latency to evaluate the determinism
>>>>>> of our real
>>>>>> time system. As we know, cyclictest and latency use hrtimer to set up
>>>>>> a timer and
>>>>>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>>>>>
>>>>>> Besides that, we can also use GPIO to evaluate more modules in
>>>>>> different scenarios.
>>>>>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>>>>>> interrupt,
>>>>>> at the same time, connect them with a cable. Once an signal is sent
>>>>>> from output pin,
>>>>>> an interrupt will be raised in interrupt pin immediately.
>>>>>>
>>>>>> Timestamps are recorded before gpio_set_value and interrupt handler
>>>>>> respectively, the
>>>>>> diff between them is jitter.
>>>>>>
>>>>>> There is also an RT task running in the user space, which collects the
>>>>>> information and
>>>>>> output the summary at the end of the test. What's more, it also
>>>>>> records the timestamps
>>>>>> in user space, syscall overhead is included.
>>>>>>
>>>>>> Further, Making a little change will enable the tool working with
>>>>>> latency box,once a
>>>>>> signal from latency box is received in interrupt pin, the tool can
>>>>>> send a signal at
>>>>>> output pin as response. (I haven't got the latency box, so this
>>>>>> function is not in
>>>>>> place yet)
>>>>>>
>>>>>> chensong (2):
>>>>>>      demo/posix/cobalt: App of gpio loopback benchmark
>>>>>>      kernel/driver/testing: Driver of gpio loopback benchmark
>>>>>>
>>>>>>     demo/posix/cobalt/Makefile.am      |   6 +
>>>>>>     demo/posix/cobalt/gpioloop.c       | 516
>>>>>> +++++++++++++++++++++++++++++++++++++
>>>>>>     kernel/drivers/testing/Kconfig     |   7 +
>>>>>>     kernel/drivers/testing/Makefile    |   3 +
>>>>>>     kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>>>>>     5 files changed, 820 insertions(+)
>>>>>>     create mode 100644 demo/posix/cobalt/gpioloop.c
>>>>>>     create mode 100644 kernel/drivers/testing/gpiobench.c
>>>>>>
>>>>>
>>>>> That is a valuable addition! We used to have such an interrupt benchmark
>>>>> in Xenomai 2 times or so, using a null modem connection (UART signals).
>>>>> GPIOs are more generic, though.
>>>>>
>>>>> Two things I would recommend doing differently:
>>>>>     - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>>>>>       your targets)
>>>> gpiobench.c in patch2/2 is referring to gpio-core.c in
>>>> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
>>>> rtdm_driver, rtdm_dev_register.
>>>>
>>>> Could you please give me a sample of RTDM GPIO device? or what kind of
>>>> RTDM GPIO driver did i miss?
>>>>
>>> You could add a proper RTDM gpio driver similar to
>>> kernel/drivers/gpio/gpio-omap.c
>>>
>>> They are pretty easy to add since there's a gpio framework in Xenomai
>>> that uses some functions from gpiolib.  This commit
>>> d4416d68082f538cdbf08579f99738adbe80d39c may help as an example on how
>>> to add a new gpio driver. Let me know if I can help.
>> i think i understand gpio framework in gpio-omap.c and gpio-core.c,
>> therefore, gpiobench.c in my patch can be replaced. what's more, a new
>> file like gpio-bcm2711.c is needed.
>
> Is this for the Raspberry pi 4?  Does that use the bcm2835 gpio
> driver?  We already have that driver if that's the case.
For Raspberry pi 4b, same with rpi 4? I'm not sure which one. I found 
them both in device tree.
If bcm2835 is the right driver, no more work to do.
>>
>> I also looked into /testsuite/gpiotest/gpiotest.c, it's working with
>> gpio-core.c and read the timestamp of gpio interrupt, however, there is
>> no histogram, nor reacting to latency-box. i'm considering to add such
>> functionalities in either gpiotest.c or still in gpioloop.c of my patch?
>> which one would you prefer?
>>
>> by the way, could you please let me know how gpiotest is triggered in
>> smokey test,i read the code of smokey test and didn't manage to figure
>> it out.
>>
>>>
>>> -Greg
>>>
>>
>>
>

Re: [PATCH 0/2]GPIO Loopback Benchmark Tool

[chensong]

On 2020年07月07日 08:42, chensong via Xenomai wrote:
>
>
> On 2020年07月07日 00:05, Greg Gallagher wrote:
>> On Mon, Jul 6, 2020 at 5:29 AM chensong <chensong@tj.kylinos.cn> wrote:
>>>
>>>
>>>
>>> On 2020年07月06日 13:59, Greg Gallagher wrote:
>>>> Hi
>>>>
>>>> On Sun, Jul 5, 2020 at 9:36 PM chensong via Xenomai
>>>> <xenomai@xenomai.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 2020年07月03日 17:21, Jan Kiszka wrote:
>>>>>> On 03.07.20 08:37, chensong via Xenomai wrote:
>>>>>>> In general, we use cyclictest and latency to evaluate the
>>>>>>> determinism
>>>>>>> of our real
>>>>>>> time system. As we know, cyclictest and latency use hrtimer to
>>>>>>> set up
>>>>>>> a timer and
>>>>>>> calculate jitter by comparing expected wakeup time and real
>>>>>>> wakeup time.
>>>>>>>
>>>>>>> Besides that, we can also use GPIO to evaluate more modules in
>>>>>>> different scenarios.
>>>>>>> In this case, i apply 2 GPIO ports, one is set as output, the
>>>>>>> other is
>>>>>>> interrupt,
>>>>>>> at the same time, connect them with a cable. Once an signal is sent
>>>>>>> from output pin,
>>>>>>> an interrupt will be raised in interrupt pin immediately.
>>>>>>>
>>>>>>> Timestamps are recorded before gpio_set_value and interrupt handler
>>>>>>> respectively, the
>>>>>>> diff between them is jitter.
>>>>>>>
>>>>>>> There is also an RT task running in the user space, which
>>>>>>> collects the
>>>>>>> information and
>>>>>>> output the summary at the end of the test. What's more, it also
>>>>>>> records the timestamps
>>>>>>> in user space, syscall overhead is included.
>>>>>>>
>>>>>>> Further, Making a little change will enable the tool working with
>>>>>>> latency box,once a
>>>>>>> signal from latency box is received in interrupt pin, the tool can
>>>>>>> send a signal at
>>>>>>> output pin as response. (I haven't got the latency box, so this
>>>>>>> function is not in
>>>>>>> place yet)
>>>>>>>
>>>>>>> chensong (2):
>>>>>>>      demo/posix/cobalt: App of gpio loopback benchmark
>>>>>>>      kernel/driver/testing: Driver of gpio loopback benchmark
>>>>>>>
>>>>>>>     demo/posix/cobalt/Makefile.am      |   6 +
>>>>>>>     demo/posix/cobalt/gpioloop.c       | 516
>>>>>>> +++++++++++++++++++++++++++++++++++++
>>>>>>>     kernel/drivers/testing/Kconfig     |   7 +
>>>>>>>     kernel/drivers/testing/Makefile    |   3 +
>>>>>>>     kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>>>>>>     5 files changed, 820 insertions(+)
>>>>>>>     create mode 100644 demo/posix/cobalt/gpioloop.c
>>>>>>>     create mode 100644 kernel/drivers/testing/gpiobench.c
>>>>>>>
>>>>>>
>>>>>> That is a valuable addition! We used to have such an interrupt
>>>>>> benchmark
>>>>>> in Xenomai 2 times or so, using a null modem connection (UART
>>>>>> signals).
>>>>>> GPIOs are more generic, though.
>>>>>>
>>>>>> Two things I would recommend doing differently:
>>>>>>     - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>>>>>>       your targets)
>>>>> gpiobench.c in patch2/2 is referring to gpio-core.c in
>>>>> kernel/driver/gpio, they use similar RTDM strcuts or APIs such as
>>>>> rtdm_driver, rtdm_dev_register.
>>>>>
>>>>> Could you please give me a sample of RTDM GPIO device? or what kind of
>>>>> RTDM GPIO driver did i miss?
>>>>>
>>>> You could add a proper RTDM gpio driver similar to
>>>> kernel/drivers/gpio/gpio-omap.c
>>>>
>>>> They are pretty easy to add since there's a gpio framework in Xenomai
>>>> that uses some functions from gpiolib.  This commit
>>>> d4416d68082f538cdbf08579f99738adbe80d39c may help as an example on how
>>>> to add a new gpio driver. Let me know if I can help.
>>> i think i understand gpio framework in gpio-omap.c and gpio-core.c,
>>> therefore, gpiobench.c in my patch can be replaced. what's more, a new
>>> file like gpio-bcm2711.c is needed.
>>
>> Is this for the Raspberry pi 4?  Does that use the bcm2835 gpio
>> driver?  We already have that driver if that's the case.
> For Raspberry pi 4b, same with rpi 4? I'm not sure which one. I found
> them both in device tree.
> If bcm2835 is the right driver, no more work to do.

i verified bcm2835, it's working perfectly with rt task in my app(patch 
1/2), therefore, gpiobench.c(patch2/2) is not necessary.

thanks.

>>>
>>> I also looked into /testsuite/gpiotest/gpiotest.c, it's working with
>>> gpio-core.c and read the timestamp of gpio interrupt, however, there is
>>> no histogram, nor reacting to latency-box. i'm considering to add such
>>> functionalities in either gpiotest.c or still in gpioloop.c of my patch?
>>> which one would you prefer?

i prefer to add asynchronous event in gpioloop.c, once received a signal 
from gpio interrupt, send a signal back via gpio out as reaction.

compared to gpiotest.c, gpioloop.c has histogram and ftrace. what do you 
say? If it's ok for you, i will start preparing patch v2.

>>>
>>> by the way, could you please let me know how gpiotest is triggered in
>>> smokey test,i read the code of smokey test and didn't manage to figure
>>> it out.
>>>
>>>>
>>>> -Greg
>>>>
>>>
>>>
>>
>
>
>
>