Re: [PATCH 2.6.13-rc5-gitNOW] msleep() cannot be used from interrupt

[Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>]

On Fri, Aug 05, 2005 at 11:53:29AM -0700, Andrew Morton wrote:
> 
> That's all pretty sad stuff.  I guess for now we can go back to the busy
> loop.  Longer-term it would be nice if we could tune up the HPET driver in
> some manner so we can avoid this busy-wait-in-interrupt.
> 
> I'm not sure who the HPET maintainer/expert is nowadays.  Robert Picco did
> the original work but I haven't seen Robert around for a long time?

Actually there are two parts in HPET. 
1) Using HPET for kernel timer and RTC emulation
2) HPET driver to export timers to user(/dev/hpet) and kernel drivers

We did the part (1) for i386 and I think Andi/Vojtech did (1) for x86_64. And 
Robert Picco did (2).

So, using rtc_get_rtc_time() in an interrupt handler will be my code. In this
part we try to emulate RTC interrupt using HPET and we have to read the current
RTC time in the interrupt handler. I can't think of any way of not doing
rtc_get_rtc_time here.

I think we should have two versions of rtc_get_rtc_time. One which does msleep,
that can be called from process context (in drivers/char/rtc.c) and one that
can be called from interrupt context (i386 and x86_64 hpet time routines). Or 
same routine behaving differently depending on where it is called from.

And for the hpet rtc emulation routines it should be OK even if the time is 
slightly off and not exact. So, probably we should be able to force read
rtc even when update is in progress. That way we can avoid the busy loop.
Unless RTC returns grossly wrong time values while UIP flag is set. I need to
look at RTC specs to verify that.

Thanks,
Venki