Re: [PATCH] staging:iio:proof of concept in kernel interface.

[Jonathan Cameron]

On 10/17/11 12:18, Mark Brown wrote:
> On Mon, Oct 17, 2011 at 12:13:27PM +0100, Jonathan Cameron wrote:
>> On 10/17/11 11:46, Mark Brown wrote:
> 
>>> I think the PMIC case is a real one, assigning numbers people need to
>>> use to find things is doesn't really reflect actual usage.
> 
>> Just to make sure I'm understanding you correctly could you give an example
>> part.  The supplies one we explicitly handle anyway so I'm happy with that
>> one, I just want to confirm that this is what you are talking about.
> 
> The wm831x PMICs have an AUXADC with (actual wirings vary depending on
> the particular device):
Just to pin this down completely...
> 
>  - Some voltage inputs hard wired to particular system supplies.
Hard wired in the pmic?  (e.g. do not vary from device to device).
These I'm happy to see have names.  If it were a normal IIO device their
access attributes would be something like:

in_voltage0_supply3V_raw
in_voltage1_supply2.8V_raw

(have insist on indexing even with named channels because it is needed as
events codes don't want to carry a string.).

>  - One or more temperature inputs wired to particular place (eg, chip
>    and battery).
Not hard wired so to my mind these are just general purpose temperature inputs.
Hence naming doesn't make sense (at least not outside of board file or DT).
If there really is something that stops these being switched round then they can
be named (e.g. if one is actually in the pmic package!). IIO raw attribute would be: 

in_temp0_raw
in_temp1_raw etc

>  - Some channels that measure voltages on some of the pins with no
>    particular function allocated to them.
So these are nameless numbered channels.

in_voltage13_raw onwards.

There are some complexities to deal with that make me wonder if direct indexing
into a driver provided table isn't easier.  The other is channel types.

Perhaps something as involved as the following works - we are basically lifting about
half of struct iio_chan_spec into here:

struct adc_map {
/* Input / output side */
        struct device *adc_dev;
        const char *adc_dev_name;
	int channel_num1;
	int channel_num2;
	enum IIO_TYPE type /*adc etc*/
	bool differential.
/* User side */
        const char *channel;
        struct device *dev;
        const char *dev_name;
};

Is it so bad to insist that the dt writer or equivalent actually looks at the
driver in question and picks the underlying channel index directly?

I'm certainly going to implement that first then add the matching logic
afterwards anyway as it will make it easier to review / test.



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