Re: newbie delay/sleep question


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!

It seems you different interrupts. If you return from your first ISR,
you are aleady in the state you call "sleep". Next interrupt comes,
your second ISR will process may be something more than first one.
Thing is that, there is no shcdule mechanism taskquest or whatever that
can give you 20 microseconds, unless it's a interrupt like you have
hardware timer...

.

Relevant Pages

  • 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)
  • Re: Premature wakeup of time.sleep()
    ... >> clock, shich varies from os to os. ... Once you have a wakeup time, you can put your sleeper in a time-ordered queue, ... have the option of a hot return as if the sleep call hadn't happened. ... meaning any time there is any interrupt. ...
    (comp.lang.python)
  • Re: Conversing with a tcl application...
    ... If the interrupt count for the keyboard, touchpad, ... will awake the computer from the sleep state. ...
    (comp.lang.tcl)
  • Re: newbie delay/sleep question
    ... microseconds and then do some other task. ... another interrupt within that 100 microseconds and the sleep I've been ... receive the interrupt and queue them up on a tasklet or work/wait queue ...
    (comp.os.linux.development.system)
  • Re: [PATCH] Remove process freezer from suspend to RAM pathway
    ... When your hardware can put itself to sleep and atomically preserve memory as it does so, you don't need an atomic copy. ... Ensure that the other CPUs have finished any trailing interrupt handlers and put them to sleep ... After you've set the "no_bind" flag, you won't get any *new* subdevices trying to bind, therefore it's safe to iterate over the list of present sub-devices and suspend them. ... When all the leaf devices are off, the parent device can be turned off because everything waiting on the leaf devices is blocked on them and won't unblock until the parent device *AND* the leaf device are turned on again, in that order. ...
    (Linux-Kernel)