On Friday 04 December 2009 14:51:02 Anisse Astier wrote: > On Fri, 4 Dec 2009 11:55:53 +0100, Thomas Renninger <trenn@xxxxxxx> wrote : > > > > > > > > +#define dprintk(msg...) do { \ > > > Isn't reimplementing some kind of dprintk a little outdated with > > > DYNAMIC_PRINTK now in kernel? > > Eh, DYNAMIC_PRINTK? > > grep DYNAMIC_PRINTK include/linux/ -r > > is empty... > > My mistake, the option name is actually DYNAMIC_DEBUG, and is named "Enable > dynamic printk() support" in Kernel Hacking config. > cf Documentation/dynamic-debug-howto.txt Good catch. > > > > + cur = ktime_get_real(); > > > > + /* Ignore event if the same event happened in a 50 ms > > > > + timeframe -> Key press may result in 10-20 GPEs */ > > > > + if (ktime_to_us(ktime_sub(cur, key->last_pressed)) > > > > + < 1000 * 50) { > > > ... > I see no problem with the above. It just works fine, whether you use > get_jiffies or a ktime. > > The thing Dmitry was proposing to do in his review to my patch, is to use a > kernel timer (struct timer_list, mod_timer, etc.), and change the algorithm. > Instead of having as a reference the first interrupt of (or bounce), you use > the last one: > Every time an interrupt is fired, you call mod_timer() to the kick the timer > further in time(say 20ms). Once you didn't have any interrupt for this given > period of time, it means your button is stabilized, and the timer will fire > your report_input function. I see these disadvantages: - It would be more complicated code - You have one extra irq (the one fired by your aimed timer which finally does the work) - You react after the timeout (+50ms delay). The latter two are not sever. The advantage is: - If you get constant irqs over the 30ms/50ms timeout, you would still only switch once. But in this HW case, it really should be save with a 50ms timeout and I'd vote to take the ktime or get_jiffies approach. > You can see how it's done in drivers/input/keybourd/gpio_keys.c > > > > > Beside that (backlight) switching takes some time, but this should not > > be due to above "debouncing". > Yep, I noticed that as well. > I verified, backlight behave the same in Windows. Slow switch, and just 6 > levels. Thanks! I'd prefer if Len could take on top patches, I don't want to touch this again any time soon if not necessary. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html