On Mon, 2024-08-26 at 12:29 +0100, Jonathan Cameron wrote: > > Is there a similar mechanism within IIO, or how do others typically > > address this problem on slower processors? If there isn't, would > > implementing such a feature in IIO make sense? I tackled this by > > simply not using IIO triggers, and only thing I thought to make use > > of was simply blocking poll calls with synchronization primitives > > until the former trigger finishes. I would appreciate your thoughts > > and suggestions. > > Roughly speaking combination of using level interrupts for > the hardware irq (so we can come around later if the interrupt > won't refire on next sample) and being careful with the sequencing > in the driver. Also IRQF_ONESHOT typically for the trigger > to ensure interrupt is only enabled when threads are done > (so if the level is still true, you immediately retrigger). > In some more fiddly cases it may be necessary to disable the > interrupt > whilst doing handling but that is very rare and usually > because the device does something bad with the interrupt > line during data read out. > > Good to have some more details of how you have tied everything > together. > > For the trigger, is it using a threaded interrupt, or calling > iio_trigger_poll() from the non threaded part? I used a threaded_irq and polled in the threaded part. For me, to use iio_trigger_generic_data_rdy_poll did not work somehow, neither in irq nor in threaded_irq. I use 'iio_trigger_poll_chained/nested' for polling although I have a single consumer. I do the things just like MAX11410's driver. Using threaded irq but not using hard part, using trigger but not using top half too. And polling chained/nested. Whatever I have tried besides of it, it just did not work. Maybe I couldn't get it done. I am doing it just how MAX11410's driver does it. But still, I do not think this scenario will work out if HARDIRQS_SW_RESEND is not set in case of a device using edge interrupt and does not automatically resets its drdyout: https://elixir.bootlin.com/linux/v6.10.6/source/drivers/iio/adc/max11410.c I got back to device and tried level interrupts. Apparently, last time I tried I messed things up and blamed level interrupts and has not tried to use them again. Now I see I was mistaken because it works great now. Thanks for the advice. > So I'm assuming you are using the device drdyout as the indicator > of data. Are you treating that as an edge interrupt? If so > you will run into lots of pain. It's a long time since it was > common to get interrupt controllers that couldn't do level > interrupts. > I suspect you want to treat it as a level interrupt with > IRQF_ONESHOT set to indicate that the interrupt should > not be reenabled until the thread is done. That thread > should only be done after all consumers of the trigger > have completed. Isn't what some portion of IIO devices in kernel do? For example, ADXL355, calls 'iio_trigger_poll' in hard interrupt context, and it still works charmingly. It has edge interrupts in YAML documentation. Maybe I should ask it's maintainers. Overall, my problems caused by not lack of features, but my lack of knowledge. Thanks for taking time to answer Jonathan. Also sorry for bad formatting of my former email. It was my first plain-text email to kernel. Best, Ibrahim.
