RE: SONY IR issue

[Joakim Zhang <qiangqing.zhang@xxxxxxx>]

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