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

[Holger Waechtler <holger@convergence.de>]

Hi Dennis,

Dennis Noordsij wrote:
> 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).

No, they are read from an EEPROM with adress 0x50. Thanks for pointing 
this out, I committed it. It did not showed up to me because the 
Hauppauge card I have here worked fine without the value read from the 
EEPROM.


> 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.

Do you know what timeout dvbstream uses?

Holger



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