[RFC] IIO LRADC for mach-mxs

Wolfram Sang w.sang at pengutronix.de
Tue Jan 24 08:14:27 EST 2012


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>


More information about the linux-arm-kernel mailing list