Message-ID: <4B6D75C5.70404@cam.ac.uk>
Date:	Sat, 06 Feb 2010 13:59:33 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	"Ira W. Snyder" <iws@...o.caltech.edu>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>,
	Dmitry Torokhov <dtor@...l.ru>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	"Frysinger, Michael" <Michael.Frysinger@...log.com>,
	"Getz, Robin" <Robin.Getz@...log.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Samu Onkalo <samu.p.onkalo@...ia.com>
Subject: Re: [RFC] Staging: IIO: New ABI V2

Hi Ira,

>> There are probably countless error in here. Please point any out you come
>> across.  This file may well need breaking up into sysfs-class-iio-in, accel
>> etc so as to keep it manageable.  Note this is not intended to obey the ABI
>> spec well.  It will be cleaned up before submission and all the other
>> required information added.
>>
> 
> How about current and power measurement devices?
We aren't applying any hard limits to what we will cover by IIO.  At the moment
the limits tend to be more precisely set by what is not adequately covered else
where than the other way around.  The other category of things we are including
tend to require facilities that IIO provides (buffering / event infrastructure)
that are not provided as is by an apparently more appropriate subsystem and
where the alternate subsystems.

For reference, Analog Devices have already suggested they will be using IIO
for a couple of energy meeting ICs which will have some similarities. 

https://docs.blackfin.uclinux.org/doku.php?id=adi_peripheral_drivers

For reference, we have a fairly dirty wiki page for IIO keeping track of devices
people are working on (or at least have and plan to work on for some of the ones
I'm listing!)

http://sourceforge.net/apps/mediawiki/iioutils/index.php?title=Device_List

As I don't have any equivalent devices in my development set, I'm happy to leave
those who do to hammer out any relevant details of naming etc as long as the
result fits nicely with the bits that are already being defined.
> I have an TI INA209
Interesting bit of kit.  The rest of my comments are based on a quick data sheet
browse, so please point out anything I have misunderstood or simply missed!
> chip which I've written a hwmon driver for, but the hwmon guys don't
> want to accept the driver upstream for the following reasons, and
> suggest IIO instead.
> 
> 1) it is sensitive enough to measure voltage in uV. This makes a huge
> difference when calculating current measurements, which I currently do
> in userspace with lm-sensors. The sense resistor is very likely to have
> a different value depending on the application the chip is used in. On
> my board, we have 5 of these chip, with 3 different resistor values.
To clarify things, do these resistors tend to specified accurately enough
on a per design basis, or are we at the level where we want to individually
calibrate individual devices?  The question is relevant to whether it makes
sense to specify these resistors as platform data or where else these values
need to be.
> 
> 2) it has "output pin enables". You can program an overcurrent limit
> into the device. When the current being drawn exceeds this limit, it
> drives an output pin so the power supply can be shut off quickly. In my
> case, it is wired to an LTC4215 hot swap controller.

Interesting setup..  If those output pin enables were routed to standard
interrupts (which clearly defeats the point!) then we could simply handle
them as event lines in IIO.  Here we have a rather convoluted situation
where  they act as hardware triggers of another device.   The first question
is whether it makes sense to make this know to the operating system, or whether
we effectively just ignore the physical link and configure the two interactive
devices appropriately (obviously we need to provide the means to do this!).

For the rest of this discussion, let us ignore the exact case you have here
and consider it as a more generic interrupt.  Obviously your current driver
has support for much if not all of what follows!

So things this device has:

* Current measurement.  For this we probably want to match naming with hwmon (no
  reason not to) with raw and conversion info as per in0_raw etc below.  I note
  we also have a controllable PGA so some of the conversion factors will be rw.
* trigger option for conversion. (IIO handles this fine)
* Peak-hold registers.  This one is new to us, so we will need to think of a suitable
  naming convention, but I'd guess reading these via sysfs will be adequate?
* Critical comparitor control.  Although much faster, these are basically threshold
  event detectors so we can use equivalents of the events described below.
* Lots of filtering controls.  Until we get a feel for how generalizable things like
  this are, we will keep them driver specific and out of the ABI spec.
* The smbus alert stuff should work fine as an event source.  I remember seeing
  some patches for support in i2c from David Brownell. We probably want to chase
  these up for this device driver.
* The single control handling data accuracy 8/10/12bit then averaging may take some thought!

So in conclusion, yes, this device falls within the scope of IIO but there are a number
of ABI elements that will need discussion.  Feel free to get that discussion going
here, by proposing the ABI you want!

Jonathan




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists