From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4309DE27.3060301@domain.hid> Date: Mon, 22 Aug 2005 16:16:07 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Adeos-main] do_gettimeofday in ADEOS ISR References: <42EFF665.3060000@domain.hid> <42F07A35.7070001@domain.hid> <43039C6A.2090508@domain.hid> <4309DC79.1090009@domain.hid> In-Reply-To: <4309DC79.1090009@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: adeos-main@gna.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.