Hi Tony, On Tue, Mar 14, 2017 at 11:21:25AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@xxxxxxxxxxx> [170311 12:13]: > > Hi, > > > > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [170310 15:06]: > > > Hi there, > > > > > > I'm using drivers/media/rc/gpio-ir-recv.c on DM3730 based board and getting > > > a lot of IR protocol decoding failures: > > > RC5(x/sz) decode failed at state 0 count 7 (855us space) > > > RC5(x/sz) decode failed at state 1 count 4 (1740us space) > > > RC5(x/sz) decode failed at state 4 count 1 (125000us space) > > > RC5(x/sz) decode failed at state 0 count 1 (182348us space) > > > RC5(x/sz) decode failed at state 0 count 1 (366us pulse) > > > etc... > > > Hacking gpio-ir-recv code to add debounce on GPIO pin makes situation > > > a bit better, but still bad enough. > > > It seems this problem is there since dawn of linux-omap time [1] and > > > can be easily reproduced requesting edge trigerred gpio interrupt, > > > feeding that gpio pin from signal generator and toggling another gpio > > > in interrupt hangler with scope hooked. > > > Last time patch [1] was updated to kernel 2.6.32 and you can find it > > > below. > > > > > > So it seems noone is really using edge triggered interrupts, right? > > > > Interesting, adding Grygorii to cc as well. > > > > > Now, patch bellow is for ancient omap1 variant (and I'd love to give it > > > a try with recent kernel, but everything I compiled so far is insanely > > > huge) and does not support both rising and falling edge. > > > > > > To make interrupt code reliable I do not see other option than to read > > > gpio input register and make loop similar as in patch bellow. However, > > > this was repeatedly rejected in the past. So, better ideas, anyone? > > > > > [1] http://marc.info/?l=linux-omap&m=119634410025393&w=2 > > > > Oh that thing yeah I remember testing it too. If we don't have any > > other options for edge interrupts I guess the loop is what we need to > > do. If you have some experimental patch to play with against the > > current mainline, please post it and I'll give it a try too. > > Hmm and we already seem to have a similar loop in the mainline kernel? > At least I could not easily spot what we might be missing. I'm sorry for not answering in timely manner, I cannot find a time to work on this, however I at least tried to write special handler for chips with set and clear registers, which improved handling, but still not working completely reliably. I'll try to find some time to clean it up and post. ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
