Messages in this thread | | | Date | Sat, 06 Feb 2010 13:59:33 +0000 | From | Jonathan Cameron <> | 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
| |