Hello Tony, On 26.07.23 12:10, Tony He wrote:

Hi,

I'm writing button driver. The button is based on GPIO.When the button is pressed or released, the interrupt is generated. According to the GPIO value(1 or 0) , I can know which action is taken(pressed or released). However, a question occurred to me. Do I need to consider when to get the GPIO value? I mean is it possible that GPIO value will be changed caused by another interrupt when I get the GPIO value in top or bottom half of first interrupt? I know the CPU is fast and pushing/releasing button is slow, so it should not happen in practice. But let's just consider this case in theory. You can assume the button is pushed or released very very fast.

This is not only a theoretical issue. The transition from button being pressed to unpressed and back is not noise free, so a naive translation of IRQ/GPIO state to input events may not be sufficient. Dealing with this is called debouncing and involves taking multiple samples before signalling the input event.

Seems that GPIO interrupt is special comparing with other device with cache. There is no cache to store data(GPIO value) for GPIO. Right? Can someone help to clarify this question? Thanks a lot.

IRQ handlers have a second argument with a pointer to device specific data. You can store information there and many drivers do so. You need to take care that the data isn't accessed concurrently though, e.g. via a spinlock. You can see how all this is implemented in the Linux gpio_keys driver. Cheers, Ahmad

Tony

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |