From: Jonathan Cameron <jic23@cam.ac.uk>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: linux-iio@vger.kernel.org, "Hennerich,
Michael" <Michael.Hennerich@analog.com>
Subject: Re: Questions about IIO drivers
Date: Tue, 27 Sep 2011 15:28:36 +0100 [thread overview]
Message-ID: <4E81DD94.6020406@cam.ac.uk> (raw)
In-Reply-To: <4E81D71C.3050805@free-electrons.com>
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
next prev parent reply other threads:[~2011-09-27 14:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 14:01 Questions about IIO drivers Maxime Ripard
2011-09-27 14:28 ` Jonathan Cameron [this message]
2011-09-27 15:59 ` Maxime Ripard
2011-09-28 8:31 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E81DD94.6020406@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=Michael.Hennerich@analog.com \
--cc=linux-iio@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.