fb: nvidiafb: Try harder at initial mode setting.
authorPaul Mundt <lethal@linux-sh.org>
Wed, 6 Feb 2008 09:39:18 +0000 (01:39 -0800)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Wed, 6 Feb 2008 18:41:16 +0000 (10:41 -0800)
commit74f482cca5f76643e7f323e66cc38b1a882d5e6f
tree7b547bb4b139aa04983079359d4594b45a023af4
parent2e9750272cd49732293b6fe771ae110be8d87273
fb: nvidiafb: Try harder at initial mode setting.

The current nvidiafb_check_var() simply bails out if the selected mode is
out of range of the panel dimensions.  A good question would be why the
bogus mode is being selected in the first place -- the panel dimensions
that are read back are certainly bogus, but alas, I have no idea where to
even begin looking at the i2c/EDID/DDC mess:

nvidiafb: Device ID: 10de0165
nvidiafb: CRTC0 analog not found
nvidiafb: CRTC1 analog not found
nvidiafb: EDID found from BUS1
nvidiafb: CRTC 0 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 0
nvidiafb: Panel size is 1280 x 1024
nvidiafb: Panel is TMDS
nvidiafb: unable to setup MTRR
nvidiafb: Flat panel dithering disabled
nvidiafb: PCI nVidia NV16 framebuffer (64MB @ 0xC0000000)

In my .config I presently have:

CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_NVIDIA_I2C=y

I've not tried fiddling with these options, as I haven't the vaguest idea
what I should be looking at.

As a workaround, simply groveling for a new mode based on the probed
dimensions seems to work ok.  While it would be nice to debug this further
and sort out why the panel information is bogus, I think it's still worth
retrying the mode based on the panel information at hand as a last-ditch
effort, rather than simply bailing out completely.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Cc: Antonino A. Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/video/nvidia/nvidia.c