linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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>

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