Jan Kiszka wrote:
> 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.
>
However, as a matter of fact, they are currently logically coupled. Let
me detail my point, considering it from the Xenomai viewpoint, depending
on the combinations of the two options we have been referring to:
** !CONFIG_X86_LOCAL_APIC && CONFIG_HPET_TIMER
=> Xenomai interposes on IRQ0 as normally generated by the HPET in LRR
mode, but unfortunately makes the false assumption that the PIT is the
active timer device and attempts to program it while managing timers
in the real-time space, so no IRQ0 is ever generated. This leads to a
complete lossage of clock event interrupts for both Linux and Xenomai.
This is why we currently prevent such configuration from being set, at
Kconfig-level.
** CONFIG_X86_LOCAL_APIC && CONFIG_HPET_TIMER
=> Xenomai always requests the LAPIC for timing because
CONFIG_X86_LOCAL_APIC is defined, and always emulates host ticks by
propagating forged interrupts to the LOCAL_TIMER_VECTOR (since v2.4.x,
at least). Then, we have to consider how Linux's evtdev is set:
o if evtdev == HPET (and of course LAPIC is not dummy), then we would
have two Linux timer ticks per period (one emulated by Xenomai to the
local APIC timer vector, one real from the HPET to IRQ0) which would
obviously be wrong,
o if evtdev == LAPIC, then things would work, Xenomai would both handle
the host and the real-time ticking by managing the timer device for both
domains.
** Therefore, a valid setup is either:
CONFIG_X86_LOCAL_APIC && CONFIG_HPET_TIMER, if evtdev == LAPIC
or
CONFIG_X86_LOCAL_APIC && !CONFIG_HPET_TIMER, implying evtdev == LAPIC
=> In which cases, Linux's clock evtdev must be LAPIC. If so, testing
about the current evtdev name like your patch does, as if it could be
different from "lapic", and in consequence as if we would allow a
different interrupt source for the Linux tick than the LAPIC when
CONFIG_X86_LOCAL_APIC is set, is _currently_ useless because not yet
implemented at Xenomai level, even if the idea underlying the patch is
generally right.
For this reason, I earlier merged your patch into the x86_32 section
since we may have !CONFIG_X86_LOCAL_APIC, in which case the PIT may be
used and we have to consider __ipipe_tick_irq as a true variable.
However, I did not merge this change on purpose yet into the x86_64
section, mainly as a reminder that we currently assume that
CONFIG_X86_LOCAL_APIC is always enabled on this arch, which raises the
issues above.
Fortunately for us, the LAPIC has a better rating as a clock event
device than the HPET, provided the Linux calibrator is happy with its
stability. Therefore, we should have evtdev == LAPIC most of the time,
at least with "decent x86 hardware" (which depending one one's mood,
sometimes may look like a nice oxymoron).
This is why I basically agree with your patch because indeed, Xenomai
will have to be made HPET-compliant at some point in time, but at the
same time, I have to raise the concern that this patch won't be enough
for proper timing in the _current_ Xenomai situation.
>> 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.
>
Yes, sorry for the noise, I was wrong. Using the HPET in LRR mode is
still clearly wired into the 2.6.24 code.
>
> As long as the APIC is available to Xenomai, we should no longer worry
> about Linux using some other clockevent device.
Provided we don't relay the host tick when Xenomai grabs the LAPIC
whilst Linux is also notified from incoming timer ticks by interrupts
from another 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.
>
Great, thanks.
--
Philippe.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
