iio_interrupt_trigger

iio_interrupt_trigger

[Matthias Meier]

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

Re: iio_interrupt_trigger

[Lars-Peter Clausen]

On 10/18/2015 02:53 PM, Matthias Meier wrote:
> 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?

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

Re: iio_interrupt_trigger

[Matthias Meier]

> 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.

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

Re: iio_interrupt_trigger

[Matthias Meier]

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

Re: iio_interrupt_trigger

[Lars-Peter Clausen]

On 10/20/2015 07:05 PM, Matthias Meier wrote:
> 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)

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