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@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
