Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Philippe Gerum <rpm@xenomai.org>]

Philippe Gerum wrote:
> Hannes Mayer wrote:
> 
>> Ciao Philippe!
>>
>> Philippe Gerum wrote:
>>
>>> Hannes Mayer wrote:
>>>
>>>> Hi all!
>>>>
>>>> I was just wondering if calling do_gettimeofday in an ADEOS interrupt
>>>> handler might cause any problems whatsoever ?
>>>>
>>>> My ISR:
>>>> flags = adeos_critical_enter (NULL);
>>>> [...]
>>>> do_gettimeofday()
>>>> [...]
>>>> adeos_critical_exit (flags);
>>>>
>>>> I saw that the code for do_gettimeofday is different in kernel 2.4 and
>>>> kernel 2.6:
>>>>
>>>> Kernel 2.4:
>>>> void do_gettimeofday(struct timeval *tv) {
>>>> [...]
>>>> read_lock_irqsave(&xtime_lock, flags);
>>>> [...]
>>>> read_unlock_irqrestore(&xtime_lock, flags);
>>>>
>>>> Kernel 2.6:
>>>> void do_gettimeofday(struct timeval *tv) {
>>>> [...]
>>>> do {
>>>> [...]
>>>> seq = read_seqbegin(&xtime_lock);
>>>> [...]
>>>> } while (read_seqretry(&xtime_lock, seq));
>>>>
>>>> Well, read_lock_irqsave in 2.4 looks like a possible source for 
>>>> trouble,
>>>> while read_seqbegin in 2.6 doesn't do anything with interrupts, right ?
>>>>
>>>
>>> Yes, but that's not better anyway. Imagine what would happen if an 
>>> undergoing write sequence on the xtime_lock in the Linux domain was 
>>> preempted by an ISR from a higher priority domain which in turn calls 
>>> do_gettimeofday(): the read sequence running over your high priority 
>>> ISR would then loop on read_seqretry(), waiting for the undergoing 
>>> write to end. Problem is, that the undergoing write sequence would 
>>> not be allowed to resume until your current high priority domain 
>>> running do_gettimeofday() relinquishes the processor. Catch 22. This 
>>> could happen in both UP and SMP configs, not to speak of the funky 
>>> behaviour one would get with the additional spinlock recursion issue 
>>> over SMP, since a write sequence also grabs a spinlock.
>>
>>
>>
>> Late "thank you"! Sorry! Was ill, but now I'm doing better.
>>
>> So do_gettimeofday is out of question...
>>
>> What would you suggest to do to get absolute time in RT context ?
>> I'd be more than happy if you'd have a few pointers for me.
> 
> 
> Since you cannot fiddle safely with Linux internals in RT context, I'd 
> suggest you keep track of your RTOS's "epoch", saving Linux's count of 
> jiffies and the current TSC when it boots, then each time you need the 
> current date, convert the difference between the current TSC and the 
> initial TSC to jiffies, and finally use the initial jiffy count as an 
> offset to compute the real date.
> 

Sidenote: this also means that using variable CPU freqs would be out of 
question, but doing so is not an option as soon as the RT support is 
required anyway, so I guess it would be ok.

-- 

Philippe.