<div dir="ltr">Replies in between...<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 10:53 AM, Russell King - ARM Linux <span dir="ltr"><<a href="mailto:linux@armlinux.org.uk" target="_blank">linux@armlinux.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Tue, Nov 07, 2017 at 10:15:02AM +0000, Russell King - ARM Linux wrote:<br> > On Tue, Nov 07, 2017 at 10:00:48AM +0000, Luís Mendes wrote:<br> > > Hi Russell,<br> > ><br> > > Sorry for sending all these emails, but to me dw_hdmi device driver is<br> > > broken regarding HDMI detection and audio support. I don't want to waste<br> > > your time, but I would like to have your opinion since you're so involved<br> > > in the ARM support for the Linux kernel.<br> ><br> > If it is so broken, how come it works for me and others?<br> <br> </span>btw, if you do this without your edid firmware loaded:<br> <br> hexdump -C /sys/class/drm/card0-HDMI-A-1/<wbr>edid<br> <br> do you get any EDID? If so, then connector->edid_blob_ptr is populated<br> with the connector's EDID (see drivers/gpu/drm/drm_sysfs.c, edid_show()).<br> <br></blockquote><div>Actually no, I just get an empty output, however, xf86-video-armada gives:<br></div><div>[ 16.075] (**) armada(0): Option "DRI" "TRUE"<br>[ 16.078] (II) armada(0): Output HDMI1 has no monitor section<br>[ 16.079] (II) armada(0): EDID for output HDMI1<br>[ 16.079] (II) armada(0): Printing probed modes for output HDMI1<br>[ 16.079] (II) armada(0): Modeline "1920x1080"x60.0 172.78 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz)<br>[ 16.079] (II) armada(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)<br>[ 16.079] (II) armada(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)<br>[ 16.079] (II) armada(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e)<br>[ 16.079] (II) armada(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e)<br>[ 16.080] (II) armada(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)<br>[ 16.080] (II) armada(0): Output HDMI1 connected<br>[ 16.080] (II) armada(0): Using exact sizes for initial modes<br>[ 16.080] (II) armada(0): Output HDMI1 using initial mode 1024x768 +0+0<br>[ 16.080] (==) armada(0): Using gamma correction (1.0, 1.0, 1.0)<br><br></div><div> </div><div>and if I run:</div><div>#sudo get-edid > tv.edid<br></div><div>This is read-edid version 3.0.2. Prepare for some fun.<br>Attempting to use i2c interface<br>No EDID on bus 0<br>No EDID on bus 2<br>1 potential busses found: 1<br>256-byte EDID successfully retrieved from i2c bus 1<br>Looks like i2c was successful. Have a good day.<br></div><div><br></div><div>and then:</div><div>#parse-edid < tv.edid, I get:</div><div>Checksum Correct<br><br>Section "Monitor"<br> Identifier "22L11A-HD-AU"<br> ModelName "22L11A-HD-AU"<br> VendorName "KTC"<br> # Monitor Manufactured week 41 of 2011<br> # EDID version 1.3<br> # Digital Display<br> DisplaySize 480 270<br> Gamma 2.20<br> Option "DPMS" "false"<br> Horizsync 15-68<br> VertRefresh 49-61<br> # Maximum pixel clock is 150MHz<br> #Not giving standard mode: 1280x1024, 60Hz<br> #Not giving standard mode: 1600x900, 60Hz<br><br> #Extension block found. Parsing...<br> Modeline "Mode 16" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync <br> Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync <br> Modeline "Mode 1" 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync <br> Modeline "Mode 2" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync<br> Modeline "Mode 3" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync<br> Modeline "Mode 4" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync<br> Modeline "Mode 5" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync<br> Modeline "Mode 6" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace<br> Modeline "Mode 7" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace<br> Modeline "Mode 8" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync<br> Modeline "Mode 9" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync<br> Modeline "Mode 10" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace<br> Modeline "Mode 11" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace<br> Modeline "Mode 12" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync<br> Modeline "Mode 13" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace<br> Modeline "Mode 14" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace<br> Modeline "Mode 15" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync<br> Modeline "Mode 17" 74.25 1920 2008 2052 2200 540 542 547 562 +hsync +vsync interlace<br> Modeline "Mode 18" 74.25 1920 2448 2492 2640 540 542 547 562 +hsync +vsync interlace<br> Modeline "Mode 19" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync <br> Option "PreferredMode" "Mode 16"<br>EndSection</div><div><br></div><div>So from what I see xf86-video-armada is getting some default modes, because they do no match the ones obtained with get-edid.</div><div>However the I2C1 is properly configured and communicating because get-edid is able to get the data from the TV.</div><div><br></div><div>Relevant DTS file, prepared by Fabio, looks like this:</div><div>&hdmi {</div><div> ddc-i2c-bus = <&i2c1>;</div><div> status = "okay";<br></div><div>}<br></div><div><br></div><div>&i2c1 {</div><div> clock-frequency = <100000>;</div><div> pinctrl-names = "default"</div><div> pinctrl-0 = <&pinctrl_i2c1>;</div><div> status = "okay";</div><div>}</div><div><br></div><div>pinctrl_i2c1: i2c1grp {</div><div> fsl,pins = <</div><div> MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1</div><div> MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1</div><div> >;</div><div>};</div><div><br></div><div>So somehow dw_hdmi is falling to retrieve the EDID data, but the get-edid user mode app. is able to retrieve it....<br></div><div><br></div><div>#uname -a<br>Linux picolo.pcnet 4.14.0-rc5 #12 SMP Tue Nov 7 08:34:41 WET 2017 armv7l armv7l armv7l GNU/Linux<br><br></div><div>#hexdump -C tv.edid <br>00000000 00 ff ff ff ff ff ff 00 2e 83 54 21 34 00 00 00 |..........T!4...|<br>00000010 29 15 01 03 80 30 1b 78 0a f0 65 98 57 51 91 27 |)....0.x..e.WQ.'|<br>00000020 21 50 54 21 08 00 81 80 a9 c0 01 01 01 01 01 01 |!PT!............|<br>00000030 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c |.......:..q8-@X,|<br>00000040 45 00 dc 0c 11 00 00 1e 66 21 50 b0 51 00 1b 30 |E.......f!P.Q..0|<br>00000050 40 70 36 00 dc 0c 11 00 00 1e 00 00 00 fc 00 32 |@p6............2|<br>00000060 32 4c 31 31 41 2d 48 44 2d 41 55 0a 00 00 00 fd |2L11A-HD-AU.....|<br>00000070 00 31 3d 0f 44 0f 00 0a 20 20 20 20 20 20 01 15 |.1=.D... ..|<br>00000080 02 03 21 73 4e 84 93 10 1f 05 14 03 12 07 16 02 |..!sN...........|<br>00000090 06 15 11 23 09 0f 07 83 01 00 00 65 03 0c 00 10 |...#.......e....|<br>000000a0 00 01 1d 00 bc 52 d0 1e 20 b8 28 55 40 c4 8e 21 |.....R.. .(U@..!|<br>000000b0 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 c4 |.......q.. X,%..|<br>000000c0 8e 21 00 00 9e 01 1d 80 d0 72 1c 16 20 10 2c 25 |.!.......r.. .,%|<br>000000d0 80 c4 8e 21 00 00 9e 8c 0a d0 8a 20 e0 2d 10 10 |...!....... .-..|<br>000000e0 3e 96 00 c4 8e 21 00 00 18 01 1d 00 72 51 d0 1e |>....!......rQ..|<br>000000f0 20 6e 28 55 00 c4 8e 21 00 00 1e 00 00 00 00 72 | n(U...!.......r|<br>00000100</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The only place that sets that is drm_mode_connector_update_<wbr>edid_property().<br> That is called when loading a firmware edid for the connector, or by<br> dw-hdmi inside dw_hdmi_connector_get_modes().<br> <br> So, if you have no firmware edid, and you get EDID from the above file,<br> then that can only have come from dw-hdmi successfully reading the EDID<br> from the connected device.<br> <br> Here's an example, with a Samsung S24C750 monitor attached:<br> <br> root@hbi2ex:~/xf86-video-<wbr>armada-0.0.0# uname -a<br> Linux hbi2ex 4.14.0-rc1+ #2214 SMP Wed Oct 25 10:51:58 BST 2017 armv7l armv7l armv7l GNU/Linux<br> root@hbi2ex:~/xf86-video-<wbr>armada-0.0.0# hexdump -C /sys/class/drm/card0-HDMI-A-1/<wbr>edid<br> 00000000 00 ff ff ff ff ff ff 00 4c 2d 5d 0a 41 5a 58 5a |........L-].AZXZ|<br> 00000010 1e 17 01 03 80 35 1e 78 2a f7 11 a3 56 4f 9e 28 |.....5.x*...VO.(|<br> 00000020 0f 50 54 bf ef 80 71 4f 81 c0 81 00 81 80 95 00 |.PT...qO........|<br> 00000030 a9 c0 b3 00 01 01 02 3a 80 18 71 38 2d 40 58 2c |.......:..q8-@X,|<br> 00000040 45 00 13 2b 21 00 00 1e 01 1d 00 72 51 d0 1e 20 |E..+!......rQ.. |<br> 00000050 6e 28 55 00 13 2b 21 00 00 1e 00 00 00 fd 00 32 |n(U..+!........2|<br> 00000060 4b 1e 51 11 00 0a 20 20 20 20 20 20 00 00 00 fc |K.Q... ....|<br> 00000070 00 53 32 34 43 37 35 30 0a 20 20 20 20 20 01 74 |.S24C750. .t|<br> 00000080 02 03 1a f1 46 90 04 1f 13 03 12 23 09 07 07 83 |....F......#....|<br> 00000090 01 00 00 66 03 0c 00 20 00 80 01 1d 00 bc 52 d0 |...f... ......R.|<br> 000000a0 1e 20 b8 28 55 40 13 2b 21 00 00 1e 8c 0a d0 90 |. .(U@.+!.......|<br> 000000b0 20 40 31 20 0c 40 55 00 13 2b 21 00 00 18 8c 0a | @1 .@U..+!.....|<br> 000000c0 d0 8a 20 e0 2d 10 10 3e 96 00 13 2b 21 00 00 18 |.. .-..>...+!...|<br> 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br> *<br> 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 89 |................|<br> 00000100<br> <br> I can assure you that this has been the case for every 4.x kernel<br> version - I've booted them all on several imx6 platforms. One<br> imx6 platform is permanently connected to AV2 on my TV, and it<br> always finds the EDID for the TV.<br> <br> So, I think there is something going on which is interfering with<br> the ability for the i2c driver to get the EDID from your TV - it<br> fails a number of times, but I think eventually it does succeed.<br> Maybe it gets the first page (128 bytes) of EDID which contains<br> the basic information, but fails to get the second page which<br> contains the HDMI vendor block along with all the audio information.<br></blockquote><div> </div><div>Yes, something has to be wrong somewhere, but it looks like configuration or kernel driver problem. <br></div><div>If it was the hardware then get-edid shouldn't be able to retrieve the EDID.</div><div>I've to dig a bit deeper to see what I can find.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> That basically means there's something wrong with the I2C/DDC bus.<br> Maybe the clock rate is too fast (DDC is 100kHz, not 400kHz).<br> Maybe the pull-ups are wrong. Maybe the board has wrong pull-ups.<br> Could be many things.<br> <div class="gmail-HOEnZb"><div class="gmail-h5"><br> --<br> RMK's Patch system: <a href="http://www.armlinux.org.uk/developer/patches/" rel="noreferrer" target="_blank">http://www.armlinux.org.uk/<wbr>developer/patches/</a><br> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up<br> According to <a href="http://speedtest.net" rel="noreferrer" target="_blank">speedtest.net</a>: 8.21Mbps down 510kbps up<br> </div></div></blockquote></div><br></div></div>