Message-ID: <4E9C354A.2010709@cam.ac.uk>
Date:	Mon, 17 Oct 2011 15:01:46 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Linus Walleij <linus.ml.walleij@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	zdevai@...il.com
Subject: Re: [PATCH] staging:iio:proof of concept in kernel interface.

On 10/17/11 14:55, Linus Walleij wrote:
> On Mon, Oct 17, 2011 at 11:43 AM, Jonathan Cameron <jic23@....ac.uk> wrote:
> 
>> Thanks for this Linus. It is more or less where I was heading with one
>> exception.  I was going to link whole physical devices whereas I think
>> you are proposing linking individual channels.
> 
> That's for the usecases I have at hand, I don't know which is more
> common: grab the entire device and pick a few channels or grab
> a single channel. I was thinking the latter would be most common
> for in-kernel use.
Guess most common for a pull type situation, less so for messing
with input devices (accelerometers etc - where they need a push
interface from the adc to the next layer up).
> 
> If you need some inspiring code for how to handle registration of
> mapping tables etc you can look at the API I'm pushing for the
> pin control subsystem:
> http://marc.info/?l=linux-kernel&m=131850357826490&w=2
Thanks, I admit I lost touch with this a while back :(
> 
>> For the adc channel I'm not particularly keen on insisting every device
>> have a unique name for every channel.  That breaks the effort we went to
>> in IIO to enforce consistent naming (for userspace interfaces) in the first
>> place.  To my mind it should never be anything other than a number.
> 
> Doesn't feel like a big issue, plain numbers are fine for me.
> 
> I was more thinking along the line that in an embedded system an
> on-system-in-chip GPADC sure has specific set-in-stone uses for
> each channel, i.e. the pin it connects to is hardwired somewhere,
> like channel 0 is "battery-voltage", pin 1 is "battery-temperature"
> etc, which makes string descriptions make sense.
Yup. Those I'm fine with. Mark is talking me into providing string
mappings for everything. We'll see how it works in practice.
Perhaps there is a happy middle ground.

> 
> It doesn't make sense for an ADC card with 100 ADC:s for random
> measurements, of course.
> 
>> struct adc_map {
>> /* Input / output side */
>>        struct device *adc_dev;
>>        const char *adc_dev_name;
>>        int channel_number;
>> /* User side */
>>        const char *channel;
>>        struct device *dev;
>>        const char *dev_name;
>> };
> 
> OK that makes sense.
> 
>> Anyhow, I'll have a go at implementing this over the next few days.  Before I
>> do that I am going to push out the proposal to move the core IIO infrastructure
>> out of staging.
> 
> Good, my gut feeling is that right now it hurts the kernel more to
> have IIO in staging than it could ever hurt it to have it in drivers/,
> it is getting badly needed.
We're working on it ;)  All reviews welcome.  We only need the first core
bit to build this pull type in kernel interfaces on top. 
(sorry, didn't cc you on the posting a few minutes ago) 
https://lkml.org/lkml/2011/10/17/157
> 
> Yours,
> Linus Walleij
> 

--
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