Message-ID: <8bd0f97a1002151658l742444cg18b2a38846cbfe37@mail.gmail.com>
Date:	Mon, 15 Feb 2010 19:58:12 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>
Cc:	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dtor@...l.ru>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	Robin Getz <rgetz@...ckfin.uclinux.org>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	Ira Snyder <iws@...o.caltech.edu>,
	Jean Delvare <khali@...ux-fr.org>,
	Samu Onkalo <samu.p.onkalo@...ia.com>,
	Stefani Seibold <stefani@...bold.net>
Subject: Re: [RFC] Staging: IIO: New ABI V2

On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
>> Here is another iteration of the ABI spec for IIO with changes made
>> in response to http://lkml.org/lkml/2010/1/20/195 and
>> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
>> other general tidy ups.
>>
>> If there are no major issues raised, we may begin working on the move
>> to this ABI shortly on the basis any minor changes can always get
>> cleaned up before those patches merge.  I'll also be doing a formal
>> version of this file for in kernel documentation once things are
>> fairly stable with all of the information not relevant to this
>> discussion.
>>
>> Changes since v1:
>>
>> * iio is now a bus with directory changes resulting in this document.
>> * moved to in0_raw etc for voltage sensors to avoid confusion with
>>   a completely different ABI from hwmon.  Jean made the point that
>>   we shouldn't take this to far, but as things currently stand there
>>   is no disadvantage in this name change.
>> * dropped freefall event for now. More discussions need to be had on this
>>   and in a straight IIO world we normally won't care about this one anyway.
>> * 'device' naming changed for the various subsidiary devices so as make
>>   the interconnections more obvious.  I haven't tried implementing this
>>   yet, but I think the small amount of pain involved is worth it for
>>   increased clarity. The only exception is triggers where the connections
>>   are not specified as a given trigger may not have and IIO device
>>   associated with it.  Anyone suggest a scheme for this? (see about 10
>>   lines below to clarify what I mean here!)
>> * As conversion of the max1363 driver over to a consistent scan_element
>>   interface will mean that these will only apply to the ring buffer
>>   (rather than direct capture), scan_elements is moved into the ring
>>   buffer device directory.
>> * Switch ring for simply buffer as it might be a fifo or other buffer
>>   form instead.
>>
>> At times I may have suppressed links that would be created by the tree of
>> devices. In the flat base directory a given driver can now create the
>> following:
>>
>> device[n]
>> device[n]:ring
>> device[n]:ring:access
>> device[n]:ring:event
>> device[n]:event[m]
>> trigger[o]
>>
>
> What exists today still requires a copy_[to|from]_user when using the ring
> buffer (and then another cache_flush if you are dma'ing things). These seems
> pretty expensive and will consume extra cycles that will limit throughput.
>
> Any thoughts to a mmaped interface directly to the IIO ring buffer, so the
> system could avoid some of the above overhead? (This is what we had to do for
> some other drivers - which were able to handle a 40 MSample/second data
> processed by userspace for a soft radio).

does sysfs currently support mmap-ing of files in there ?
-mike
--
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