[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120410140749.GL7499@opensource.wolfsonmicro.com>
Date: Tue, 10 Apr 2012 15:07:50 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: mingo@...e.hu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] x86, intel_mid: ADC management
On Tue, Apr 10, 2012 at 02:42:35PM +0100, Alan Cox wrote:
> > Right, but fundamentally it's just a general purpose ADC which looks
> > just the same as all the other SoC/PMIC ADCs. Like I say the decision
> > for that hardware was to push it in via IIO.
> Your decision maybe. And it's one that makes no sense.
> As I said this is a low level interface for driver enabling including
It's not just me, it's where all the ARM SoCs and their PMICs are going.
If you look on the IIO list you'll see patches for at least the AT91
> early boot time stuff, and its on a platform that's unlikely to want or
> ever use and suck in the big blob of IIO code.
Could you be more specific about what this early boot time stuff is?
Looking at the changelogs in there it all looks like the standard
battery monitoring and power supply stuff that these ADCs get used for -
just based on the changelogs there doesn't appear to be anything
remarkable here.
There's already a standard adaptor to map IIO into at least hwmon, not
sure about the power supply subsystem. There were also some other
things people were doing in areas like thermal management that were
using this sort of hardware in generic ways.
> If you want an IIO interface to it you can write one, it's just a low
> level resource manager.
We can't just keep on going round adding new custom interfaces every
time someone supports a new SoC - it means we end up having to sit and
write lots of per-device adaptor code to integrate things and it's
hard for us to factor common code out of drivers when we've not got any
kind of framework for them.
If IIO is totally unsuitable then someone needs to make the case for a
new subsystem for this class of hardware and provide that subsystem but
it seems entirely obvious that there is a general class of hardware here
which is widely implemented.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists