Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes

[Andy Walls <awalls@md.metrocast.net>]

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. 

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.



> And I definitely horked up the hdpvr i2c a bit, but have a follow-up
> patch that goes back to doing the right thing with two i2c_new_device()
> calls, which I've successfully tested with the latest lirc_zilog plus
> mdelay patch.

Yay!

Regards,
Andy