* Tony Lindgren <tony@xxxxxxxxxxx> [170315 09:37]: > * Ladislav Michl <ladis@xxxxxxxxxxxxxx> [170314 23:20]: > > 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. > > OK sure no problem. Hmm maybe we need to flush posted writes when re-enabling the GPIO interrupts? Below is an untested patch that might help if that's the case. Regards, Tony 8< -------------------------- diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -578,6 +578,7 @@ static void omap_enable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask) } writel_relaxed(l, reg); + l = readl_relaxed(reg); } -- 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
