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