On Wed, Oct 11, 2017 at 08:25:12PM -0400, Devin Heitmueller wrote: > > There's an ir_lock mutex in the driver to prevent simultaneous access to > > the Rx and Tx functions of the z8. Accessing Rx and Tx functions of the > > chip together can cause it to do the wrong thing (sometimes hang?), IIRC. > > > > I'll see if I can dig up my old disassembly of the z8's firmware to see if > > that interlock is strictly necessary. > > > > Yes I know ir-kbd-i2c is in mainline, but as I said, I had reasons for > > avoiding it when using Tx operation of the chip. It's been 7 years, and > > I'm getting too old to remember the reasons. :P > > Yeah, you definitely don't want to be issuing requests to the Rx and > Tx addresses at the same time. Very bad things will happen.
Right, ok. That's good to know. I'll have to merge the Tx code with ir-kbd-i2c or port lirc_zilog Rx to rc-core. > Also, what is the polling interval for ir-kbd-i2c? lirc_zilog polls every 260ms and ir-kbd-i2c polls every 100ms. > If it's too high > you can wedge the I2C bus (depending on the hardware design). > Likewise, many people disable IR RX entirely (which is trivial to do > with lirc_zilog through a modprobe optoin). Yes, lirc_zilog has a tx_only option. > This is because early > versions of the HDPVR had issues where polling too often can interfere > with traffic that configures the component receiver chip. This was > improved in later versions of the design, but many people found it was > just easiest to disable RX since they don't use it (i.e. they would > use the blaster for controlling their STB but use a separate IR > receiver). That's very interesting. > Are you testing with video capture actively in use? If you're testing > the IR interface without an active HD capture in progress you're > likely to miss some of these edge cases (in particular those which > would hang the encoder). I had not, but I'll do that now. > I'm not against the removal of duplicate code in general, but you have > to tread carefully because there are plenty of non-obvious edge cases > to consider. Absolutely, thank you for your insights. Rather than relying on ir-kbd-i2c for receive, I can port lirc_zilog to rc-core and leave much of it in place. Thanks Sean
