From: Jonathan Cameron <jic23@cam.ac.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Greg KH <greg@kroah.com>, Jean Delvare <khali@linux-fr.org>,
Guenter Roeck <guenter.roeck@ericsson.com>
Subject: Re: IIO comments
Date: Fri, 18 Mar 2011 16:29:16 +0000 [thread overview]
Message-ID: <4D83885C.3050402@cam.ac.uk> (raw)
In-Reply-To: <201103181718.08502.arnd@arndb.de>
On 03/18/11 16:18, Arnd Bergmann wrote:
> On Friday 18 March 2011, Jonathan Cameron wrote:
>> On 03/18/11 12:47, Arnd Bergmann wrote:
>>> On Thursday 17 March 2011, Jonathan Cameron wrote:
>>>> On 03/17/11 17:51, Arnd Bergmann wrote:
>>>>> I don't completely understand the notation. Regarding the various
>>>>> {in0, in1, in2, ...} inputs, is there a fundamental difference between
>>>>> them? In the code example I gave, a driver would simply list
>>>>> a set of inputs of the same type (IIO_CHAN_IN) and let the core
>>>>> enumerate them. What does "in0-in1" mean?
>>>>
>>>> in0-in1 is a differential adc channel. Literally outputs value on
>>>> physical pin 1 subtracted from physical pin 2.
>>>
>>> Ok, I see. So these would be fairly hard to enumerate, right?
>>> Would it be possible to have one attribute with named "diff%d"
>>> and another attribute associated with it that describes which
>>> channels are compared?
>>
>> Could do, but what would it gain us? If the information is available
>> to the core, then it can use it give us the explicit naming? As shown
>> below we have to handle holes in the enumeration anyway so this isn't
>> to much of a problem.
>
> Maybe I was seeing problems that don't exist here. Wouldn't
> you need to numeric identifiers to describe a differential
> channel?
Agreed, but from the point of view of what is exposed in naming it doesn't
matter. The core and the driver need that number. Userspace doesn't.
Also note that we'll need to pass over an explicit index for the buffering
order anyway so what is one more. The buffering one we can't avoid as
userspace has to know what it is and they are sometimes dependent on
really esoteric rules on the hardware. Right now we assume that
there aren't sets with different contents where the ordering
of any given pair changes. I think that is probably valid.
Hence what we have won't allow
a b c and b a d (in some sense they have to have a monotonic index).
> I guess if it's always in${i}-in${i+1}, it's still not too hard.
I think they have been so far, but doubt this is universal.
How about having a diff type and just having a pair of indices in the
channel structure? Actually may need a third for x^2+y^2+z^2 devices.
(iirc there are parts that do x^2+y^2 despite also having a z channel)
...
next prev parent reply other threads:[~2011-03-18 16:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 21:15 IIO comments Arnd Bergmann
2011-03-16 11:57 ` Jonathan Cameron
2011-03-16 13:33 ` Arnd Bergmann
2011-03-16 14:50 ` Jonathan Cameron
2011-03-16 15:09 ` Guenter Roeck
2011-03-16 15:15 ` Arnd Bergmann
2011-03-16 15:33 ` Jonathan Cameron
2011-03-17 13:24 ` Arnd Bergmann
2011-03-17 16:47 ` Jonathan Cameron
2011-03-17 17:51 ` Arnd Bergmann
2011-03-17 18:33 ` Jonathan Cameron
2011-03-18 12:47 ` Arnd Bergmann
2011-03-18 16:06 ` Jonathan Cameron
2011-03-18 16:18 ` Arnd Bergmann
2011-03-18 16:29 ` Jonathan Cameron [this message]
2011-03-18 16:57 ` Arnd Bergmann
2011-03-18 17:51 ` Jonathan Cameron
2011-03-17 13:47 ` Arnd Bergmann
2011-03-17 14:42 ` Jonathan Cameron
2011-03-17 15:03 ` Arnd Bergmann
2011-03-17 16:46 ` Jonathan Cameron
2011-03-17 16:47 ` Jonathan Cameron
2011-03-17 17:54 ` Arnd Bergmann
2011-03-16 16:54 ` Jonathan Cameron
2011-03-16 18:52 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D83885C.3050402@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=arnd@arndb.de \
--cc=greg@kroah.com \
--cc=guenter.roeck@ericsson.com \
--cc=kay.sievers@vrfy.org \
--cc=khali@linux-fr.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox