CODEWITHSUNDEEP
linuxinterruptgpiosysfs
Paul DeRocco
Paul DeRocco

Reputation: 413

Linux sysfs gpio: what re-arms interrupt?

The usual way to respond to an edge-triggered GPIO interrupt, using the old sysfs GPIO interface, is like this:

repeat forever
    poll() on POLLPRI event on GPIO fd
    lseek() back to 0 on GPIO fd
    read() current state from GPIO fd

If I put the code that actually handles the interrupt after the read(), is it guaranteed that any new interrupt that happens before poll() is called again will cause that next poll() to return immediately? In other words, what step re-arms the interrupt? The return from poll(), the call to lseek(), the call to read(), or the next call to poll()? If it's the last of these, I don't see any way to guarantee that an interrupt can't get lost.

Also, is it necessary to do the read()? I don't care about the state, just the edge event. And if I don't need read(), does lseek() do anything useful? This is hard to test in real life, because it would require generating interrupts in rapid succession on the existing hardware. None of the docs seem to explain this.

Upvotes: 0

Views: 967

Answers (1)

Jack
Jack

Reputation: 121

I've been using sysfs recently, and this snippet helped me:

int main() {
    struct pollfd myPollfd;
    myPollfd.fd = open("/sys/class/gpio/GPIO_IN_WHEEL1/value", O_RDONLY); //store filedescriptor in struct, open(path, read-write-permission)
    myPollfd.events = POLLPRI;
    while (1) {
        poll(&myPollfd, 1, -1); //poll(struct pollfd, max fd, timeout), timeout=-1 --> never
        if(myPollfd.revents & POLLPRI) {
            len = read(myPollfd.fd, buf, BUF_SIZE);  //mandatory to make system register interrupt as served
            printf("interrupt!\n",);
        }
        lseek(myPollfd.fd, 0, 0); //return cursor to beginning of file or next read() will return EOF
    }
    close(myPollfd.fd);
    return 0;
}

According to the sysfs manual, it's the read operation that makrs the interrupt to register as served, so in order to react to the next interrupt one must call read() on the endpoint, even if the content of the endpoint itself is meaningless.
Unfortunately i can't find the said documentation at the moment, but if i understood your question correctly, what you need to know is that all interrupts that happen between the first and the first call to read() are going to be lost.

Upvotes: 1

Related Questions