linux-kernel - Re: [PATCH] DocBook: Add initial documentation for IIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Jul 2015 12:18:51 +0300
From:	Daniel Baluta <daniel.baluta@...el.com>
To:	Jonathan Cameron <jic23@...nel.org>
Cc:	Daniel Baluta <daniel.baluta@...el.com>,
	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

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.

>>+    <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. :)

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

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/