iio_interrupt_trigger

Hi

I'm trying to set on a IMX6 SoC (wandboard) a PWM to use as a 'iio_interrupt_trigger' source. I can't figure out how to assign the pwm to the 'iio_interrupt_trigger' module in the device tree source. (The pwm an the iio adc device when sysfs triggered is working fine)

Any suggestions?

Thanks
Matthias

The problem is that you can't really instantiate the iio-interrupt-trigger from the devicetree. IIO is a software concept, there is no hardware associated with it that you could describe in the devicetree.

There have been discussions in the past about implementing a pwm trigger, similar to the existing iio-trig-bfin-timer.c trigger driver. But instead of directly accessing the PWM/Timer hardware registers use the PWM API. This requires some extensions to the PWM API though, so we can export the IRQ associated with the PWM device.

So far nobody has stepped up to implement this, but sounds like a fun project, doesn't it? ;)

- Lars

iio-interrupt-trigger

I managed to execute the 'iio_interrupt_trigger' ISR by executing 'generic_handle_irq(intnr)' out of my PWM ISR - it works but its ugly.

For 'intnr' I used a gpio interrupt number on which I registerd the platform data for 'iio_interrupt_trigger' inside the 'pwm-imx' driver.

I also tried to share the same intnr for 'iio_interrupt_trigger' and the pwm but this did not work.

Is it possible to get a software INT Nr somehow istead of a gpio interrupt?

Btw:
generic_buffer from 4.1.y
works well on 4.1.y and 4.2.y kernel,

whereas generic_buffer from 4.2.y and v4.3-rc6
gives following error on a 4.2.y

"Problem reading scan element information
diag /sys/bus/iio/devices/iio:device0
"

thx Matthias

Just for information...

I estimated the max ISR rate and sampling accuracy when using iio buffering triggered by a hardware PWM timer on a IMX6 dl board:

Up to a ISR rate of ~5kHz the accuracy of the sampling time is about +/-25us (measured over several seconds).

Above 10kHz, interrupts are lost (but CPU load still <25%).

Test conditions:

For this test I modified 'generic_buffer' so I could estimate the accuracy of the sampling point (by calculating min/max/mean of the time difference. The kernel was 4.2.1 with CONFIG_PREEMPT=y
The ADC device I used is a AD7476 connected via SPI bus.
The scaling_governor was set to performance.
No additional load (buildroot rfs).
The results are about same when using a 4.1 TT-patched kernel with CONFIG_PREEMPT_RT_FULL=y (without special isr priority).

Conclusion: accurate high(er) speed sampling seems not to be possible this way (without dma buffered continuous sampling)

-- Matthias

Yeah, that is similar to my findings. 5kHz-10kHz is around the maximum you can do with interrupt driven capture. For higher datarates you'll have to dedicate a full CPU to polling the data, which is kind of sub-optimal.

I've been working on the concept of SPI offloading, which allows to pre-program the SPI message to the controller and let the controller execute it when the interrupt happens. But this required dedicated hardware support and is not available with all SPI controllers.

The SPI Engine framework allows to create controller that support this type of offloading, see https://wiki.analog.com/resources/fpga/peripherals/spi_engine

- Lars