[linux-dvb] Patch for frontends/ves1820.c

[Dennis Noordsij <dennis.noordsij@wiral.com>]

Hi,

Old drivers:
VES1820.c :
int init(struct i2c_client *client) - msgs[0].addr=msgs[1].addr=(0x28<<1);

HEAD drivers:
frontends/ves1820.c :
struct i2c_msg msg [] = { { addr: 0x28, flags: 0, buf: b0, len: 1 },
                      { addr: 0x28, flags: I2C_M_RD, buf: &pwm, len: 1 } };

In this ves1820 init function the pwm values are read from the ves1820 chips 
on the cards. 

If you change "addr: 0x28" in the HEAD drivers to "addr: 0x28 << 1" as in the 
old drivers, it now reads the same PWM values as the old drivers did 
(otherwise it would get like 0x00 and then 0xff - now it's 0x15 and 0x34). 
Now both cards tune properly :-)   (before 1 would occasionally tune, the 
other wouldn't).

I'm still poking around for other things, I added a printk in 
dvb_frontend_add_event for when there is a FE_HAS_LOCK event, and both cards 
will now tune and eventually (can take a second or 2 depending on zigzagging) 
report this FE_HAS_LOCK.

However, if I call dvbtune with certain parameters, it might time out before 
this FE_HAS_LOCK is reported. I wait until the FE_HAS_LOCK shows up in the 
logs, and call dvbtune again with the exact same parameters, expecting the 
card not to tune again but just set the video and audio pids. Instead, it 
starts tuning again, which again might time out dvbtune (causing it not to 
set the audio/video pids) but it will still lock eventually.

Complicated story :) I hope to figure some more out tonight.

The 0x28<<1 just stuck out like something that would be wrong.

Cheers,
Dennis






--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.