Re: nvidia fb flicker

["Antonino A. Daplas" <adaplas@gmail.com>]

Linus Torvalds wrote:
> 
> On Tue, 29 Nov 2005, Antonino A. Daplas wrote:
>> Nov 28 14:02:32 stiffy kernel: Extrapolated
>> Nov 28 14:02:32 stiffy kernel:            H: 75-75KHz V: 60-60Hz DCLK: 162MHz
>>
>> Since the min and max value of the sync timings are equal, nvidiafb has
>> no room left to verify the timings, and will _always_ reject any timings even
>> if they are valid.
>>
>> So, try this patch, we make nvidiafb less restrictive by ignoring the
>> hsync and vsync ranges if the min and max values are equal. This should
>> make your hardware display properly even if CONFIG_FB_NVIDIA_I2c = y.
> 
> Tony,
> 
>  may I suggestinstead making the verifier allow a small error?
> 
> I don't find it at all unlikely that some EDID blocks might say that only 
> a 60Hz refresh rate is allowed. A lot of LCD's are literally specced for 
> that (just read their manuals), even though they often in practice allow 
> other frequencies (often _wildly_ different - most modern LCD's are 
> perfectly happy to sync up with almost anything).
> 
> And if a monitor says that it wants a vertical frequency of 60Hz, a mode 
> that has a frequency of 59 should certainly be accepted.
> 
> So it sounds like something has marked a perfectly valid mode as invalid, 
> just because it's not _exactly_ at the frequency.
> 
> So how about allowing a small error in the frequencies in 
> fb_validate_mode()? And make sure to try to round the divisions to 
> nearest, not down. Something like the appended (totally untested)..
> 

Yes, your patch looks good, and will fix some of the reports I've received.

However, after giving it some more thought, I believe my original
reasoning is probably incorrect.  Because if nvidiafb rejected the
mode timings, nvidiafb would not have loaded at all, but it did.

Which leads me to conclude that Calin's display EDID, specifically the
timing information, is totally garbage.

Calin, can you verify? Set CONFIG_FB_NVIDIA_I2C = y.

First, apply Linus' patch, then boot without any options.  If you get a
nice display, then my original reasoning is correct, and Linus' patch
is all we need.

Secondly, if you get a corrupt display after doing the above, then apply
my patch and boot without any options.  If you get a working display,
something is wrong with Linus' patch :-)  But most probably you'll also get
a corrupt display, so...

Finally, boot with video=nvidiafb:1600x1200MR@60.  If you reach this stage
and you get a working display, then the conclusion is that you have a
garbage EDID block :-).  And we will need both Linus' patch plus another
patch, perhaps a boot option that tells nvidiafb to totally ignore the
EDID block. (We don't want to disable the i2c bus because this is still
useful in userspace).

Tony

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