i2c support for edid on armel

Hi David,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/daily/current/ . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 608279

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I was able to read the EDID without any kernel modification:

mpoirier@beagle:~$ uname -a
Linux beagle 2.6.35-15-omap #22 Thu Aug 12 16:23:35 EDT 2010 armv7l GNU/Linux
mpoirier@beagle:~$
mpoirier@beagle:~$ sudo apt-get install i2c-tools
mpoirier@beagle:~$
mpoirier@beagle:~$ sudo modprove i2c-dev
mpoirier@beagle:~$
mpoirier@beagle:~$ sudo i2cdump -y 3 0x50
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 10 ac 28 d0 4c 4e 38 32 ........??(?LN82
10: 31 13 01 03 80 33 1d 78 2e ee 95 a3 54 4c 99 26 1????3?x.???TL?&
20: 0f 50 54 a5 4b 00 71 4f 81 80 d1 c0 01 01 01 01 ?PT?K.qO????????
30: 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c ???????:??q8-@X,
40: 45 00 fd 1e 11 00 00 1e 00 00 00 ff 00 4e 39 31 E.???..?.....N91
50: 38 52 39 43 32 32 38 4e 4c 0a 00 00 00 fc 00 44 8R9C228NL?...?.D
60: 45 4c 4c 20 50 32 33 31 30 48 0a 20 00 00 00 fd ELL P2310H? ...?
70: 00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 80 .8L?S?.? .?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
mpoirier@beagle:~$

I have a Dell P2310H, something that can be found starting at address 0x5F.

Can confirm that it works OK:

root@beagle-maverick:~# i2cdump -y 3 0x50
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 1e 6d dc 56 01 01 01 01 ........?m?V????
10: 03 14 01 03 80 31 20 78 ea ee 91 a3 54 4c 99 26 ?????1 x????TL?&
20: 0f 50 54 a7 6b 80 b3 00 81 80 81 8f 71 4f 01 01 ?PT?k??.????qO??
30: 01 01 01 01 01 01 1a 36 80 a0 70 38 1f 40 30 20 ???????6??p8?@0
40: 35 00 fe 22 11 00 00 1e 02 3a 80 18 71 38 2d 40 5.?"?..??:??q8-@
50: 58 2c 45 00 fe 22 11 00 00 1c 00 00 00 fd 00 38 X,E.?"?..?...?.8
60: 4b 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc K?S?.? ...?
70: 00 57 32 32 35 33 0a 20 20 20 20 20 20 20 00 87 .W2253? .?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

Mine is a LG W2253.

could one of you pass that through parse-edid (from the read-edid package) to make sure the hex data is actually a valid EDID table ?

parse-edid demands binary date, something i2cdump doesn't provide.

I added an additional 'i2c_board_info' structure and tied it to the i2c 'eeprom' driver, which creates the following /sys/bus/i2c/devices/3-0050/eeprom entry. From there using 'decode-edid' specifying to scan bus 3 is trivial. Note that decode-edid calls parse-edid.

mpoirier@beagle:~$ sudo modprobe eeprom
mpoirier@beagle:~$ decode-edid 3
decode-edid: decode-edid version 1.1
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:ff
        # Block type: 2:0 3:fc
        Identifier "DELL P2310H"
        VendorName "DEL"
        ModelName "DELL P2310H"
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        HorizSync 30-83
        VertRefresh 56-76
        # Max dot clock (video bandwidth) 170 MHz
        # DPMS capabilities: Active off:yes Suspend:no Standby:no

        Mode "1920x1080" # vfreq 60.000Hz, hfreq 67.500kHz
                DotClock 148.500000
                HTimings 1920 2008 2052 2200
                VTimings 1080 1084 1089 1125
                Flags "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:ff
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
EndSection
mpoirier@beagle:~$

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@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).

This bug was fixed in the package linux - 2.6.35-19.25

---------------
linux (2.6.35-19.25) maverick; urgency=low

  [ Jarod Wilson ]

  * SAUCE: Bring in staging/lirc from 2.6.36
    - LP: #609234
  * SAUCE: Update ir-core to linuxtv/other which should be merged for
    2.6.36.
    - LP: #609234
  * SAUCE: Fix memleaks in imon and mceusb drivers
    - LP: #609234
  * SAUCE: Bring in streamzap support from linuxtv/other
    - LP: #609234

  [ Mario Limonciello ]

  * Remove ubuntu/lirc in favor of staging/lirc from 2.6.36
    - LP: #609234

  [ Mathieu J. Poirier ]

  * SAUCE: ARM: adding i2c eeprom driver to read EDID
    - LP: #608279

  [ Upstream Kernel Changes ]

  * intel_idle: disable module support
    - LP: #615265
  * (pre-stable) ALSA: hda - Ensure codec patch files are checked for the
    correct codec ID
  * (pre-stable) ALSA: hda - Rename iMic to Int Mic on Lenovo NB0763
    - LP: #605101
  * (pre-stable) ALSA: HDA: Use model=auto for LG R510
    - LP: #495134
  * (pre-stable) ALSA: HDA: Add Sony VAIO quirk for ALC269
    - LP: #519066
  * (pre-stable) ALSA: HDA: Fix front mic on Dell Precision M6500
    - LP: #519066
  * input: mt: Initialize slots to unused (rev2)
  * input: mt: Add support for the Bamboo Touch trackpad
  * hid: Add a hid quirk for input sync override
 -- Leann Ogasawara <email address hidden> Mon, 23 Aug 2010 12:42:52 -0700

   It’s your time for an education!
A big distance is between a first class till the final exam. Isn’t?
We are here to make your way shorter.
We know that’s something you can’t find around the corner.
It is an EDUCATION! You can find it right here.
Get free info! Call us and you will get professional help in choosing right option for you!
The secret of our popularity is the quality, responsibility and respect.
PhD, Master, Bachelor
2-4 weeks and you are graduated.

-----------

+ 1 - 646 - 537 - 1732

-----------

Please leave us the infarmation:
1) Your Name
2) Your Country
3) Telephone No. with country code if you are outside USA
Please Do Not Reply to this Email.
We do not reply to text inquiries, and our server will reject all response traffic.
We apologize for any inconvenience this may have caused you.