Re: newbie delay/sleep question


malc wrote:
"cstahl3" <carl.stahl@xxxxxxxx> writes:

malc wrote:
Aaron Isotton <aaron@xxxxxxxxxxx> writes:

cstahl3 wrote:
I am developing a device driver that handles an interrupt. When my
device driver receives the interrupt I would like to sleep for 100
microseconds and then do some other task. My problem is I may receive
another interrupt within that 100 microseconds and the sleep I've been
trying to do is blocking the next guy from executing on time (waiting
for the first guy to finish sleeping).

I've been looking at using timers, task queues, and work queues, but
I'm not exactly sure if that's the way to go and it seems if I base my
delay on jiffies, I will not be able to satisfy my microsecond sleep
requirement. Any ideas?

[..snip..]

I completely missed the fact that the orignal post implied kernel mode, sorry
about that (only one of the points against RDTSC is affected by this though).
I have forgotten the most serious one however:

RDTSC is nowhere near being reliable clock source on CPUs that do
frequency scaling.

I'm working on a svme181 ppc and it looks like jiffies only gives me
millisecond granularity. Someone suggested to use sys_rt_sigtimedwait
but I'm not sure if I could generate signals at the kernel level to
cause a wait. I'm also not sure on how to implement a work queue or
tasklet, or if that's the way to go for processing multiple interrupts
coming in without blocking. I'd like all of them to process and sleep
accordingly.


Perhaps http://www.linuxjournal.com/article/8144 would be of some help.

I'm however not sure what do you really mean by: receiving an interrupt,
sleeping after that and then doing some other task. Do you really want
to sleep in an IRQ handler? Besides `task' is rather overloaded term.

--
vale

I don't want to sleep in the irq handler, my top half is going to
receive the interrupt and queue them up on a tasklet or work/wait queue
of some sort (this is the part I don't understand) and in the bottom
half, I'd like to process each of the interrupts that come in 20
microseconds later. My problem is, I need a very small sleep/delay
after every interrupt that I receive but I don't want to block my
driver. I'll check out that article, thanks!

.

Relevant Pages

  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... Jiffies are increased at every tick (kernel tick, not clock tick), so ...
    (comp.os.linux.development.system)
  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... Jiffies are increased at every tick (kernel tick, not clock tick), so ...
    (comp.os.linux.development.system)
  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... Jiffies are increased at every tick, so ...
    (comp.os.linux.development.system)
  • newbie delay/sleep question
    ... I am developing a device driver that handles an interrupt. ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ...
    (comp.os.linux.development.system)
  • Re: 8ms Timer for serial port access
    ... sleep has a grainularity of 10ms. ... and that's at the next 10ms interrupt. ... -scheduler runs as soon as the driver tasklett completes. ... Disable the FIFO on your UART so you get an interrupt for every byte. ...
    (comp.os.linux.development.apps)