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