Questions about IIO drivers

Questions about IIO drivers

[Maxime Ripard]

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,

-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: Questions about IIO drivers

[Jonathan Cameron]

Hi Maxime,

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

As an aside
IIO_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.
> 
>   - 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 ?
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

Re: Questions about IIO drivers

[Maxime Ripard]

Hi Jonathan,

On 27/09/2011 16:28, Jonathan Cameron wrote:
>> 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.

>>   - 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 ?
> 
> As an aside
> IIO_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)?

Yep, I've seen that, but I've branched from 3.1-rc6. I've rebased on top
of your github tree.

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

Ok, thanks, I'll check this out.

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

Ok, now I see the trigger_now file :)

But I guess that the driver still have to register this trigger, right ?

Thanks,

-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: Questions about IIO drivers

[Jonathan Cameron]

On 09/27/11 16:59, Maxime Ripard wrote:
> Hi Jonathan,
> 
> On 27/09/2011 16:28, Jonathan Cameron wrote:
>>> 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.
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!
> 
>>>   - 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 ?
>>
>> As an aside
>> IIO_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)?
> 
> Yep, I've seen that, but I've branched from 3.1-rc6. I've rebased on top
> of your github tree.
> 
>> 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.
> 
> Ok, thanks, I'll check this out.
> 
>>>   - 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 ?
>> 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).
> 
> Ok, now I see the trigger_now file :)
> 
> 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