diff options
author | Paul Mundt <lethal@linux-sh.org> | 2008-02-06 04:39:18 -0500 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2008-02-06 13:41:16 -0500 |
commit | 74f482cca5f76643e7f323e66cc38b1a882d5e6f (patch) | |
tree | 7b547bb4b139aa04983079359d4594b45a023af4 /drivers/video/uvesafb.c | |
parent | 2e9750272cd49732293b6fe771ae110be8d87273 (diff) |
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>
Diffstat (limited to 'drivers/video/uvesafb.c')
0 files changed, 0 insertions, 0 deletions