From: Arnd Bergmann <arnd@arndb.de>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH 2/3] staging:iio:lis3l02dq - experimental move to new channel_spec approach.
Date: Fri, 25 Mar 2011 17:02:01 +0100 [thread overview]
Message-ID: <201103251702.02292.arnd@arndb.de> (raw)
In-Reply-To: <4D8CB6EF.2000808@cam.ac.uk>
On Friday 25 March 2011, Jonathan Cameron wrote:
> > I need some background information here. Why do you expose the configuration
> > register directly? Is this something that users normally access?
> >
> > I would assume that it's highly device specific and would need to be
> > abstracted by the kernel.
> We could cache what events are enabled, and in some drivers we do. Here it is
> just simpler to ask the device as it has a convenient bitmap of what is enabled.
>
> It's actually a real pain to completely abstract this away because some
> devices only support sets of events at a time and exactly which are
> supported can be extremely complex. The common cases are:
>
> 1) Separate comparators for each event. (simple as we have here!)
> 2) n comparators which can be configured to any n events from a large list (adis16350
> is a classic example though we haven't finally merged event support for that
> part yet).
> 3) n comparators each of which can be configured to a subset of thresholds. e.g. one
> comparator per channel, lots of different things it can compare about the channel.
>
> It is possible that we can abstract these at some point, but right now I'm not even
> tempted to try! We are mostly avoiding the nastiest case at the moment which is
> where you have controllable compound events. In this particular device you can
> either have the events as 'or' as we do or 'and' for any set of them. Right now
> we simply don't implement the 'and' case.
Ok, thanks for the explanation.
Arnd
next prev parent reply other threads:[~2011-03-25 16:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 20:05 [RFC PATCH 0/3] Experimenting with channel specification structures Jonathan Cameron
2011-03-24 20:05 ` [PATCH 1/3] staging:iio: allow channels to be set up using a table of iio_channel_spec structures Jonathan Cameron
2011-03-25 14:37 ` Arnd Bergmann
2011-03-25 15:15 ` Jonathan Cameron
2011-03-25 15:26 ` Arnd Bergmann
2011-03-24 20:05 ` [PATCH 2/3] staging:iio:lis3l02dq - experimental move to new channel_spec approach Jonathan Cameron
2011-03-25 14:26 ` Arnd Bergmann
2011-03-25 15:38 ` Jonathan Cameron
2011-03-25 16:02 ` Arnd Bergmann [this message]
2011-03-24 20:05 ` [PATCH 3/3] staging:iio:max1363 - experimental move to channel_spec registration Jonathan Cameron
2011-03-25 15:03 ` [RFC PATCH 0/3] Experimenting with channel specification structures Arnd Bergmann
2011-03-25 15:19 ` 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=201103251702.02292.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
/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.