Implementing a driver that listen to a GPIO

Implementing a driver that listen to a GPIO

[Clemens Gruber]

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

Implementing a driver that listen to a GPIO

[Jinqiang Zeng]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Implementing a driver that listen to a GPIO

[Luca Ellero]

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

Implementing a driver that listen to a GPIO

[Luca Ellero]

On 02/10/2014 14:52, Greg KH wrote:
> On Thu, Oct 02, 2014 at 10:03:15AM +0200, Luca Ellero wrote:
>> Hi,
>> I'm working on an ARM platform running Linux kernel 2.6.35.
> Wow, you do realize just how old and obsolete that is, right?  Please
> upgrade to a new kernel version, you can not get any help from anyone in
> the community for something as ancient as that, sorry.
>
> Best of luck,
>
> greg k-h
>

Ok, let's suppose I'm running a recent kernel (I plan to do it).
My questions are the same.
Thanks
regards
Luca

Implementing a driver that listen to a GPIO

[Greg KH]

On Thu, Oct 02, 2014 at 10:03:15AM +0200, Luca Ellero wrote:
> Hi,
> I'm working on an ARM platform running Linux kernel 2.6.35.

Wow, you do realize just how old and obsolete that is, right?  Please
upgrade to a new kernel version, you can not get any help from anyone in
the community for something as ancient as that, sorry.

Best of luck,

greg k-h

Implementing a driver that listen to a GPIO

[Luca Ellero]

Hi,
I'm working on an ARM platform running Linux kernel 2.6.35.
The board is powered by a "micro UPS" that guarantees about 500 ms of 
"self-power" in case of a power failure.
Power failure is reported by a GPIO that can raise an interrupt when 
power is falling.
I would like to implement a mechanism which listen to the GPIO and when 
power is going down it saves some amount of data (about 100 KB) and then 
shutdown the board.

Which is best way to do that?

I'm thinking about 3 ways of doing that:

1) |using |theusermode-helper API:
Implement a driver which use c|all_usermodehelpe|rto launch an user 
space app

2) Using a gpio-event driver, as explained here:

http://wiki.gumstix.org/index.php?title=GPIO_Event_Driver#Detecting_events

3) Implement my own driver using completions. Something like this:

DECLARE_COMPLETION(comp);

interrupt_handler(){
     complete(comp);
}

ups_read (){
     wait_for_completion(&comp);
     copy_to_user(...something...);
     return 0; /* EOF */
}

static const struct file_operations ups_driver_ops = {
     .owner        = THIS_MODULE,
     .read        = ups_read,
};

static struct miscdevice hello_miscdev = {
     .minor        = MISC_DYNAMIC_MINOR,
     .name        = "ups",
     .fops        = &ups_driver_ops
};

init (){
     request_irq(interrupt_handler);
     misc_register(&hello_miscdev);
}

and in userspace a process which execute a read from /dev/ups. When the 
call to readreturns, it means that power is falling.


What do you think? Any suggestion is welcome.

Thanks
Regards
Luca Ellero