Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
> Hi Jan,
> 
> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>> Philippe,
>>>>>>
>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>> RTDM IIRC.
>>>>>>
>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>
>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>> this test?
>>>>
>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>> probably the best requirements source for multi-arch support.
>>>
>>> I mean that the bulk of the code could be made arch-neutral, with only
>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>> not uncommon on powerpc, but we obviously don't program them via
>>> ioports. A second level of indirection could provide the entire chip
>>> handling, to fit other uarts, maybe?
>>
>> If there are suitable UARTs around, refactoring the code accordingly and
>> maybe adding support for one of them as reference would be a good next
>> step. But first I would like to understand (or recall - I think Wolfgang
>> once explained it) the motivations for not going this path with the
>> gpiobench test and learn its requirements to avoid doing refactorings
>> twice or more.
> 
> Well, it's a long time ago that I wrote gpioirqbench, which is derived
> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
> instead of signals from the parallel port or serial line. I never
> supported the serial line for embedded boards.

What was the reason? That it is too often blocked by a terminal?

> You can get the code with:
> 
>   $ git clone git://git.denx.de/gpioirqbench
> 
> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
> 
> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD

Is this abstracting the target side, right?

> 
> Don't know if it's generic enough to support the parallel and serial
> port interface as well. Anyway, with working generic GPIO lib support,
> it's quite simple to support new hardware, e.g. i.MX31 boards.
> 
> The host side to measure precisely the latency is even more tricky.

Depends. If you can map the GPIO output on something RS232 or parallel
port compatible, you are done. Usually, there is always some x86 box
around with one of those ports, even in 2010. Would it make sense to
specify the electrical interface between host and target accordingly?
That would allow to concentrate on the target, the more interesting part.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]