[linux-dvb] Re: Problem conserning NEWSTRUCT drivers, DVB-C andQAM 128

[Jaakko Hyvätti <jaakko@hyvatti.iki.fi>]

  Hi,

  I found the reason for this.  The ves1820 register 0 is first set to the
correct QAM setting, but immediately after that FE_RESET is called, and
reg0 value is lost and QAM_128 value is replaced in there.  I added a
couple of printk's to obvious places to find this:

Sep  8 04:20:04 pupu kernel: ves1820.c: Setting tuner type 1 to 161.750000 MHz
Sep  8 04:20:04 pupu kernel: ves1820.c: reg0 69
Sep  8 04:20:04 pupu kernel: ves1820.c set to QAM_64, 6.900000 Msym/s, inversion:0
Sep  8 04:20:04 pupu kernel: ves1820.c reset, reg0 6d

  This is because the internal storage of the ves1820 driver data is not
updated correctly when changing from QAM_128 to QAM_64.  The bits are
OR'ed but no bits are cleared.  As QAM_128 is represented by bits 011 and
QAM_64 is represented as 010, the QAM_128 setting is premanent if set
once.  Here is a patch:

Index: driver/frontends/ves1820.c
===================================================================
RCS file: /cvs/linuxtv/DVB/driver/frontends/Attic/ves1820.c,v
retrieving revision 1.1.2.10
diff -u -r1.1.2.10 ves1820.c
--- driver/frontends/ves1820.c	19 Aug 2002 12:08:18 -0000	1.1.2.10
+++ driver/frontends/ves1820.c	8 Sep 2002 02:09:08 -0000
@@ -31,13 +31,13 @@
 #define dprintk	if (debug) printk


-#define SET_PWM(frontend,pwm) do { (int) frontend->data |= pwm; } while (0)
+#define SET_PWM(frontend,pwm) do { (int) frontend->data &= 0xffff00; (int) frontend->data |= pwm; } while (0)
 #define GET_PWM(frontend) ((u8) ((int) frontend->data & 0xff))

-#define SET_REG0(frontend,reg0) do { (int) frontend->data |= reg0 << 8; } while (0)
+#define SET_REG0(frontend,reg0) do { (int) frontend->data &= 0xff00ff; (int) frontend->data |= reg0 << 8; } while (0)
 #define GET_REG0(frontend) ((u8) (((int) frontend->data >> 8) & 0xff))

-#define SET_TUNER(frontend,type) do { (int) frontend->data |= type << 16; } while (0)
+#define SET_TUNER(frontend,type) do { (int) frontend->data &= 0xffff; (int) frontend->data |= type << 16; } while (0)
 #define GET_TUNER(frontend) ((u8) (((int) frontend->data >> 16) & 0xff))

  After this patch I can tune to all streams in HTV cable, except for the
138MHz one.  Probably below some hardware limit?  Well that's not free to
air anyway.

  Ps. I do not quite understand why dvb_register_frontend does this:
	return (struct dvb_frontend*) data;
..where data is the frontend internal data???

-Jaakko

-- 
Foreca Ltd                                           Jaakko.Hyvatti@foreca.com
Pursimiehenkatu 29-31 B, FIN-00150 Helsinki, Finland     http://www.foreca.com


On Tue, 3 Sep 2002, Antti Lammi wrote:
> Lainaus Antti O Lammi <alammi@cc.helsinki.fi>:
>
> > My enviroment is DVB-C (QAM 64-128), and Technotrend card with MPEG2
> > decoder.
> >
> > I tried to change my drivers to the NEWSTRUCT branch, but it seems that
> > QAM 128 does not work with those drivers. QAM 64 worked fine. I even made
> > this change to VDR 1.1.8 software:
> >   Frontend.u.qam.modulation = QAM_128;
> > Just before the tuning line:
> >  CHECK(ioctl(fd_frontend, FE_SET_FRONTEND, &Frontend));
> >
> > Funny thing about this is, that QAM 64 channels _still_ worked fine, even
> > I forced QAM 128.
>
> OK, I found something. I noticed there was something changed in setting the inversion/qam
> modes. So I did some testing in function ves1820_setup_reg0:
>
> - To make QAM 128 channels work, I just forced INVERSION_OFF for all channels. Then QAM
> 128 works OK, but QAM 64 works only when tuned _before_ any QAM 128 channels. After
> tuning any QAM 128 channel they don't work unless reloading the driver.
>
> - Not setting the inversion masks to reg0 _at_all_ has exactly same effects as above.
>
> - Forcing INVERSION_OFF for QAM 128, and INVERSION_ON for QAM 64, makes QAM 64 _not_ to
> work even before QAM 128 channels are tuned.
>
> Any ideas? Anybody?




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