Messages in this thread | | | Date | Sat, 11 Oct 2008 16:36:00 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH/RFC] hardware irq debouncing support |
| |
Hi!
> > > Ok, so the limitations of various chips vary a lot...which means that > > > it's difficult to predict what IRQF_DEBOUNCED actually does. > > > > The specific QOS achieved is system-specific; the term for > > that kind of mechanism is "hinting". It's very clearly defined > > what the hint means .. but a given system might not use it. > > I know that, but is "hinting" really what drivers need? > > > The madvise(2) system call is a userspace example of hinting. > > That's different. Ignoring madvise() hints might hurt performance > slightly, but it won't result in any fundamentally different behaviour. > > On the other hand, lack of debouncing might cause the gpio_keys driver > to report 1000 keypresses instead of one when the user pushes a button. > That's much more harmful. > > So if someone goes and replaces the debounce timer in gpio_keys with > this IRQF_DEBOUNCE flag, it might work very well on hardware which > happens to use a 30 ms debounce interval, but will break horribly on > hardware with shorter debounce intervals.
Right. So you don't _replace_ debounce timer, you just do both timer and IRQF_.
> > > > Why require "software debouncing" if perhaps the hardware could do > > > > it all for you? > > > > > > Because of the "perhaps" part of your sentence. > > > > I'm not sure which sentence you refer too, but the first > > "perhaps" above is yours! :) > > I mean that it's difficult to rely on hardware that "perhaps" can do > debouncing for you. I think many drivers need to know for sure.
Why? You write code as if no debouncing exist...
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |