Hello Bob, I exactly concur with you about using the threaded interrupt. I was trying to make do with an existing code, and finding issues there. Thanks for the reply. I will modify the driver and see what is the outcome. One question is, in the threaded irq handler, is it okay to do i2c transfer, with the interrupt disabled? I need to check the status of the controller, to see which is the source of the irq. Thanks, Arindam
On Tue, Aug 30, 2011 at 6:28 AM, Robert Beckett <[email protected]>wrote: > You would only get a race condition if the suspend code is contending the > same lock as the thread. Unlikely if there is no locking. > > The kernel does not stop kthreads when suspending. > Each kthread that runs a main loop should call try_to_freeze() in its main > loop. This will let it detect the suspend and put it in the refrigerator > while it is in suspend. > If you need a kthread, then generally the suspend handler should wake it up > from whatever wait state it is in, and the thread would immediately call > try_to_freeze(). > > If you are only using the kthread as a defered interrupt handler (i.e. it > only does work as a response to a raised interrupt), then you should just > use a deferred interrupt handler. See request_threaded_irq for details > (kernel/irq/manage.c). The request_threaded_irq call is there for doing > exactly this sort of thing (and is what the plain request_irq will call > underneath). Using this, there is no need to have your own thread, and it > avoids having to do your own signalling between the isr and thread. > > Regards > > Bob > > > > On 30/08/11 00:58, scorproy wrote: > >> Hello, >> If I have a driver with the following setup, on an SMP system: >> 1. When IRQ is high, ISR is fired, which schedules a work function, >> and also sets a completion flag >> 2. A kthread is being in the background, with an infinite whole loop. >> which waits for this completion >> 3. Upon completion, process the work, and again goes back to wait. >> >> My queries are as follows: >> 1. If I am doing a suspend, on an smp system, can there be a race >> condition between the driver suspend code >> and the the kthread code? >> 2. Does the kernel take care that when the kernel starts to to call >> suspend, all the kthreads are stopped? >> >> Thanks, >> Arindam >> >> > -- > unsubscribe: > android-kernel+unsubscribe@**googlegroups.com<android-kernel%[email protected]> > website: > http://groups.google.com/**group/android-kernel<http://groups.google.com/group/android-kernel> > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
