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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
