On Thu, 5 Jul 2012 20:30:35 +1000, Anton Blanchard <anton@xxxxxxxxx>
wrote:
> I had a closer look. I dumped the RC6 debug, but I also printed the raw
> data in the interrupt handler:
>
> printk("%x %d %d\n", irdata, rawir.pulse, rawir.duration);
>
...
> That should have been a pulse but it came out as a space. This makes me
> wonder if there is an issue with the run length encoding, perhaps when
> a pulse is the right size to just saturate it. It does seem like we
> set the top bit even though we should not have.
It's quite weird to see a "short" space followed by a max space followed
by a "short" space (0xdc 0xff 0xde). Almost like there's one or more
(pulse) bytes missing in between.
I've tested long pulses/spaces before and they've worked as expected (e.g.
"max", "max", "short" events....the leading 0x7f 0x7f 0x08 sequence in your
log is a good example).
Now, there is a minor bug in the RLE decoding in that the duration should
have 1 added to it (meaning that 0x00 or 0x80 are valid values).
Just to make sure something like that isn't happening, could you correct
the line in wbcir_irq_rx() which currently reads:
rawir.duration = US_TO_NS((irdata & 0x7F) * 10);
so that it reads
rawir.duration = US_TO_NS(((irdata & 0x7F) + 1) * 10);
However, I'm guessing you inserted the extra debug printk inside
wbcir_irq_rx() so any 0x00 or 0x80 bytes would have been printed?
Another possibility is that the printk in the interrupt handler causes
overhead...could you do a debug run without the printk in the interrupt
handler?
Also, could you provide me with the full versions of both logs? (i.e. all
the way to idle....it might help spot a missed pulse/space)
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
