[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201103171447.17960.arnd@arndb.de>
Date: Thu, 17 Mar 2011 14:47:17 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Jonathan Cameron <jic23@....ac.uk>
Cc: Kay Sievers <kay.sievers@...y.org>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>,
Jean Delvare <khali@...ux-fr.org>,
Guenter Roeck <guenter.roeck@...csson.com>
Subject: Re: IIO comments
I just went back to the older email and noticed that I missed some of your
important replies.
On Wednesday 16 March 2011, Jonathan Cameron wrote:
> > I'm slightly confused, mainly because I have no idea how the
> > buffer and event interfaces are actually being used. I would
> > have expected an interface as simple as:
> >
> > * One iio device per sensor that can provide data, possibly
> > many per hardware device
>
> One per device.
I'm not sure what that means. One iio device per hardware device?
What about hardware devices that have multiple unrelated streams
of buffered input data?
> > * One chardev for each iio device
>
> currently 1-3. (event line, buffer access, buffer event)
It would be really nice to unify this, as I said. What
are the reasons why you think it cannot or should not be
done?
> > * Use epoll to wait for data and/or out-of-band messages
> > * Use chrdev read to get events from the buffer
>
> and data?
I mean get the data associated with the event. The event
itself as you said does not have any data, so we would not
need to read it, just to use poll()/epoll() in order to
wait for it.
> > * Use sysfs to read from sensors that are not event based
> >
> > What you have is obviously more complex than this, and you
> > probably have good reasons that I still need to understand.
Arnd
--
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