Hi Sean, GPIO IR Recv extremely rely on the real-time performance of the interrupt response, after turn off cpuidle, IR can work steadily now. Much thanks for your kindly help. 😊 Best Regards, Joakim Zhang > -----Original Message----- > From: Joakim Zhang > Sent: 2020年9月7日 16:52 > To: Sean Young <sean@xxxxxxxx> > Cc: linux-media@xxxxxxxxxxxxxxx; Andy Duan <fugang.duan@xxxxxxx>; > linux-gpio@xxxxxxxxxxxxxxx; Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > Subject: RE: SONY IR issue > > > > -----Original Message----- > > From: Sean Young <sean@xxxxxxxx> > > Sent: 2020年9月7日 16:41 > > To: Joakim Zhang <qiangqing.zhang@xxxxxxx> > > Cc: linux-media@xxxxxxxxxxxxxxx; Andy Duan <fugang.duan@xxxxxxx>; > > linux-gpio@xxxxxxxxxxxxxxx; Bartosz Golaszewski > > <bgolaszewski@xxxxxxxxxxxx> > > Subject: Re: SONY IR issue > > > > On Mon, Sep 07, 2020 at 06:58:43AM +0000, Joakim Zhang wrote: > > > > -snip- > > > > > > > > I wouldn't be surprised if the gpio device generates two > > > > > > interrupts for the broken pulse (one after 690us and another > > > > > > at 1200us), and if decoding happens before the second then the > > > > > > wrong > > pulse length is used. > > > > > I also check the number of interrupt generated by gpio. After I > > > > > press the key, > > > > RC transmits 7 frames, it should contain 182 falling/rising edges. > > > > > It indeed reports 182 interrupts and go through > > > > > ir_raw_event_store function 182 times. Since the number of > > > > > interrupt is accurate, just a few > > > > falling/rising interrupt comes much quickly than others, but the > > > > analog signal is perfect. It is really out of my understanding. It > > > > should not an > > issue in IR layer. > > > > > > > > I think the next step would be to put dev_dbg/printk in > > > > gpio-ir-recv.c, and see if the results are the same there. I > > > > suspect they will > > be. > > > Yes, as you suspected, the result is the same there. It seems to be > > > a system > > or gpio issue. > > > > > > > > > > > > > I also have a question, if RC transmit repeatedly 6 times, > > > > > > > and SONY decodes > > > > > > decode all raw data successfully, it will report to input > > > > > > subsystem > > > > > > 6 times, does input subsystem will still report to userspace 6 times? > > > > > > > > > > > > If the sony decodes the same values 6 times, then scancode > > > > > > will reported 6 imes, but there will be only one key down > > > > > > event, and a key up event about 100ms after the the last > > > > > > decode (plus a few other milliseconds for various timeouts). > > > > > Thanks for your details. Does this mean input subsystem will > > > > > still report > > > > scancode 6 times, but only report keycode once if it is matched? > > > > > > > > Exactly. The keycode is only reported once, so that if the user press e.g. > > > > "1" they will get just get one "1". > > > > > > > > > Sean, based on your experience, where else do you suggest me to > > > > > look into > > > > this further? Have you came across such case, a few interrupt > > > > responded so quickly so that front pulse/space is much shorten? > > > > > > > > To be honest I've never seen this before. > > > > > > > > I'm not sure what the cause could be. On the raspberry pi it is > > > > known that lots usb traffic causes delays in the gpio interrupt > > > > handlers due to some hardware issue, but this causes some > > > > interrupts to arrive late. This causes some of the pulse/space > > > > timings to be longer, and then later ones are shorter again as it catches > up. > > > > > > > > Similarly if the kernel is running with interrupts off for too > > > > long, some of the timings will be longer and others shorter. > > > Yes, we can understand the interrupt arrives late and cause the > > > timings > > incorrect. At my side, a few interrupt arrives too faster. > > > > I'm wondering where you captured the IR signal. If you captured the IR > > signal on the transmitter led, make sure the resolution is high enough > > so you can see the carrier. Then you can make sure there are no errors in > there. > > > > It might be better to capture the IR signal on the gpio signal going into the > SoC. > > Yes, the signal I captured is the output of the IR device, i.e. the gpio signal > going into the SoC. > > Best Regards, > Joakim Zhang > > > > Is there anything you can tell us about the gpio hardware? > > > GPIO is from our SoC, power supply with extern 3.3V, and I > > > configured it > > internal pull-up. > > > > Thanks > > Sean
