On Sat, 2008-07-12 at 00:52 -0400, Josh Becigneul wrote: > <quote who="Andy Walls"> > > On Fri, 2008-07-11 at 20:56 -0400, Josh Becigneul wrote: > >> > >> Not sure why this happens, any ideas? > >> > > > > lirc_i2c is the receive only module. lirc_pvr150 is a module that > > handles both Tx and Rx. I suspect they are mutually exclusive: you > > probably can't load lirc_i2c and lirc_pvr150 together. Try to inhibit > > the load of the lirc_i2c module. > > > > Regards, > > Andy > > Andy, > > I moved the lirc_i2c driver so it can never be loaded. Running modprobe > lirc_pvr150 results in the following: > > otherbox misc # modprobe lirc_pvr150 > FATAL: Could not open '/lib/modules/2.6.24-gentoo-r4/misc/lirc_i2c.ko': No > such file or directory
Did you mean "modprobe lirc_i2c" instead of "lirc_pvr150"? I didn't think lirc_pvr150 depended on lirc_i2c. The desired result of my suggestion is there: the lirc_i2c module didn't load. > > And this is from my syslog: > > Jul 12 00:29:16 otherbox ivtv: Start initialization, version 1.3.0 > Jul 12 00:29:16 otherbox ivtv: End initialization > Jul 12 00:29:16 otherbox lirc_dev: IR Remote Control driver registered, > major 61 > Jul 12 00:29:17 otherbox lirc_pvr150: chip found with RX and TX > Jul 12 00:29:17 otherbox lirc_dev: lirc_register_plugin: sample_rate: 0 > Jul 12 00:29:17 otherbox lirc_pvr150: firmware of size 302355 loaded > Jul 12 00:29:17 otherbox lirc_pvr150: 743 codesets loaded > Jul 12 00:29:17 otherbox i2c-adapter i2c-1: Used 4 tries to write to > client at 0x70: success > Jul 12 00:29:17 otherbox lirc_pvr150: Hauppauge PVR-150 IR blaster: > firmware version 2.1.0 On Mark's blog the firmware in the Zilog microcontroller has a different version: Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0 That's different from the HVR-1600's Zilgo firmware and could be a source of problems. But OK, so at least lirc_pvr150 found a Zilog chip on the cx23418's first I2C bus... > Jul 12 00:29:17 otherbox i2c-adapter i2c-2: NAK from device addr 0x70 msg #0 > Jul 12 00:29:17 otherbox i2c-adapter i2c-2: NAK from device addr 0x71 msg #0 > Jul 12 00:29:17 otherbox lirc_pvr150: cx18 i2c driver #0-1: no devices found and it didn't find one on the second I2C bus. > So far so good... Yes, I think so... > Running irsend results in the following: > > otherbox bin # ./irsend SEND_ONCE blaster POWER > buffer: -BEGIN- > buffer: -SEND_ONCE blaster POWER- > buffer: -ERROR- > irsend: command failed: SEND_ONCE blaster POWER > buffer: -DATA- > buffer: -1- > buffer: -transmission failed- > irsend: transmission failed > buffer: -END- > > lircd -n says: > > lircd: accepted new client on /dev/lircd > lircd: write failed > lircd: Remote I/O error > lircd: error processing command: SEND_ONCE blaster POWER > lircd: transmission failed > lircd: removed client > > Syslog says: > > Jul 12 00:47:49 otherbox i2c-adapter i2c-1: NAK from device addr 0x70 msg #0 > Jul 12 00:47:49 otherbox lirc_pvr150: i2c_master_send failed with -121 -121 is -EREMOTEIO IIRC. The "remote" in the remote I/O error refers to the I2C bus between the CX23418 and the Zilog microcontroller (IR blaster chip). It's hard for me to tell if this is a bonafide I2C bus error, or a protocol error (the microcontroller firmware changed since Mark did his captures of traffic). I'll have to investigate further. > Jul 12 00:47:49 otherbox lirc_pvr150: sending to the IR transmitter chip > failed, trying reset > Jul 12 00:47:49 otherbox i2c-adapter i2c-1: Used 4 tries to write to > client at 0x70: success OK, it looks like the reset code I added to the cx18 driver may work properly. > Jul 12 00:47:49 otherbox lirc_pvr150: unexpected IR TX response: a0 After loading the "boot block" after reset, the lirc_pvr150 was expecting a response of 80 here, not a0. Another indication of possibly a newer protocol in the Zilog microntroller firmware, or that maybe I did get the reset wrong. I was avoiding manipulating the DBG pin on the Zilog chip - the reset code in ivtv didn't make much sense to me in some of it's manipulations. > Jul 12 00:47:49 otherbox i2c-adapter i2c-1: NAK from device addr 0x70 msg #0 > Jul 12 00:47:49 otherbox lirc_pvr150: i2c_master_send failed with -121 > Jul 12 00:47:49 otherbox lirc_pvr150: sending to the IR transmitter chip > failed, trying reset > Jul 12 00:47:50 otherbox i2c-adapter i2c-1: Used 4 tries to write to > client at 0x70: success > Jul 12 00:47:50 otherbox lirc_pvr150: unexpected IR TX response: a0 > Jul 12 00:47:50 otherbox i2c-adapter i2c-1: NAK from device addr 0x70 msg #0 > Jul 12 00:47:50 otherbox lirc_pvr150: i2c_master_send failed with -121 > Jul 12 00:47:50 otherbox lirc_pvr150: sending to the IR transmitter chip > failed, trying reset > Jul 12 00:47:50 otherbox i2c-adapter i2c-1: Used 4 tries to write to > client at 0x70: success > Jul 12 00:47:50 otherbox lirc_pvr150: unexpected IR TX response: a0 > Jul 12 00:47:50 otherbox i2c-adapter i2c-1: NAK from device addr 0x70 msg #0 > Jul 12 00:47:50 otherbox lirc_pvr150: i2c_master_send failed with -121 > Jul 12 00:47:50 otherbox lirc_pvr150: sending to the IR transmitter chip > failed, trying reset > Jul 12 00:47:50 otherbox lirc_pvr150: unable to send to the IR chip after > 3 resets, giving up Well the lirc_pvr150 module gave up. The troubleshooting step, as I see them, that need to happen are: 1. Baseline that lirc_i2c.ko at least works for receiving IR codes. Forget about lirc_pvr150 and see if lirc_i2c receives the proper codes from the remote all the time. 2. With lirc_pvr150, I'll try some ivtv-like reset code for the Zilog in the cx18 driver to see if it makes a difference. 3. With licr_pvr150, I need to try to determine if the bytes that lirc_pvr150 is trying to send to the Zilog chip are actually the ones being sent. That'll involve turning on the debug for the i2c_algo_bit module (which may mean recompiling that module), maybe adding some printf()'s to lirc_pvr150 and the cx18-i2c.c:set_sda/scl() routines. 4. Depending if a. it is actual I2C errors, I have revisions in mind for the cx18-i2c.c:set_sda/scl() routines to make them more robust; or b. it's not I2C errors, but a protocol problem. You'll have to install the Hauppauge windows drivers, modify/build Mark's VB code (lirc/tools/pvr150/Form1.frm, etc.) for extracting the codesets and "boot blocks" and build a new "firmware" image using Mark other tools. Maybe not all in that order, though. > Hope this helps... I'm going to run downstairs and see if the light on the > blaster blinks at all. > I also found this thread which is a little more complete: > http://mysettopbox.tv/phpBB2/viewtopic.php?t=6206&postdays=0&postorder=asc&start=0&sid=88e71f09b17342208fcaca9e220bdd4d That is a nice writeup. > -Josh Becigneul Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
