RE: SONY IR issue

[Joakim Zhang <qiangqing.zhang@xxxxxxx>]

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