On Wednesday 14 July 2004 04:16, Peter Henderson wrote: > I think I've fixed it. > > There is an integer underflow bug in mt352.c > need to change line 517 (based on rev 1.7 in cvs) > from > tmp = 6 * freq + IF_FREQUENCYx6; > to > tmp = ((param->frequency*6)/1000000) + IF_FREQUENCYx6; > > This affects any multiplex which is on a Positive or Negative offset. > (So 4978333330Hz fails but 690000000Hz would be fine) > > So Ben this should fix your problem as Crystal Palace is all Pos/Neg > offsets.
According to the datasheet (* p.44), this calulation is wrong. I've attached a patch which corrects this and also adds the requested change below. Please test a clean CVS with this patch, as I don't have this card/frontend/dvb-t. > As a side note. > Can FEC_NONE be added as a case to the LP code rate switch statements > (and probably the HP as well) as this was the original reason I couldnt > tune anything and had to comment out the default error return. It will then default to FEC_1_2, is this okay? Kenneth * http://assets.zarlink.com/DM/MT352_Design_Manual_Nov03.pdf
Index: mt352.c =================================================================== RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/frontends/mt352.c,v retrieving revision 1.7 diff -u -r1.7 mt352.c --- mt352.c 8 Jul 2004 17:05:42 -0000 1.7 +++ mt352.c 14 Jul 2004 13:08:38 -0000 @@ -395,6 +395,7 @@ break; case FEC_1_2: case FEC_AUTO: + case FEC_NONE: break; default: return -EINVAL; @@ -415,6 +416,7 @@ break; case FEC_1_2: case FEC_AUTO: + case FEC_NONE: break; default: return -EINVAL; @@ -514,7 +516,7 @@ /* here we assume 1/6MHz == 166.66kHz stepsize */ #define IF_FREQUENCYx6 217 /* 6 * 36.16666666667MHz */ - tmp = 6 * freq + IF_FREQUENCYx6; + tmp = 6 * (freq + IF_FREQUENCYx6); buf[9] = msb(tmp); /* CHAN_START_(1|0) */ buf[10] = lsb(tmp);
