[mythtv-users] HDPVR IR blaster slow

[Joseph Fry]

On Sat, Jun 20, 2015 at 1:07 PM, Joseph Fry <joe at thefrys.com> wrote:

> On Sat, Jun 20, 2015 at 12:55 PM, Gary Buhrmaster <
> gary.buhrmaster at gmail.com> wrote:
>
>> On Sat, Jun 20, 2015 at 4:23 PM, Joseph Fry <joe at thefrys.com> wrote:
>> .....
>> > In the function description you see that it says it returns a negative
>> error
>> > number, or the number of bytes written.  If you look at the actual
>> return
>> > statement, it's returning the count (or the error from i2c_transfer).
>> >
>> > I think I need to patch lirc_zilog:
>> >
>> > for (i = 0; i < 10; i++) {
>> > ret = i2c_master_send(tx->c, buf, 1);
>> > - if (ret == 1)
>> > + if (ret > 0)
>> > break;
>> > udelay(100);
>> > }
>> >
>> > Can anyone confirm my conclusion?  My programming skills are limited to
>> > scripts... so this is new territory for me.
>>
>> Since the return is the count, and you only send 1 character,
>> a "successful" send would be the count passed in, or 1.
>>
>> So, while you may be on the right track, this does not seem
>> to be the bug you are looking for (and btw, if you write <n>
>> bytes, if the return is not <n>, you need to handle the short
>> write case in some form, as the code immediately above
>> does for a return not equal to the 2 case.).
>
>
> I just tested this... and indeed your right.  I added in some debug output
> and see that the pause is occuring after the "sent code..." message.  And I
> was able to confirm that i2c_master_send is returning 1 every time.
>
> so... time to keep digging.
>

Ok... here is where I am now.

When sending a button, lirc_zlog reports this to syslog (with debugging
enabled):

Jun 20 14:03:13 mythserver kernel: [10341.776138] lirc_zilog: 01 60 7e a2 d9
Jun 20 14:03:13 mythserver kernel: [10341.795537] lirc_zilog: 05 49 0e 48
91lirc_zilog: 09 77 d6 3d 09
Jun 20 14:03:13 mythserver kernel: [10341.835569] lirc_zilog: 0d 44 18 60
f1lirc_zilog: 11 32 c6 e9 bb
Jun 20 14:03:14 mythserver kernel: [10341.875489] lirc_zilog: 15 2f c5 4a
e3lirc_zilog: 19 b9 a0 48 a2
Jun 20 14:03:14 mythserver kernel: [10341.915157] lirc_zilog: 1d 7d 81 59
90lirc_zilog: 21 28 0d 48 69
Jun 20 14:03:14 mythserver kernel: [10341.955083] lirc_zilog: 25 10 c4 78
78lirc_zilog: 29 27 51 1e 71
Jun 20 14:03:14 mythserver kernel: [10341.995125] lirc_zilog: 2d 09 de 13
c5lirc_zilog: 31 18 d2 56 36
Jun 20 14:03:14 mythserver kernel: [10342.034793] lirc_zilog: 35 8e 59 93
6blirc_zilog: 39 9c f1 d5 e5
Jun 20 14:03:14 mythserver kernel: [10342.074715] lirc_zilog: 3d cf c4 ba
05lirc_zilog: 41 cb 81 e5 26
Jun 20 14:03:14 mythserver kernel: [10342.115762] lirc_zilog: 45 f3 f1 b7
6elirc_zilog: 49 88 29 c2 f6
Jun 20 14:03:14 mythserver kernel: [10342.155681] lirc_zilog: 4d bb e7 9f
1alirc_zilog: 51 ed 39 93 45
Jun 20 14:03:14 mythserver kernel: [10342.195353] lirc_zilog: 55 cd 3b d9
1clirc_zilog: 59 89 fe b7 5d
Jun 20 14:03:14 mythserver kernel: [10342.235402] lirc_zilog: 5d 82 7e 44
a1lirc_zilog: 61 00 00 00 a1
Jun 20 14:03:14 mythserver kernel: [10342.327126] lirc_zilog: sent code
130, key 2

Only after that does the led flash.  And while all the above happens
quickly, it does take some time.

I am sure there is a good reason for it, but zilog is breaking the data up
in to 32bit chunks and sending them one chunk at a time, prefixing them
with 1 byte that indicates where in the stream they are... first block
starts at 01, next is 05, and so on.

static int send_data_block(struct IR_tx *tx, unsigned char *data_block)
{
int i, j, ret;
unsigned char buf[5];

for (i = 0; i < TX_BLOCK_SIZE;) {
int tosend = TX_BLOCK_SIZE - i;
if (tosend > 4)
tosend = 4;
buf[0] = (unsigned char)(i + 1);
for (j = 0; j < tosend; ++j)
buf[1 + j] = data_block[i + j];
dprintk("%*ph", 5, buf);
ret = i2c_master_send(tx->c, buf, tosend + 1);
if (ret != tosend + 1) {
zilog_error("i2c_master_send failed with %d\n", ret);
return ret < 0 ? ret : -EFAULT;
}
i += tosend;
}
return 0;
}


I know that i2c_master_send can handle up to 64k... so I think I may try
and force it to send everything in one go rather than breaking it up.  I
doubt it will work, but it would be interesting if it did.

Beyond that, I can't see anything else to do to make this faster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150620/ca1eeabc/attachment.html>