Re: Hauppauge WinTV-HVR2205 driver feedback

[Antti Palosaari <crope@iki.fi>]

On 06/03/2015 10:08 PM, Olli Salonen wrote:
> I cold booted my number cruncher after a hiatus of a couple of weeks,
> applied a couple of extra dev_dbg printouts in the si2168_cmd_execute
> and installed the newly built module. The results:
>
> [  663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached
> [  663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158
> successfully attached
> [  663.152436] DVB: registering new adapter (saa7164)
> [  663.152441] saa7164 0000:07:00.0: DVB: registering adapter 1
> frontend 0 (Silicon Labs Si2168)...
> [  678.690104] si2168:si2168_init: si2168 2-0064:
> [  678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0
> [  678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
> 12 00 0c 00 0d 16 00 00 00 00 00 00
> [  678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1
> [  678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0
> 06 01 0f 00 20 20 01
> [  678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
> [  678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms
> [  678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13
> [  678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02
> [  678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80
> 00 44 34 30 02 00 00 00 00 00 00 00
> [  678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms
> [  678.708639] si2168 2-0064: unknown chip version Si2168-
> [  678.714777] si2168:si2168_init: si2168 2-0064: failed=-22
> [  678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30'
> [  678.783587] si2157 0-0060: firmware version: 3.0.5
>
> The answer to the 02 command seems really odd. You can see it is a
> Si2168, version 40, but I'd expect the second octet to say 42 instead
> of 00.

Yeah, very odd. That byte should be letter A (0x41) or B (0x42) or 
likely C (0x43) in future when current C revision chips are seen.

Are you really sure it has returned (and worked) 0x42 earlier? Have you 
used Windows driver - I speculate if it could make permanent upgrade to 
chip to change it.

Timing issues are also possible. Maybe you could test with some extra 
sleeps, like adding 100ms delay between command request and reply.

Unfortunately value of those 3 bytes are really important as driver 
selects firmware to download according them.

regards
Antti

-- 
http://palosaari.fi/