Re: Implementing a driver that listen to a GPIO
Hi, I am just trying to solve a similar problem as Luca described. I have a TQMa28 board running Linux 3.17-rc7 though. The capacitors keep the system up for about 1500 more milliseconds after the power fails. A GPIO line is set to high as soon as the main power is lost. So I have not much time to quit an important user space process and to clean up the ext4 root filesystem before the power fails. At the moment I pass rootflags=data=journal,commit=1 in the kernel commandline to lower the risk of data loss. In the user space application I open important files using the O_SYNC flag. Is there something else I should do to avoid data loss? How would you implement the "emergency cleanup on power-failure" logic? Dedicated driver (similar to the mentioned gpio-event driver?), implement it with UIO, let a userspace application running as root select /dev/uioX and cleaning up? Or should I create a separate partition on my eMMC just for this user space application data and use a readonly rootfs for the rest? Thanks for your help! Best regards, Clemens
2014-10-02 10:01 GMT-07:00 Clemens Gruber <clemens.gruber@pqgruber.com>:
Hi,
I am just trying to solve a similar problem as Luca described. I have a TQMa28 board running Linux 3.17-rc7 though. The capacitors keep the system up for about 1500 more milliseconds after the power fails. A GPIO line is set to high as soon as the main power is lost.
So I have not much time to quit an important user space process and to clean up the ext4 root filesystem before the power fails.
At the moment I pass rootflags=data=journal,commit=1 in the kernel commandline to lower the risk of data loss. In the user space application I open important files using the O_SYNC flag.
Is there something else I should do to avoid data loss?
How would you implement the "emergency cleanup on power-failure" logic? Dedicated driver (similar to the mentioned gpio-event driver?), implement it with UIO, let a userspace application running as root select /dev/uioX and cleaning up?
how about using netlink to notify the usersapce app on gpio interrupt .
Or should I create a separate partition on my eMMC just for this user space application data and use a readonly rootfs for the rest?
Thanks for your help!
Best regards, Clemens
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi, On 03/10/2014 02:33, Jinqiang Zeng wrote:
2014-10-02 10:01 GMT-07:00 Clemens Gruber <clemens.gruber@pqgruber.com>:
Hi,
I am just trying to solve a similar problem as Luca described. I have a TQMa28 board running Linux 3.17-rc7 though. The capacitors keep the system up for about 1500 more milliseconds after the power fails. A GPIO line is set to high as soon as the main power is lost.
So I have not much time to quit an important user space process and to clean up the ext4 root filesystem before the power fails.
At the moment I pass rootflags=data=journal,commit=1 in the kernel commandline to lower the risk of data loss. In the user space application I open important files using the O_SYNC flag.
Is there something else I should do to avoid data loss?
How would you implement the "emergency cleanup on power-failure" logic? Dedicated driver (similar to the mentioned gpio-event driver?), implement it with UIO, let a userspace application running as root select /dev/uioX and cleaning up? how about using netlink to notify the usersapce app on gpio interrupt .
thanks to all for your replies. Anyway, I solved the issue simply using the GPIO driver (no kernel modifications needed): - export GPIO number (es 7): $ echo 7 > /sys/class/gpio/export - set direction: $ echo "in" > /sys/class/gpio/gpio7/direction - set event that triggers interrupt: $ echo "falling" > /sys/class/gpio/gpio7/edge Then I create a user space application that executes a poll system call on "/sys/class/gpio/gpio7/value". Regards --- Luca Ellero http://http://www.brickedbrain.com
participants (3)
-
Clemens Gruber -
Jinqiang Zeng -
Luca Ellero