Re: tm6000 and IR

[Stefan Ringel <stefan.ringel@arcor.de>]

Am 18.12.2010 14:56, schrieb Andy Walls:
> On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:
>
>
>> Despite all discussions, we didn't reach an agreement yet.
>>
>> There are some points to consider whatever solution we do:
>>
>> 1) A keycode table should be able to work with a generic raw decoder. So, on all
>> drivers, the bit order and the number of bits for a given protocol should be the same;
>>
>> 2) we should avoid to cause regressions on the existing definitions.
>>
>> That's said, suggestions to meet the needs are welcome.
> Just to throw out some ideas:
>
> It appears to me that what you are looking at are communications
> protocols with
>
> a. a common Physical layer (PHY): a pulse distance protocol with a
> common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
> and repeat sequence.  The number of bits (and the leader pulse length?)
> is allowed to vary.
>
> b. differing Data Link layers (LL): the data link address can be
> different lengths and in different places; so can the data payload, so
> can the checks on address and data payload.
>
> For the end user, I would present each PHY/LL combination a different
> protocol.  How the kernel implements it internally doesn't matter much.
> It could be one raw decoder handling all the PHY/LL combinations that it
> can, or one PHY decoder and several LL decoders.
>
> The keytables should probably be working on cooked LL output from the
> raw decoder.  I think that will handle a lot of the issues you mention.
> The output from a LL could include
>
> 	destination address (from the transmitted code),
> 	source address (useful if different remotes can be detected),
> 	payload length,
> 	payload, and
> 	maybe button up/down.
>
> The LL could swallow the automatic repeats, since they are just part of
> the button up/down scheme.
>
> Aside from backward compatibility with existing keytables, I don't see
> much point in a decoder trying to flip bits from the PHY layer around to
> present a pseudo-PHY layer output.  Don't keytables get updated with the
> kernel release anyway, or did they all move to userspace utils?
>
>
> Anyway, just some thoughts.
>
> Regards,
> Andy
>
>
>> Thanks,
>> Mauro
>
TM5600, TM6000 and TM6010 IR
==========================

It give two ways to receive data

1. over the control pipe (ep0)
- polling must stop if it loads firmware
- data length are a byte (command)

2. over interrupt pipe (only TM6010)
- data length are two bytes (address << 8 | command)

It has any control registers to configure IR (protocol ...)

TM6010_REQ07_RD8_IR
??, we use 0x2f

TM6010_REQ07_RD8_IR_BSIZE
??

TM6010_REQ07_RD8_IR_WAKEUP_SEL
command mask, I think,   we use here 0xff

TM6010_REQ07_RD8_IR_WAKEUP_ADD
address mask, we use 0xff

TM6010_REQ07_RD8_IR_LEADER1
TM6010_REQ07_RD8_IR_LEADER0
is a 16bit register
for NEC 0xaa30

TM6010_REQ07_RD8_IR_PULSE_CNT1
TM6010_REQ07_RD8_IR_PULSE_CNT0
is a 16bit register
for NEC 0x20d0


Stefan Ringel