Subject: Re: Fix for "MT2032 Fatal Error: PLLs didn't lock"
From: "Subbu K. K." <kksubramaniam@novell.com>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
In-Reply-To: <1069743507.1270.2.camel@dog.blr.novell.com>
References: <20031124004835.3abbb4cf.akpm@osdl.org>
	 <20031124114620.GA29771@bytesex.org>
	 <1069743507.1270.2.camel@dog.blr.novell.com>
Content-Type: text/plain
Message-Id: <1069917999.1914.85.camel@dog.blr.novell.com>
Mime-Version: 1.0
Date: Thu, 27 Nov 2003 12:56:39 +0530
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1312
Lines: 39

On Tue, 2003-11-25 at 12:28, Subbu K. K. wrote:
> Let me poke around in the assembly code tonight to find out why the sign
> change happens on my box. I suspect this could be due to gcc/athlon
> combo.
> 
ok. Found the error.

bttv-0.7.103 and earlier (kernel 2.4.20 and earlier) had the following
lines in two places:
  mt2032_set_if_freq(c,freq* 1000*1000/16, ...
When freq is defined as int, this computation causes a sign extension
error when freq is 2244 (140.25MHz). The error disappears if
1000*1000/16 is replaced with 62500 and/or if freq is defined as
unsigned int.

Here is a simple test to surface this error:
// test with gcc -o signext signext.c && ./signext
main(int argc, char *argv[])
{
	int s; unsigned f;

	s = 2244; f = s;
	printf("freq=%d rfin=%d\n", s*62500, s*1000*1000/16);
	printf("freq=%d rfin=%d\n", f*62500, f*1000*1000/16);
}
the output shows:
freq=14025000 rfin=-128185456
freq=14025000 rfin=140250000

bttv-0.7.104+ and kernel 2.4.21+ have the fix. Still, I thought of
recording the error for those still on older kernels.

Subbu K. K.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/