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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
