Re: SONY IR issue

[Sean Young <sean@xxxxxxxx>]

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.

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