On Tue, Mar 17, 2015 at 5:47 PM, Michael Welling mwell...@ieee.org wrote:
On Tue, Mar 17, 2015 at 05:39:01PM +0100, Linus Walleij wrote:
I would more think about deprecating the sysfs in favor of the dev
node.
What happens to all of the users of the sysfs interface when this happens?
They
On Mon, Mar 9, 2015 at 9:22 PM, Michael Welling mwell...@ieee.org wrote:
On Mon, Mar 09, 2015 at 04:52:26PM +0100, Linus Walleij wrote:
Whoever comes up with a cleaner sysfs or a clean device interface
will win the argument and lock the path for the other approach.
It's like a forking path
On Tue, Mar 17, 2015 at 05:39:01PM +0100, Linus Walleij wrote:
On Mon, Mar 9, 2015 at 9:22 PM, Michael Welling mwell...@ieee.org wrote:
On Mon, Mar 09, 2015 at 04:52:26PM +0100, Linus Walleij wrote:
Whoever comes up with a cleaner sysfs or a clean device interface
will win the argument
On Wed, Mar 4, 2015 at 1:43 PM, Alexandre Courbot gnu...@gmail.com wrote:
On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot gnu...@gmail.com wrote:
It really comes down to how user-space wants to access GPIOs. I
Whoever comes up with a cleaner sysfs or a clean device interface
will win the argument and lock the path for the other approach.
It's like a forking path with no going back or something.
Can't we just do it a bit like v4l2 does it?
E.g. an open /dev/gpio and then an ioctl which queries all
On Mon, Mar 09, 2015 at 04:52:26PM +0100, Linus Walleij wrote:
On Wed, Mar 4, 2015 at 1:43 PM, Alexandre Courbot gnu...@gmail.com wrote:
On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Tue, Mar 3, 2015 at 7:31 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Tue, Mar 3, 2015 at 9:27 AM, Alexandre Courbot gnu...@gmail.com wrote:
It really comes down to how user-space wants to access GPIOs. I
suspect the majority of sysfs accesses is done by scripts and other
simple
On Mon, Mar 2, 2015 at 4:27 PM, Michael Welling mwell...@ieee.org wrote:
On Mon, Mar 02, 2015 at 03:16:06PM +0900, Alexandre Courbot wrote:
On Fri, Feb 27, 2015 at 10:15 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Feb 26, 2015 at 11:27 AM, Alexandre Courbot gnu...@gmail.com
On Fri, Feb 27, 2015 at 10:15 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Feb 26, 2015 at 11:27 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:52 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Thu, Feb 19, 2015 at 9:53 AM, folkert
On Fri, Feb 27, 2015 at 10:19 PM, folkert folk...@vanheusden.com wrote:
Mmm, I was thinking it would be nice to have a (new, redesigned) sysfs
interface for this. :P
Aren't we going to make things less accessible if we use a char device?
Since sysfs has a one value per file paradigm, it
On Mon, Mar 02, 2015 at 03:16:06PM +0900, Alexandre Courbot wrote:
On Fri, Feb 27, 2015 at 10:15 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Thu, Feb 26, 2015 at 11:27 AM, Alexandre Courbot gnu...@gmail.com
wrote:
On Fri, Feb 20, 2015 at 1:52 AM, Linus Walleij
On Thu, Feb 26, 2015 at 11:27 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:52 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Thu, Feb 19, 2015 at 9:53 AM, folkert folk...@vanheusden.com wrote:
I also think that this interface is cumbersome. I did not measure
On Thu, Feb 19, 2015 at 5:53 PM, folkert folk...@vanheusden.com wrote:
Try using lseek before reading the data after the poll.
EX.
if (fdset[0].revents POLLPRI) {
lseek(fdset[0].fd, 0, SEEK_SET);
len = read(fdset[0].fd, buf, MAX_BUF);
On Fri, Feb 20, 2015 at 1:52 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Feb 19, 2015 at 9:53 AM, folkert folk...@vanheusden.com wrote:
I also think that this interface is cumbersome. I did not measure it(!)
but I think adding this open/seek + read construction may add all kinds
Try using lseek before reading the data after the poll.
EX.
if (fdset[0].revents POLLPRI) {
lseek(fdset[0].fd, 0, SEEK_SET);
len = read(fdset[0].fd, buf, MAX_BUF);
.
.
}
See if this helps.
On Thu, Feb 19, 2015 at 9:53 AM, folkert folk...@vanheusden.com wrote:
I also think that this interface is cumbersome. I did not measure it(!)
but I think adding this open/seek + read construction may add all kinds
of overhead. Especially since my use-case requires the lowest latency
On Tue, Feb 3, 2015 at 5:03 PM, Michael Welling mwell...@ieee.org wrote:
On Sat, Jan 31, 2015 at 02:39:03PM +0100, Alexandre Courbot wrote:
On Sat, Jan 31, 2015 at 9:33 AM, folkert folk...@vanheusden.com wrote:
Michael,
For timekeeping I wrote a program which waits for interrupts on
On Sat, Jan 31, 2015 at 02:39:03PM +0100, Alexandre Courbot wrote:
On Sat, Jan 31, 2015 at 9:33 AM, folkert folk...@vanheusden.com wrote:
Michael,
For timekeeping I wrote a program which waits for interrupts on
gpio-pins and then tells the local ntp daemon the clock offset.
I'm aware
On Sat, Jan 31, 2015 at 9:33 AM, folkert folk...@vanheusden.com wrote:
Michael,
For timekeeping I wrote a program which waits for interrupts on
gpio-pins and then tells the local ntp daemon the clock offset.
I'm aware of the pps support in recent kernel but that does not work
(yet) on
For timekeeping I wrote a program which waits for interrupts on
gpio-pins and then tells the local ntp daemon the clock offset.
I'm aware of the pps support in recent kernel but that does not work
(yet) on all platforms (eg cubieboard 1).
This has worked for quite some time but
Michael,
For timekeeping I wrote a program which waits for interrupts on
gpio-pins and then tells the local ntp daemon the clock offset.
I'm aware of the pps support in recent kernel but that does not work
(yet) on all platforms (eg cubieboard 1).
This has worked for quite some time
On Thu, Jan 29, 2015 at 04:29:02PM +0100, folkert wrote:
Hi,
For timekeeping I wrote a program which waits for interrupts on
gpio-pins and then tells the local ntp daemon the clock offset.
I'm aware of the pps support in recent kernel but that does not work
(yet) on all platforms (eg
22 matches
Mail list logo
