Re: Fix for "MT2032 Fatal Error: PLLs didn't lock"

[Gerd Knorr]

> I saw others report same issues but didnt see any
> fixes/patches/solutions. With the debug option on for bttv and tuner in
> /etc/modules.conf and the TV frequency set to 133.25MHz and then
> 140.25MHz, the sign extension defect pops up in rfin value below. This
> is because 133.25MHz is 0x7F13BD0 and 140.25MHz is 0x85C0B90. The high
> bit gets sign extended in as 0xFFFFFFFFF85C0B90 (-128185456)

Huh?  I can't see where a sign extension happens.  0x85C0B90 has the bit
#27 set to one, not #31 ...

Beside that the values are passed around as unsigned values everythere.
Can you please explain in more detail what is going on?

> Nov 16 21:45:56 localhost kernel: tuner: tv freq set to 133.25
> Nov 16 21:45:56 localhost kernel: mt2032_set_if_freq rfin=133250000
> if1=1090000000 if2=38900000 from=32900000 to=39900000

> Nov 16 21:45:58 localhost kernel: tuner: tv freq set to 140.25
> Nov 16 21:45:58 localhost kernel: mt2032_set_if_freq rfin=-128185456
> if1=1090000000 if2=38900000 from=32900000 to=39900000

Works fine here:

tuner: tv freq set to 140.25
mt2032_set_if_freq rfin=140250000 if1=1090000000 if2=38900000 from=32900000 to=39900000

>  	case VIDIOCSFREQ:
>  	{
> -		unsigned long *v = arg;
> +		unsigned int *v = arg;

Wrong, VIDIOCSFREQ is "_IOW('v',15, unsigned long)".  Beside that I'm
very surprised that this actually makes a difference.  What architecture
is that?  And what size int/long have there?

> -				(*iarg)/16,(*iarg)%16*100/16);
> +				(*v)/16,(*v)%16*100/16);

That is ok.

  Gerd

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