[PATCH 0/2]GPIO Loopback Benchmark Tool

chensong chensong at tj.kylinos.cn
Tue Jul 7 02:42:22 CEST 2020

On 2020年07月07日 00:05, Greg Gallagher wrote:
> On Mon, Jul 6, 2020 at 5:29 AM chensong <chensong at 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 at 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

More information about the Xenomai mailing list