Yes, it should be fine to do i2c accesses during the thread_fn handler.
You should not attempt i2c during the actual handler though as most i2c
drivers require sleeping.
When requesting the threaded irq, you can not set the handler, and just
set the thread_fn, but make sure that you use IRQF_ONESHOT in the flags
so that the irq is not enabled until after the thread_fn returns handled.
Hope this helps
Bob
On 30/08/11 18:45, Arindam Roy wrote:
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] <mailto:[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: [email protected]
<mailto:android-kernel%[email protected]>
website: http://groups.google.com/group/android-kernel
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-kernel
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-kernel
