Re: [Xenomai-core] ns vs. tsc as internal timer base

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jim Cromie wrote:
>>> Philippe Gerum wrote:
>>>
>>>> Gilles Chanteperdrix wrote:
>>>>
>>>>> Philippe Gerum wrote:
>>>>>  > Redone the check here on a Centrino 1.6Mhz, and still have
>>>>> roughly x20  > improvement (a bit better actually). I'm using
>>>>> Debian/sarge gcc 3.3.5.
>>>>>
>>>>> I think I remember that Pentium M has a much shorter mull instruction
>>>>> than other processors of the family.
>>>>>
>>>> That would explain. Anyway, as John Stulz put it:
>>>> "math is hard, lets go shopping!"
>>>>
>>> Heh.  Appropriate that his name (Stultz) comes up here, as his
>>> generic-time (GTOD)
>>> patchset looks headed for 2.6.18, bringing with it a full re-working
>>> of linux timers / timeofday.  IN this new world, time is kept on
>>> free-running counters.
>>>
>>> Ive been running this patchset on my soekris for some time, since
>>> GTOD detects that the TSC counts slowly, calls it insane, and does timing
>>> with the PIT.
>>>
>>> With GTOD, writing a new clocksource driver is easy, enough so I could
>>> do it.
>>> My clocksource patch uses the 27 mhz timer on the Geode CPU.
>>> Once the TSC is de-rated, mine becomes the best clocksource, and GTOD
>>> switches to it.
>>>
>>> All of which is to say ..
>>> new mainline code is coming, should this current rework notion wait,
>>> given that its will all need revisited again later
>>>
>> Clearly yes, since this is going to impact Adeos too. GTOD is going to
>> fiddle with the PIT channels in a way Adeos needs to be aware of, in
>> order for the client RTOS to reuse such timer. Added to the flow of
>> other core changes planned for 2.6.18, this is likely going to be funky.
>>
>> "Find wall. Beat head against same."
>>
> 
> May not be required: the GTOD and clocksource abstractions could provide
> a clean way to register some virtual, Adeos- or RTOS-provided clock with
> Linux. And that clock may even lose ticks without Linux losing its
> system time! So far for the theory, practice may still require walls...
> 

Some refinement: clocksource may either remain TSC or become a
Xenomai-provided clock if its handling (PIT...) requires
synchronisation. The clockevent, the one thing that triggers timer IRQs,
could become a virtual device driven by Xenomai. And GTOD should happily
make use of them instead of messing up with shared hardware.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]