> -----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
