<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> > I know that i2c_master_send can handle up to 64k... so I think I may try<br>
>> > and<br>
>> > force it to send everything in one go rather than breaking it up.  I<br>
>> > doubt<br>
>> > it will work, but it would be interesting if it did.<br>
<br>
</span>i2c_master_send() does indeed have that 64K limit, but many actual I2C<br>
master hardware implementations can't support anywhere near that.<br>
It's not uncommon for them to have length limits on the order of 16 or<br>
64.  In other words, don't assume that just because the Linux<br>
framework supports sending messages up to that size that the hardware<br>
itself can support it.<br>
<span class=""><br>
>> > Beyond that, I can't see anything else to do to make this faster.<br>
>><br>
>> You will likely have to look at the IC datasheets, HD-PVR schematics,<br>
>> and HD-PVR firmware (only the first is likely publicly available) to know<br>
>> what can be sent across the i2c bus.  It can be fun experimenting and<br>
>> reverse engineering, but it may not be successful.<br>
<br>
</span>Bear in mind that the Windows driver implementation for the ZIlog was<br>
originally written for the much older PVR-x50 cards (which is what got<br>
copied through reverse engineering into the Linux implementation).<br>
Hence it's likely that I2C masters in newer hardware designs such as<br>
the HDPVR don't have the 4-byte limit - but bear in mind that if you<br>
change the driver than it will likely be rejected upstream since it<br>
would break interaction with older products that use the same driver.<br>
<span class=""><br>
>> At some point, it is likely going to be worth your time to simply purchase<br>
>> another transmitter (but you probably already knew that).<br>
>><br>
>> Good luck.<br>
><br>
><br>
> Believe it or not... it works fine passing all 400 bytes at once.  Shaved<br>
> the time for 10 key presses from over 10 seconds to under 9 seconds... sigh.<br>
<br>
</span>Correct, the I2C master on the Ambarella doesn't have the 4-byte<br>
limit.  I have an implementation which I've used in house which puts<br>
the whole blob out in a single transaction.<br>
<br>
The bulk of the time won't be clocking out the bytes for the<br>
particular RC code.  It's the last I2C message which says "go" once<br>
the RC blob is fully loaded which is going to block until the code is<br>
fully transmitted (and RC codes themselves can have a delay at the end<br>
after clocking out the last pulse).  Also bear in mind that how long<br>
it takes can vary based on the particular RC codeset and protocol that<br>
your particular STB requires.  Hence it's entirely likely that other<br>
people may say that it works much faster if they're talking to a STB<br>
that doesn't require as much delay between keys.<br>
<br>
Just as a test, you may wish to fire the HDPVR up under Windows and<br>
see if it exhibits the same behavior.  That will tell you definitively<br>
if the Linux driver is doing something that is outright dumb (i.e. not<br>
properly emulating the Windows behavior), or it it might just be a<br>
limitation of the particular RC codeset required for your STB.<br></blockquote><div><br></div><div>Well... testing in windows does seem to indicate that it's an issue with the codeset as it's every bit as slow there as in linux.</div><div><br></div><div>I guess I will just have to accept it as is for now, until I can find something better.</div><div><br></div><div>Speaking of better, I know the MCEUSB devices are the best supported, but I can't seem to find anything that has multiple transmitters.  I know I had an old ehome unit that had two emmitter ports, but I am not sure they were independently addressable.</div><div><br></div><div>I would welcome suggestions of a working solution for 4 emitters that is dirt cheap and easily implemented (would rather not have to compile drivers for each one and whatnot).</div><div><br></div><div>Thanks everyone for your input on this... it's been fun getting into the code.</div></div></div></div>