Are we sure this isn't our bug? It looks like the rom Dmitry posted has a mostly correct modeline:
* panel type 02: 800x480 clock 27000000 info: LVDS: 0x40000300 PP_ON_DELAYS: 0x025907d1 PP_OFF_DELAYS: 0x01f507d1 PP_DIVISOR: 0x00270f05 PFIT: 0x00000668 timings: 800 808 904 900 480 482 484 500 27000.00 (BAD!)
only the vtotal vs vsyncend is broken (as we've seen before). The mode pointer table is busted though:
LVDS timing pointer data:
Number of entries: 3
panel type 02: 0x3072
It sounds like the EDID might be broken, but we're trying to use it anyway? What happens if we just use the VBT mode unconditionally, rather than assuming the EDID data is right?
Maybe once we get more VBIOS info we'll be able to figure out what data to trust better...
Are we sure this isn't our bug? It looks like the rom Dmitry posted has a mostly correct modeline:
info:
LVDS: 0x40000300
PP_ ON_DELAYS: 0x025907d1
PP_ OFF_DELAYS: 0x01f507d1
PP_ DIVISOR: 0x00270f05
PFIT: 0x00000668
timings: 800 808 904 900 480 482 484 500 27000.00 (BAD!)
* panel type 02: 800x480 clock 27000000
only the vtotal vs vsyncend is broken (as we've seen before). The mode pointer table is busted though:
LVDS timing pointer data:
Number of entries: 3
panel type 02: 0x3072
It sounds like the EDID might be broken, but we're trying to use it anyway? What happens if we just use the VBT mode unconditionally, rather than assuming the EDID data is right?
Maybe once we get more VBIOS info we'll be able to figure out what data to trust better...