More questions about IIO
Hi Jonathan,
Now that the work on the AT91 adc driver using software triggers looks well on its way to the kernel, I begin to work on hardware triggers for it.
Few questions raise though.
First, it seems that when using hardware triggers, we have to use the iio ring buffers.
So the first implementation that comes to my mind is this one :
- The probe function actually sets up the driver, the triggers, the
buffer, etc.
- Each time an interrupt is raised, the handler either fill the buffer
with the values of the activated channels or store it in a temporary variable just like I'm doing right now for the software triggers.
- When a user reads the sysfs file, either read from the buffer or
from the temporary variable.
But :
- Is it the right way to do so with iio ?
- Is there a way for the user to select at runtime if he wants only
software trigger or hardware trigger (if they are enabled in the kernel) ?
- What is the role of this pollfunc defined in the iio_dev struct ?
Also, the ADC has 4 external trigger sources, which are selected through a register. 3 of them are muxed pins, so the pins available varies from one board to another. Is there a way for the user at runtime to select the source he wants ?
Finally, this ADC supports two resolutions : 8 and 10 bit. For now, only 10 bit resolution is supported, but the user might want to use 8 bit. Is there a way to do so ?
Thanks,
Maxime
Signature · 4 lines
Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
On a train so will reply in more detail later.
Quoted 10 lines · Maxime Ripard
Hi Jonathan,
Now that the work on the AT91 adc driver using software triggers looks well on its way to the kernel, I begin to work on hardware triggers for it.
Few questions raise though.
First, it seems that when using hardware triggers, we have to use the iio ring buffers.
There are patches against staging that allow a fake buffer that routes data to input or similar but it looks much the same from the driver.
Quoted 4 lines
So the first implementation that comes to my mind is this one :
- The probe function actually sets up the driver, the triggers, the buffer, etc.
Creates infrastructure etc.
Quoted 3 lines
- Each time an interrupt is raised, the handler either fill the buffer with the values of the activated channels or store it in a temporary variable just like I'm doing right now for the software triggers.
Interupt drives a trigger. That then calls the pollfunc which does the read into the buffer. Note the trigger is associated with the device in userspace so can be provided by any device or indeed fake device.
Quoted 2 lines
- When a user reads the sysfs file, either read from the buffer or
from the temporary variable.
Yes.
Quoted 3 lines
But :
- Is it the right way to do so with iio ?
Not quite as explained... I will take a look at the datasheets later and try and point you at something similar in tree.
Quoted 3 lines
- Is there a way for the user to select at runtime if he wants only
software trigger or hardware trigger (if they are enabled in the kernel) ?
Yup. Don't enable the buffer. I need to put in a single scan buffer for in kernel interface anyway so may make sense for you to use that on long run.
Quoted 1 line
- What is the role of this pollfunc defined in the
iio_devstruct ?
Equivalent of threaded interupt to be run on a data ready or capture now interupt.
Quoted 6 lines
Also, the ADC has 4 external trigger sources, which are selected through
a register. 3 of them are muxed pins, so the pins available varies from one board to another. Is there a way for the user at runtime to select the source he wants ?
Yes create lots of triggers.
Quoted 6 lines
Finally, this ADC supports two resolutions : 8 and 10 bit. For now, only
10 bit resolution is supported, but the user might want to use 8 bit. Is
there a way to do so ?
Never seen a use case for sysfs users. Can in theory control it for buffered data but I think the core support is missing. Sca3000 used to do it.
Quoted 9 lines
Thanks,
MaximeSignature · 4 lines
Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Signature · 2 lines
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Hi Jonathan,
Thanks for the first replies.
Quoted 10 lines · Jonathan Cameron
On a train so will reply in more detail later.
Quoted 6 lines · Maxime Ripard
Hi Jonathan,
Now that the work on the AT91 adc driver using software triggers looks well on its way to the kernel, I begin to work on hardware triggers for it.
Quoted 5 lines
Quoted 4 lines
Few questions raise though.
First, it seems that when using hardware triggers, we have to use the iio ring buffers.
There are patches against staging that allow a fake buffer that routes data to input or similar but it looks much the same from the driver.
Ok
Quoted 14 lines
Quoted 3 lines
So the first implementation that comes to my mind is this one :
- The probe function actually sets up the driver, the triggers, the buffer, etc.Creates infrastructure etc.
Quoted 3 lines
- Each time an interrupt is raised, the handler either fill the buffer with the values of the activated channels or store it in a temporary variable just like I'm doing right now for the software triggers.
Interupt drives a trigger. That then calls the pollfunc which does the read into the buffer. Note the trigger is associated with the device in userspace so can be provided by any device or indeed fake device.
Quoted 2 lines
- When a user reads the sysfs file, either read from the buffer or
from the temporary variable.Yes.
Quoted 3 lines
But :
- Is it the right way to do so with iio ?
Quoted 7 lines
Not quite as explained... I will take a look at the datasheets later and try and point you at something similar in tree.
Quoted 3 lines
- Is there a way for the user to select at runtime if he wants only
software trigger or hardware trigger (if they are enabled in the kernel) ?Yup. Don't enable the buffer. I need to put in a single scan buffer for in kernel interface anyway so may make sense for you to use that on long run.
Quoted 1 line
- What is the role of this pollfunc defined in the
iio_devstruct ?Equivalent of threaded interupt to be run on a data ready or capture now interupt.
I'm confused here. You said earlier that the pollfunc was reading from the buffer. But if it is similar to a threaded interrupt, I'm more expecting it to be writing into the buffer, no ? Or there is two buffers ?
Quoted 6 lines
Quoted 5 lines
Also, the ADC has 4 external trigger sources, which are selected through
a register. 3 of them are muxed pins, so the pins available varies from one board to another. Is there a way for the user at runtime to select the source he wants ?Yes create lots of triggers.
Ok, fine by me :)
Quoted 6 lines
Quoted 5 lines
Finally, this ADC supports two resolutions : 8 and 10 bit. For now, only
10 bit resolution is supported, but the user might want to use 8 bit. Is
there a way to do so ?Never seen a use case for sysfs users. Can in theory control it for buffered data but I think the core support is missing. Sca3000 used to do it.
Ok
Signature · 4 lines
Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Jonathan Cameron
maintainerQuoted 41 lines · Maxime Ripard
Hi Jonathan,
Thanks for the first replies.
Quoted 10 lines · Jonathan Cameron
On a train so will reply in more detail later.
Quoted 6 lines · Maxime Ripard
Hi Jonathan,
Now that the work on the AT91 adc driver using software triggers looks well on its way to the kernel, I begin to work on hardware triggers for it.
Quoted 5 lines
Quoted 4 lines
Few questions raise though.
First, it seems that when using hardware triggers, we have to use the iio ring buffers.
There are patches against staging that allow a fake buffer that routes data to input or similar but it looks much the same from the driver.
Ok
Quoted 18 lines
Quoted 3 lines
So the first implementation that comes to my mind is this one :
- The probe function actually sets up the driver, the triggers, the buffer, etc.Creates infrastructure etc.
Quoted 3 lines
- Each time an interrupt is raised, the handler either fill the buffer with the values of the activated channels or store it in a temporary variable just like I'm doing right now for the software triggers.
Interupt drives a trigger. That then calls the pollfunc which does the read into the buffer. Note the trigger is associated with the device in userspace so can be provided by any device or indeed fake device.
Quoted 2 lines
- When a user reads the sysfs file, either read from the buffer or
from the temporary variable.Yes.
Quoted 3 lines
But :
- Is it the right way to do so with iio ?Not quite as explained... I will take a look at the datasheets later and try and point you at something similar in tree.
Quoted 3 lines
- Is there a way for the user to select at runtime if he wants only
software trigger or hardware trigger (if they are enabled in the kernel) ?
Quoted 7 lines
Quoted 3 lines
Yup. Don't enable the buffer. I need to put in a single scan buffer for in kernel interface anyway so may make sense for you to use that on long run.
Quoted 1 line
- What is the role of this pollfunc defined in the
iio_devstruct ?Equivalent of threaded interupt to be run on a data ready or capture now interupt.
I'm confused here. You said earlier that the pollfunc was reading from the buffer. But if it is similar to a threaded interrupt, I'm more expecting it to be writing into the buffer, no ? Or there is two buffers ?
Nope. It reads data and pushes it to the buffer. It is basically a threaded interrupt - wrapped up somewhat for convenience. The enabling of the relevant interrupt occurs in iio_triggered_buffer_postenable. Actually it only gets one from the per trigger poll of interrupts at this stage. Until then there is no point.
Quoted 19 lines
Quoted 7 lines
Quoted 6 lines
Also, the ADC has 4 external trigger sources, which are selected through
a register. 3 of them are muxed pins, so the pins available varies from one board to another. Is there a way for the user at runtime to select the source he wants ?Yes create lots of triggers.
Ok, fine by me :)
Quoted 6 lines
Quoted 5 lines
Finally, this ADC supports two resolutions : 8 and 10 bit. For now, only
10 bit resolution is supported, but the user might want to use 8 bit. Is
there a way to do so ?Never seen a use case for sysfs users. Can in theory control it for buffered data but I think the core support is missing. Sca3000 used to do it.
Ok