* GPIO and interrupt
@ 2023-07-26 10:10 Tony He
2023-07-26 11:09 ` Ahmad Fatoum
0 siblings, 1 reply; 2+ messages in thread
From: Tony He @ 2023-07-26 10:10 UTC (permalink / raw)
To: kernelnewbies
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.
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.
Tony
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: GPIO and interrupt
2023-07-26 10:10 GPIO and interrupt Tony He
@ 2023-07-26 11:09 ` Ahmad Fatoum
0 siblings, 0 replies; 2+ messages in thread
From: Ahmad Fatoum @ 2023-07-26 11:09 UTC (permalink / raw)
To: Tony He, kernelnewbies
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 |
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-07-26 11:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-26 10:10 GPIO and interrupt Tony He
2023-07-26 11:09 ` Ahmad Fatoum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).