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.
