Hi Victor, I don't think it's a good idea to block an entire IRQ line for so much time (i.e. until a work queue runs), unless you're sure you're the sole user of it.
How about you try a more traditional approach and make the IRQ handler schedule a work queue after it completes? Or, if you need to run as fast as possible, why don't you create a tasklet? Remember that you can't sleep in this case. - Richard 2015-01-13 11:51 GMT-02:00 Victor Ascroft <[email protected]>: > Hello, > > Is it ok to use wait_for_completion in a workqueue? > > static void my_work(struct work_struct *work) > { > > while (true) > { > wait_for_completion(completion); > > // Do something here > > reinit_completion(completion); > enable_irq(irq); > } > } > > static irqreturn_t my_irq_handler(int irq, void *dev) > { > disable_irq(irq); > > complete(completion); > > return IRQ_HANDLED; > } > > Something like the above is what I have. Is it a correct way to > do things or complete idiotic brainfart. Workqueues can sleep so > I thought of the above code, but, was not sure. > > And I am not using _interruptible or _interruptible_timeout because > I absolutely want it to wait for the IRQ. Now as such though this > works I get stack traces with hung task complaining and I have > to set /proc/sys/kernel/hung_task_timeout_secs to 0. And were the IRQ > not generated I do get NMI watchdog hang. > > I will accept I have only little knowledge of these things. > > Regards, > Victor. > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
