[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150717121454.90E9343115@saturn.retrosnub.co.uk>
Date: Fri, 17 Jul 2015 13:14:54 +0100
From: jic23@...23.retrosnub.co.uk
To: Daniel Baluta <daniel.baluta@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
Peter Meerwald <pmeerw@...erw.net>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] DocBook: Add initial documentation for IIO
Daniel Baluta writes:
> On Thu, Jul 16, 2015 at 10:31 PM, Jonathan Cameron <jic23@...nel.org> wrote:
>
> Thanks for your review Jonathan! I will try to address your
> comments in v2.
>
>
>>>+ The main purpose of the Industrial I/O subsystem (IIO) is to
>>>provide
>>>+ support for devices that in some sense are analog to digital
>>>converts
>>>+ (ADCs). As many actual devices combine some ADCs with digital to
>>>analog
>>>+ converters (DACs), that functionality is also supported.
>>
>> I wonder if we now want to treat DACs at the same level in the docs as ADCs. Right
>> now our support is simpler but there are patches adding full buffered support to output devices as well (Lars?)
>
> I have very few experience with DACs IIO drivers :) but I assume that
> the basic part
> is the same (e.g. set .output = 1) then triggers are independent of
> device type :).
>
> Anyhow, the above line only says that IIO also supports DACs and then
> all the examples
> are for ADCs :). Perhaps I can make the examples more clear.
>
> <snip>
>
>>
>>>+ Usually these sensors are connected via SPI or I2C.
>> Maybe add something about SOC integrated parts as well?
>
> Like sensors hubs? We can add this later.
Not so much sensor hubs (though could mention those as well).
A lot of our ADCs are integrated in various (typically arm) SOCs.
These then provide services to other users (battery etc) as needed.
>
>>>+ <para>
>>>+ The Industrial I/O core offers a way for continuous data capture
>>>+ based on a trigger source. Multiple data channels can be read at
>>>once
>>>+ from <filename>/dev/iio:deviceX</filename> character device node,
>>>+ thus reducing the CPU load.
>>>+ </para>
>> Why reduced load? Also perhaps mention pseudo scans? (Sort of all at the same time)
>
> Because, the alternative would be to use "polling" on sysfs data
> attributes. This means:
> * 3 userspace read()'s instead of 1.
> * 3 kernel separate register reads instead 1 bulk read.
>
> Perhaps I can make this clearer. :)
Also make the point that the interface is binary and scaling / offsets
left to userspace. Just wants some explanation I think!
>
> <snip>
>
>> Sorry for messy review. Ignoring my daughter down the park:)
>>
>> Anyhow, a great basis to build on. I like the example driven approach.
>> Might have missed it but perhaps cross refer to the dummy driver?
>
> Thanks again for your time Jonathan! We are really happy with your
> per weekend review sessions, so you would better stay away from
> your phone while in the park :D.
*laughs*. My daughter's 9. She doesn't really need pushing on the swings
any more. Just keeps coming over to see what I'm doing :)
Busy with Ballet shows this weekend and holiday next so got to fit
the odd bit in mid week at the moment :)
>
> thanks,
> Daniel.
--
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