From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] IIO LRADC for mach-mxs
Date: Tue, 24 Jan 2012 14:14:27 +0100 [thread overview]
Message-ID: <20120124131427.GE2609@pengutronix.de> (raw)
In-Reply-To: <201201241408.08083.marek.vasut@gmail.com>
On Tue, Jan 24, 2012 at 02:08:07PM +0100, Marek Vasut wrote:
> Hi guys,
>
> I've been playing with a custom mxs board recently and I'd like to tinker with
> ADC. Well, apparently there was some effort but it died silently.
>
> Now, there are two approaches how to go about the MXS IIO LRADC. Firstly though,
> here are some hw details:
>
> 1) The ADC has 16 channels in total, some dedicated to particular function
> 2) The ADC can sample only up to 8 channels at the same time
> 3) The ADC delay triggers can trigger only up to 4 kinds of sampling for those
> up to 8 selected channel
>
> So how should we go about this:
>
> A) Implement functions, to configure and select a channel at probe-time and then
> never allow (at runtime) different channel to be selected.
>
> + Channel configuration is static, passed via plat_data
> + The channels don't need to be reconfigured => when data are demanded, the
> channel doesn't need to be reconfigured (if it's not configured in one of those
> 8 options) and the user doesn't need to wait for data.
> - Only 8 channels can be used
>
> B) Allow channel to be configured on-demand -- when it's value is requested, it
> is configured (if it's not already) for the particular function.
>
> + All 16 channels can be used
> - It's clunky and fragile to breakage
> - It's hard to implement good channel replacement algo (replacement as on the
> delay triggers and on those 8 slots)
>
> Which way do you consider better ?
CCing Jonathan and the iio-list (as found in MAINTAINERS). They probably
have more experience regardings those scenarios?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120124/ada27f02/attachment.sig>
next prev parent reply other threads:[~2012-01-24 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 13:08 [RFC] IIO LRADC for mach-mxs Marek Vasut
2012-01-24 13:14 ` Wolfram Sang [this message]
2012-01-24 14:20 ` J.I. Cameron
2012-01-24 14:39 ` J.I. Cameron
2012-01-26 0:49 ` Marek Vasut
2012-01-26 6:49 ` Jonathan Cameron
2012-01-26 10:30 ` Marek Vasut
2012-01-26 21:29 ` Jonathan Cameron
2012-01-27 21:44 ` Marek Vasut
2012-01-28 9:37 ` 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=20120124131427.GE2609@pengutronix.de \
--to=w.sang@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).