Philippe Gerum wrote: > 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)
Eek, ok, my brain is definitely in low power mode. if we don't use the same clock device than Linux, then we should neither emulate the periodic tick, nor receive any host tick programming requests anyway from Linux. Ok, forget about this. Let's be happy, and merge this. We should only have to take care of the remaining issue #1. -- Philippe. _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
