Re: [Adeos-main] [PATCH 4/5] remove legacy code

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

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
>>>> This patch gets rid of code that is no longer needed or valid:
>>>>
>>>>  - x86_64 APIC frequency is now delivered via ipipe_request_tickdev
>>> Ack.
>>>
>>>>  - __ipipe_tick_irq is maintained via ipipe_update_tick_evtdev also on
>>>>    x86_64
>>> Client RTOS may/do assume that timing is always delivered through the
>>> local APIC timer on x86_64. We could merge that and allow the 8253 to be
>>> used as the timer device, but this would not work in practice.
>> For forget HPET. There is no wiring of the timer IRQ to the APIC
>> anymore.
> 
> My point is that whatever timer IRQs the kernel routes to INT0, be them
> from the HPET in legacy route replacement mode or from the i8253 with
> some former routing, we currently rely on the local APIC timer vector.
> No matter what, HPET it's just unsupported by Xenomai right now, so we
> can't see any IRQ0 registered as our tick device interrupt.

__ipipe_tick_irq, as it is used now, is reflecting Linux' tick IRQ, not
necessarily the one that Xenomai prefers.

> 
> If your point is about allowing HPET to be used, then your patch
> currently expects the HPET to be used in legacy replacement route mode,
> which is no more the default setup. In short, TIMER_IRQ may not be the

static struct clock_event_device hpet_clockevent = {
...
        .irq            = 0,

which is TIMER_IRQ.

> right -constant- value in the common case.
> 
>  The result is that there is no difference between x86_32 and
>> x86_64 anymore, and that's what the code reflects.
>>
>> If the client RTOS is not yet fully prepared for this, this has to be
>> fixed. And only if there is no valid Linux configuration (e.g. HPET off)
>> that results in the same timer assignment as with 2.6.23, we need a
>> workaround at I-pipe level IMHO.
>>
> 
> Again, I see no basic issue in merging that patch, but the message is:
> Xenomai still has to support more timer devices than the local APIC one
> on x86_64 (e.g. HPET), before this patch has any real upside for it. In
> short, it's ok with me, but I feel that we are still half-way from the
> complete support.

As long as the APIC is available to Xenomai, we should no longer worry
about Linux using some other clockevent device. At least in theory. But
I will carefully check again during this week if there are any
regressions or .config limitation related to these hunks.

Jan


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