Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010

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

Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>
> At the above, you're just trying to reproduce whatever the original driver does,
> instead of relying on the i2c drivers.
>
> At the Linux drivers, we don't just send random i2c sequences in the middle of
> the setup. Instead, we let each i2c driver to do the initialization they need
> to do. 
>
> If you take a look on each call, for example:
> 		tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x0000, buf, 2);
>
> The first value determines the USB direction: 0x40 is write; 0xc0 is read;
> The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for
> i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14
> works better for bigger sizes.
>
> The third value gives the first byte of a write message and the i2c address. The lower
> 8 bits is the i2c address. The above sequence is playing with several different 
> i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f.
>
> Most of the calls there are read (0xc0). I don't know any device that requires
> a read for it to work. I suspect that the above code is just probing to check
> what i2c devices are found at the board. The writes are to a device at address
> 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation).
>
> I suspect that the probe sequence noticed something at the address 0x32 and is
> sending some init sequence for it. As this is not the tuner nor the demod, you
> don't need those setup for your device to work. Also, this address is not typical
> for eeprom. Without taking a look at the hardware, we can only guess what's there.
> My guess is that it is for some i2c-based remote controller chip. We don't need
> this for now. After having the rest working, we may need to return on it when
> patching ir-kbd.i2c.
>   

The i2c address 0x32 isn't ir, but I think it sets the power or so. Ir
has vendor requests. see tm6000_regs.h . The i2c addresses 0x10 and 0xc0
cannot say what this is (check i2c address space or so). and the i2c
address 0x1f is the read address from demodulator.

-- 
Stefan Ringel <stefan.ringel@arcor.de>