On 02/20/2012 05:46 PM, Philippe Gerum wrote:
> On 02/19/2012 08:43 PM, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> restarting the ipipe-core is the good opportunity to look a bit at our
>> current state and think about what we could improve. On ARM, at least,
>> the thing we could improve is the timer subsystem. A long time ago,
>> linux has switched to a system allowing to select at run-time which
>> timer to use, and we do not really benefit from this, what timer we use
>> is selected at compile time, resulting in a massive ifdefery on arm, and
>> even on x86, we have to select at compile time whether using the 8254 or
>> APIC, whereas we could decide to use whatever linux is using, even say
>> HPET, without any compilation option. That is assuming we want to move
>> the x86 timer-specific code from xenomai to I-pipe.
>>
>> The idea to reach this goal would be to add some ipipe specific members
>> to the struct clock_event_device, the way we do for the interrupt
>> controller:
>> - a CLOCK_EVT_FEAT_IPIPE would signal that the clockevent device is
>> ipipe capable, meaning that it implements the following callback
>> - ipipe_steal would be called when stealing the timer, we could decide
>> to call this callback either as part of ipipe_request_timer, or with a
>> specific ipipe_steal_timer call, currently we simply set
>> __ipipe_mach_timerstolen to 1, but it is pure luck that we never needed
>> something more complicated, besides, we may want to start a timer that
>> was not started by linux so, we would put its initialization here;
>> - ipipe_stolen would record whether the timer is stolen
>> - ipipe_min_delta_ticks, ipipe_max_delta_ticks would be used by the
>> ipipe_set_next_event callback
>> - ipipe_ack would be called to ack the timer interrupt the way we
>> currently do it currently on arm with __ipipe_mach_acktimer
>> - ipipe_set_next_event would program the next timer shot, the way it is
>> currently done in __ipipe_mach_set_dec.
>>
>> All this is pretty straightforward, but there is still a question: how
>> does ipipe_request_timer select a timer. The idea is that on platform
>> without PIC muting, it is probably more efficient to use the same timer
>> for linux and xenomai. But on platforms with PIC muting, we could want
>> to select a different timer for linux and xenomai, but how do we find
>> it, what if linux has not selected a timer because it is unusable on
>> that platform?
>
> Checking the clock device mode for CLOCK_EVT_MODE_SHUTDOWN, and falling
> back to sharing the active kernel tick device + disabling PIC muting?
OK. Another question is: do we want to move x86 timer handling from
xenomai to ipipe. If not, we have to find a way to support the two
possible configurations. What we could do is using the timer name in
ipipe_request_tickdev: if a timer name is supplied, we keep the old
implementation, if no timer name is supplied, we use the new
implementation which looks for the best candidate with the
CLOCK_EVT_FEAT_IPIPE bit.
--
Gilles.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
