On Jan 20, 2011, at 8:22 AM, Andy Walls wrote: > On Wed, 2011-01-19 at 23:45 -0500, Jarod Wilson wrote: >> On Jan 19, 2011, at 3:08 PM, Jarod Wilson wrote: > >>> I'm working on >>> fixing up hdpvr-i2c further right now, and will do some more prodding >>> with pvrusb2, the code for which looks correct with two i2c_new_device() >>> calls in it, one for each address, so I just need to figure out why >>> lirc_zilog is getting an -EIO trying to get tx brought up. >> >> So as we were discussing on irc today, the -EIO is within lirc_zilog's >> send_boot_data() function. The firmware is loaded, and then we send the >> z8 a command to activate the firmware, immediately follow by an attempt >> to read the firmware version. The z8 is still busy when we do that, and >> throwing in a simple mdelay() remedies the problem for both the hvr-1950 >> and the hdpvr -- tried 100 initially, and all the way down to 20 still >> worked, didn't try any lower. > > The Z8 on my HVR-1600 is using a 18.432 MHz crystal for its clock. > > The Z8 CPU Fetch and Execution units are running with a pipeline depth > of 1: 1 insn being executed while another 1 insn is being fetched. Most > Z8 fetch or execution cycle counts are in the range of 2-4 cycles. So > let's just assume an insn takes 4 cycles to execute. > > 18.432 MHz * 20 ms = 368,640 cycles > 368,640 cycles / 4 cycles/insn = 92,160 insns > > 20 ms is ~90k instructions, and seems like too long a delay to be just > for Z8 latency. Some further testing today with a try-check success-delay-retry loop shows one i2c_master_send() failure plus a udelay(100), and the second i2c_master_send() typically always works (I haven't seen it *not* work on the HVR-1950 in cursory testing). A second similar loop has proven necessary for IR TX attempts to actually claim to succeed -- not 100% certain they really worked, as I don't have the IR emitter with me at the moment, its at home hooked up to my hdpvr, but I suspect its working fine now. > I find it interesting that for the HVR-1600 the delay isn't needed at > all. > > I'm wondering if there might also be some Linux/USB latency in getting > commands shoved over to the HVR-1950's controller (or maybe latency in > the HVR-1950's controller too), for which this delay is really > accounting. I suppose in kernel tracing can be used to find the latency > on shoving things across the USB and watching for any Ack from the > HVR-1950 controller. An experiment for some other day, I guess. Yeah, definitely seems to be specific to usb devices. On the plus side, the delay loops should only add insignificant delay overhead for pci devices, since if they work on the first call, there won't be any delay added. Oh, I've also got IR RX with ir-kbd-i2c attached to the HVR-1950 working much better now, with the polling interval reverted to the standard 100ms, but simply introducing the same i2c_master_send() poll that lirc_zilog uses into get_key_haup_xvr(). I want to test today's changes with the hdpvr tonight (and verify that tx is working on the HVR-1950) before I send along my current stack of patches, and I have suspicions that most of the hdpvr-specific crud in lirc_zilog is bogus now -- it *should* behave exactly like the HVR-1950, which obviously doesn't follow any of those hdpvr-specific code paths, so I'm hoping we can rip out some additional complexity from lirc_zilog. -- Jarod Wilson jarod@xxxxxxxxxxxx -- 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
