Questions about IIO drivers
Hi all,
I'm currently writing a driver for the ADCs present in Atmel AT91 SoC using iio. I will of course submit it once it is ready.
For now, I have the basic integration into iio, and I am beginning to integrate the hardware logic in it. However, this integration raises few questions, and I didn't found any answers to it. (The dummy driver is of great help btw)
- While the registers are all the same on the AT91 platform for the
ADCs, the number of channels available is not the same from one board to another. For now, I'm declaring the number of channels available through the board definition and platform_data, and I'm declaring the channels to iio using :
idev->channels = kzalloc(sizeof(struct iio_chan_spec) * nb_chan,
GFP_KERNEL);
for(i = 0; i < nb_chan; i++) {
struct iio_chan_spec *chan = idev->channels + i;
chan->type = IIO_IN;
chan->indexed = 1;
chan->channel = i;
}While it seems to work nicely, it generates a warning, as iio_dev's channels field is declared const. Is there a better solution ?
- For now, I don't really want to rely on hardware triggers, but
instead use only software triggers. I've taken a look to sysfs triggers, and while the module for sysfs trigger is compiled and loaded, and added to the platform_devices of the board, the file trigger_now is nowhere to be found. I guess that I need to declare triggers in my driver, but I have found no clue on how to do that. How can we achieve it ?
Thanks,
Signature · 4 lines
Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Hi Maxime,
Quoted 7 lines
I'm currently writing a driver for the ADCs present in Atmel AT91 SoC using iio. I will of course submit it once it is ready.
For now, I have the basic integration into iio, and I am beginning to integrate the hardware logic in it. However, this integration raises few questions, and I didn't found any answers to it. (The dummy driver is of great help btw)
cool. Any feedback on that particularly welcome given we haven't merged it yet.
Quoted 16 lines
- While the registers are all the same on the AT91 platform for the
ADCs, the number of channels available is not the same from one board to another. For now, I'm declaring the number of channels available through the board definition andplatform_data, and I'm declaring the channels to iio using :idev->channels = kzalloc(sizeof(struct iio_chan_spec) * nb_chan, GFP_KERNEL); for(i = 0; i < nb_chan; i++) { struct iio_chan_spec *chan = idev->channels + i; chan->type = IIO_IN; chan->indexed = 1; chan->channel = i; }
Quoted 2 lines
While it seems to work nicely, it generates a warning, as iio_dev's channels field is declared const. Is there a better solution ?
As an asideIIO_IN -> IIO_VOLTAGE. I've push a patch to GregKH today that scraps IIO_IN once and for all.
Are you using the latest published tree (currently on github)? There's at least one driver that does the same in tree and it doesn't give a warning (there were some core changes to avoid it). ad7280a.
The other option is to have a single array of all channels and set num_channels lower than the size of the array. Couple of drivers do that for some of the parts they support.
Quoted 7 lines
- For now, I don't really want to rely on hardware triggers, but
instead use only software triggers. I've taken a look to sysfs triggers, and while the module for sysfs trigger is compiled and loaded, and added to theplatform_devicesof the board, the filetrigger_nowis nowhere to be found. I guess that I need to declare triggers in my driver, but I have found no clue on how to do that. How can we achieve it ?
Hmm.. clearly need some documentation for that driver.
What you should have is a directory called:/sys/bus/iio/devices/iio_sysfs_trigger (it's a rather 'unusual device').
In there are the userspace controls for creating and destroying sysfs triggers.
echo N to > add_trigger and you should find it has created a trigger called sysfstrigN the controls for which (including the trigger_now) file can be found in /sys/bus/iio/devices/triggerY (where Y is id of the trigger - counting from 0).
Hope that helps,
Jonathan
Hi Jonathan,
Quoted 9 lines · Jonathan Cameron
Quoted 7 lines
I'm currently writing a driver for the ADCs present in Atmel AT91 SoC using iio. I will of course submit it once it is ready.
For now, I have the basic integration into iio, and I am beginning to integrate the hardware logic in it. However, this integration raises few questions, and I didn't found any answers to it. (The dummy driver is of great help btw)
cool. Any feedback on that particularly welcome given we haven't merged it yet.
Well, it addresses the beginner questions quite well in my opinion, apart from triggers maybe. Adding triggers could maybe be a good idea.
Quoted 15 lines
Quoted 15 lines
- While the registers are all the same on the AT91 platform for the
ADCs, the number of channels available is not the same from one board to another. For now, I'm declaring the number of channels available through the board definition andplatform_data, and I'm declaring the channels to iio using :idev->channels = kzalloc(sizeof(struct iio_chan_spec) * nb_chan, GFP_KERNEL); for(i = 0; i < nb_chan; i++) { struct iio_chan_spec *chan = idev->channels + i; chan->type = IIO_IN; chan->indexed = 1; chan->channel = i; }
Quoted 8 lines
Quoted 2 lines
While it seems to work nicely, it generates a warning, as iio_dev's channels field is declared const. Is there a better solution ?
As an aside
IIO_IN->IIO_VOLTAGE. I've push a patch to GregKH today that scrapsIIO_INonce and for all.Are you using the latest published tree (currently on github)?
Yep, I've seen that, but I've branched from 3.1-rc6. I've rebased on top of your github tree.
Quoted 6 lines
There's at least one driver that does the same in tree and it doesn't give a warning (there were some core changes to avoid it). ad7280a.
The other option is to have a single array of all channels and set
num_channelslower than the size of the array. Couple of drivers do that for some of the parts they support.
Ok, thanks, I'll check this out.
Quoted 11 lines
Quoted 6 lines
- For now, I don't really want to rely on hardware triggers, but
instead use only software triggers. I've taken a look to sysfs triggers, and while the module for sysfs trigger is compiled and loaded, and added to theplatform_devicesof the board, the filetrigger_nowis nowhere to be found. I guess that I need to declare triggers in my driver, but I have found no clue on how to do that. How can we achieve it ?Hmm.. clearly need some documentation for that driver.
What you should have is a directory called:
/sys/bus/iio/devices/iio_sysfs_trigger(it's a rather 'unusual device').
Quoted 7 lines
In there are the userspace controls for creating and destroying sysfs triggers.
echo N to >
add_triggerand you should find it has created a trigger called sysfstrigN the controls for which (including thetrigger_now) file can be found in/sys/bus/iio/devices/triggerY(where Y is id of the trigger - counting from 0).
Ok, now I see the trigger_now file :)
But I guess that the driver still have to register this trigger, right ?
Thanks,
Signature · 4 lines
Maxime Ripard, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 10 lines · Maxime Ripard
Hi Jonathan,
Quoted 7 lines · Jonathan Cameron
Quoted 7 lines
I'm currently writing a driver for the ADCs present in Atmel AT91 SoC using iio. I will of course submit it once it is ready.
For now, I have the basic integration into iio, and I am beginning to integrate the hardware logic in it. However, this integration raises few questions, and I didn't found any answers to it. (The dummy driver is of great help btw)
Quoted 5 lines
Quoted 2 lines
cool. Any feedback on that particularly welcome given we haven't merged it yet.
Well, it addresses the beginner questions quite well in my opinion, apart from triggers maybe. Adding triggers could maybe be a good idea.
I thought about it, but the issue is that we'll end up replicating the functionality of the sysfs trigger in a more clunky inelegant fashion. If people are messing with triggers then we want them to look at a real hardware driver. Still I'm open to patches adding that if anyone else wants to have a go!
Quoted 51 lines
Quoted 16 lines
Quoted 16 lines
- While the registers are all the same on the AT91 platform for the
ADCs, the number of channels available is not the same from one board to another. For now, I'm declaring the number of channels available through the board definition andplatform_data, and I'm declaring the channels to iio using :idev->channels = kzalloc(sizeof(struct iio_chan_spec) * nb_chan, GFP_KERNEL); for(i = 0; i < nb_chan; i++) { struct iio_chan_spec *chan = idev->channels + i; chan->type = IIO_IN; chan->indexed = 1; chan->channel = i; }Quoted 8 lines
Quoted 2 lines
While it seems to work nicely, it generates a warning, as iio_dev's channels field is declared const. Is there a better solution ?
As an aside
IIO_IN->IIO_VOLTAGE. I've push a patch to GregKH today that scrapsIIO_INonce and for all.Are you using the latest published tree (currently on github)?
Yep, I've seen that, but I've branched from 3.1-rc6. I've rebased on top of your github tree.
Quoted 6 lines
There's at least one driver that does the same in tree and it doesn't give a warning (there were some core changes to avoid it). ad7280a.
The other option is to have a single array of all channels and set
num_channelslower than the size of the array. Couple of drivers do that for some of the parts they support.Ok, thanks, I'll check this out.
Quoted 14 lines
Quoted 6 lines
- For now, I don't really want to rely on hardware triggers, but
instead use only software triggers. I've taken a look to sysfs triggers, and while the module for sysfs trigger is compiled and loaded, and added to theplatform_devicesof the board, the filetrigger_nowis nowhere to be found. I guess that I need to declare triggers in my driver, but I have found no clue on how to do that. How can we achieve it ?Hmm.. clearly need some documentation for that driver.
What you should have is a directory called:
/sys/bus/iio/devices/iio_sysfs_trigger(it's a rather 'unusual device').In there are the userspace controls for creating and destroying sysfs triggers.
Quoted 8 lines
Quoted 4 lines
echo N to >
add_triggerand you should find it has created a trigger called sysfstrigN the controls for which (including thetrigger_now) file can be found in/sys/bus/iio/devices/triggerY(where Y is id of the trigger - counting from 0).Ok, now I see the
trigger_nowfile :)But I guess that the driver still have to register this trigger, right ?
Yes but only in userspace, not at compile time.
Take a look at what the example app does staging/iio/Documentation/generic_buffer.c. To summarize doing equivalent from console
1) Select the trigger you have created:
echo "sysfstrigN" > /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
2) make sure you've enabled the channels you want to capture.
3) set the ring length by
echo 100 > /sys/bus/iio/devices/iio:deviceX/buffer/length
4) enable buffered capture
echo 1 > /sys/bus/iio/devices/iio:deviceX/buffer/enable
5) read from the chrdev /dev/iio:deviceX