[Bug 608279] Re: i2c support for edid on armel

[Ricardo Salveti]

Nice that you got this working.

Regarding the subject, maybe this is not the correct place to discuss,
but the main problem I believe is to know what should be the best and
more standard way to use the EDID information and set the correct
monitor output.

Currently for Omap 4 the EDID parsing happens inside the display driver, and it tries to set up everything so you don't need to specify any display argument at the boot cmd line. Even with all this logic, robclark created an entry at the sysfs so you could probe it:
ubuntu at panda-maverick-usb:~$ parse-edid /sys/devices/omapdss/display0/edid
parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
        Identifier "W2253"
        VendorName "GSM"
        ModelName "W2253"
        # Block type: 2:0 3:fd
        HorizSync 30-83
        VertRefresh 56-61
        # Max dot clock (video bandwidth) 150 MHz
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:no  Suspend:no  Standby:no

        Mode    "1920x1080"     # vfreq 59.934Hz, hfreq 66.587kHz
                DotClock        138.500000
                HTimings        1920 1968 2000 2080
                VTimings        1080 1083 1088 1111
                Flags   "+HSync" "+VSync"
        EndMode
        Mode    "1920x1080"     # vfreq 60.000Hz, hfreq 67.500kHz
                DotClock        148.500000
                HTimings        1920 2003 2047 2200
                VTimings        1080 1084 1089 1125
                Flags   "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fd
        # Block type: 2:0 3:fc
EndSection

This week we had one thread about what should be the default resolution
for BeagleBoard xM validation, that you can find at
http://groups.google.com/group/beagleboard/browse_thread/thread/229d7dd3ff4447d8.
For them there could be two options, one is to probe i2c and parse the
edid at the boot loader and the other is to change the kernel code in
order to probe and detect it correctly, like what we have for Omap 4.
For the second option there is a quite old patch at
http://groups.google.com/group/beagleboard/browse_thread/thread/5274e1527067d88e/bd988bdaa65b7d58,
that was sent last year.

As you demonstrated, changing the kernel to probe the EDID from eeprom
works, and it would fit our blueprint (that sets up the correct
resolution just after the second boot), but looking forward, what should
be the best way to implement this?

Doing like Omap 4 sounds more correct, but needs a lot of work. Another
solution would move this to u-boot, as it'd help us from the first boot
and affect a wider audience (beagle, OE, etc).

-- 
i2c support for edid on armel
https://bugs.launchpad.net/bugs/608279
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.