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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 5 Aug 2005, Venkatesh Pallipadi wrote:

> 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

The usual way is to read all time registers, save those values.
Read all registers again. Do this until the two consecutive reads
return the same values. You never have to busy-wait at all.
When I do this, I put the values read in two arrays, I memcmp()
them and, if not the same use memcpy() to copy new to old and
try again.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux