Problems with using IIO buffers

Problems with using IIO buffers

[Matthias Klumpp]

Hello!
I am having troubles getting buffers to work with IIO. Querying raw
data from devices works well via sysfs, but buffered input from ADCs
does not work.

I am writing a driver for the MAX1133 ADC chip, and the poll function
to gather data is never called, while it is correctly registered using
the iio_triggered_buffer_setup() function.
Querying the device with iio_readdev fails with a timeout.

Furthermore when using the iio_dummy driver with iio_readdev from the
libiio utils, I get the exact same result: "Unable to refill buffer:
Connection timed out".

Do you maybe have any pointers for me on what to try next to make this
work? So far, all my attempts at adressing this issue yielded no
results. The Linux kernel is rather standard, but compiled with the
RT_PREEMPT patches (but I also verified that this issue exists with a
non-RT kernel as well).

Linux is at 4.8.14 on armhf, and this issue also exists with Linux 4.4.

Since I never touched IIO before, I would be very happy about getting
some pointers on how to debug this.

Kind regards,
    Matthias Klumpp

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Problems with using IIO buffers

[Peter Meerwald-Stadler]

Hello,

> I am having troubles getting buffers to work with IIO. Querying raw
> data from devices works well via sysfs, but buffered input from ADCs
> does not work.

how do you setup the buffer from userspace? see e.g.
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf, 
page 21

regards, p.

-- 

Peter Meerwald-Stadler
+43-664-2444418 (mobile)

Re: Problems with using IIO buffers

[Peter Meerwald-Stadler]

Hello,

> >> I am having troubles getting buffers to work with IIO. Querying raw
> >> data from devices works well via sysfs, but buffered input from ADCs
> >> does not work.
> >
> > how do you setup the buffer from userspace? see e.g.
> > http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf,
> > page 21
> 
> I used what iio_readdev does, but setting up the buffer manually on
> sysfs (using a sysfs trigger as current_trigger), I get
> "echo: write error: Invalid argument" when trying to enable the buffer
> (writing 1 to buffer/enable).
> 
> I tried this on the iio_dummy module, enabling the in_voltage0 channel.

this is what I use (Ubuntu, Linux 4.4) and it works; maybe the trigger 
name you use is incorrect?

modprobe iio_trig_sysfs
modprobe iio_dummy (make sure CONFIG_IIO_SIMPLE_DUMMY_BUFFER is #defined)
cd /sys/bus/iio/devices/iio_sysfs_trigger
echo 123 > add_trigger
cd /sys/bus/iio/devices/trigger0
cat name # should give sysfstrig123
cd /sys/bus/iio/devices/iio:device0
echo sysfstrig123 > trigger/current_trigger
echo 1 > scan_elements/in_voltage0_en
echo 1 > buffer/enable

regards, p.

-- 

Peter Meerwald-Stadler
+43-664-2444418 (mobile)

Re: Problems with using IIO buffers

[Matthias Klumpp]

2016-12-20 17:30 GMT+01:00 Peter Meerwald-Stadler <pmeerw@pmeerw.net>:
> [...]
>
> this is what I use (Ubuntu, Linux 4.4) and it works; maybe the trigger
> name you use is incorrect?
>
> modprobe iio_trig_sysfs
> modprobe iio_dummy (make sure CONFIG_IIO_SIMPLE_DUMMY_BUFFER is #defined)
> cd /sys/bus/iio/devices/iio_sysfs_trigger
> echo 123 > add_trigger
> cd /sys/bus/iio/devices/trigger0
> cat name # should give sysfstrig123
> cd /sys/bus/iio/devices/iio:device0
> echo sysfstrig123 > trigger/current_trigger
> echo 1 > scan_elements/in_voltage0_en
> echo 1 > buffer/enable

This works now, I think I messed up setting the trigger last time
(selected the wrong name, stupid...).
I now trigger the trigger via `echo 1 > trigger0/trigger_now` and try
to read data from the character device via
`iio_readdev /dev/iio:device0`, with the same result as described in
the first post - refilling the buffer doesn't work and I run into a
timeout.
When trying this with my driver, I see that the data polling function
is not called, and when (using the dummy driver) trying to get data
from the /dev/iio:device0 device without using iio_readdev, I also get
no result.

Clearly, it feels like I am missing something obvious here...

Regards,
    Matthias

Re: Problems with using IIO buffers

[Jonathan Cameron]

On 20/12/16 16:49, Matthias Klumpp wrote:
> 2016-12-20 17:30 GMT+01:00 Peter Meerwald-Stadler <pmeerw@pmeerw.net>:
>> [...]
>>
>> this is what I use (Ubuntu, Linux 4.4) and it works; maybe the trigger
>> name you use is incorrect?
>>
>> modprobe iio_trig_sysfs
>> modprobe iio_dummy (make sure CONFIG_IIO_SIMPLE_DUMMY_BUFFER is #defined)
>> cd /sys/bus/iio/devices/iio_sysfs_trigger
>> echo 123 > add_trigger
>> cd /sys/bus/iio/devices/trigger0
>> cat name # should give sysfstrig123
>> cd /sys/bus/iio/devices/iio:device0
>> echo sysfstrig123 > trigger/current_trigger
>> echo 1 > scan_elements/in_voltage0_en
>> echo 1 > buffer/enable
> 
> This works now, I think I messed up setting the trigger last time
> (selected the wrong name, stupid...).
> I now trigger the trigger via `echo 1 > trigger0/trigger_now` and try
> to read data from the character device via
> `iio_readdev /dev/iio:device0`, with the same result as described in
> the first post - refilling the buffer doesn't work and I run into a
> timeout.
> When trying this with my driver, I see that the data polling function
> is not called, and when (using the dummy driver) trying to get data
> from the /dev/iio:device0 device without using iio_readdev, I also get
> no result.
> 
> Clearly, it feels like I am missing something obvious here...

Just to check.

Triggering is per 'scan'. It's perhaps closer to the trigger on a camera
that than on an oscilloscope if that helps.

Are you firing the trigger multiple times?

It sounds like you are refilling the buffer in your driver so possibly
we are looking at different problems in the two cases?

Perhaps post an RFC of your driver for us to take a look at?

Let us know if you got this sorted. I've been rather snowed under and
out of touch for the last few weeks!

Jonathan

> 
> Regards,
>     Matthias
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Problems with using IIO buffers

[Matthias Klumpp]

2016-12-30 19:34 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
> [...]
> Just to check.
>
> Triggering is per 'scan'. It's perhaps closer to the trigger on a camera
> that than on an oscilloscope if that helps.

Right... I am not yet sure if this is the thing I need to do to
acquire data quickly, but from looking at the other DAQ drivers it
seems to be.

> Are you firing the trigger multiple times?

Usually only once, but even then I should get data, right?

> It sounds like you are refilling the buffer in your driver so possibly
> we are looking at different problems in the two cases?

The problem is that I can't even make the iio_dummy driver work
properly, so even if there is a bug in my driver, the dummy driver at
least should work.
When using my actual driver, firing a trigger doesn't seem to run a scan at all.

> Perhaps post an RFC of your driver for us to take a look at?

I could certainly do that, maybe tomorrow - but I suppose there is a
more general issue with this, if I can't even get the iio_dummy driver
to work with the tools provided by libiio and the kernel userspace
tools. (It still feels a bit like I am missing some obvious
information...)

> Let us know if you got this sorted. I've been rather snowed under and
> out of touch for the last few weeks!

Thanks, I'll do - I am still out of ideas though - but maybe when I
look at this again tomorrow (after two weeks of not thinking about it)
I'll notice some obvious mistake ;-) (although that's probably
unlikely).

 --- Matthias

Re: Problems with using IIO buffers

[Matthias Klumpp]

Hi!

The iio_dummy test module works now with the iio_generic_buffer test
program :-) (libiio still doesn't do what I want though).
My own driver does recognize the trigger call but does not acquire
data, likely due to a mask that is set to something I don't implement
yet (maybe checking for IIO_CHAN_INFO_RAW was not enough).

In any case, it looks like I need to continuously trigger the
(software) trigger to move data into the buffer - is there any way to
automate that, i.e. by saying "give me X samples" or "acquire data for
3ms"? Or do I always need to trigger from userspace or use a hardware
trigger?

Regards,
    Matthias

Re: Problems with using IIO buffers

[jic23]

On 10.01.2017 13:29, Matthias Klumpp wrote:
> Hi!
> 
> The iio_dummy test module works now with the iio_generic_buffer test
> program :-) (libiio still doesn't do what I want though).
> My own driver does recognize the trigger call but does not acquire
> data, likely due to a mask that is set to something I don't implement
> yet (maybe checking for IIO_CHAN_INFO_RAW was not enough).
> 
> In any case, it looks like I need to continuously trigger the
> (software) trigger to move data into the buffer - is there any way to
> automate that, i.e. by saying "give me X samples" or "acquire data for
> 3ms"? Or do I always need to trigger from userspace or use a hardware
> trigger?
> 
> Regards,
>     Matthias
Hi Matthias,

At the moment we have no oscilloscope style triggering.  It's been a 
topic
of discussion recently in the form of trees of triggers (one trigger 
starts
another firing on say a high resolution timer), but no code exists yet.

One easy option is to use a high resolution timer trigger in conjunction
with setting the watermark on a given buffer.   Thus it might capture 
more
data but it will at least come back to userspace only when there is 
'enough'
data.

The triggering is really about synchronising multiple sensor streams so
has to be a one trigger per one sample scan (set of samples from across
a number of channels).

Jonathan

Re: Problems with using IIO buffers

[Mani Sadhasivam]

Hello Mathias,

For iio_readdev api, the default timeout is 1s that's why you're getting timeout error as the trigger fails to happen within that timeout period.

It'd be worth to note that this api is not a blocking call.

If you wanna use iio_readddev you can probably increase the timeout in local.c file of libiio source.

Change the timeout value of DEFAULT_TIMEOUT_MS to 5000 or anything which will let the trigger to happen. Depending upon the buffer and sample
size you'll require corresponding number of triggers.

For instance, for the buffer length of 2 and you want 2 samples

iio_readdev -t sysfstrig1 -b 2 -s 2 mydev

In this case, if 2 triggers happen within that timeout period, iio_readdev api will successfully return the buffer content.

But for iio_generic_buffer, buffer contents are returned after getting enough triggers (blocking).

Thanks,
Mani