When using HDMI-DVI converter, no video output is visible on many monitor models. The issue is root caused to the GOP driver programmed the HDMI port to drive null packet does not work in a DVI panel which has a VSYNC. Disabling NULL packets during VSync appears to fix the issue while preserving compatibility with HDMI (including HDMI Audio - verified on 2 different HDMI monitors). So the request is to change GOP driver to disable NULL-packets during VSync. 14.11.26 SDVOHDMIB—Offset 61140h Digital Display Port B Control Register HDMIB port control (dprrega.v sdvo_bQ) 9 0b RW NULL_PACKETS_ENABLED_DURING_VSYNC: This bit enables a null packet (32 bytes of a value of 0) to be sent when Vsync=1 on this port, required for HDMI operation. It also enables preambles and guardbands prior to the null packets, in accordance with the HDMI specification. It is only valid for modes that use TMDS encoding. 0 = Disable null infoframe packets when Vsync=1 on this port. (Default) 1 = Enable null infoframe packets when Vsync=1 on this port
Possibly related to Bug 6485
The workaround was implemented but fix in GOP driver is still required in order to remove the workaround.
I verified that the following audio test works with the 8/13 firmware image: $ speaker-test -t sine -f 1000 -d plughw:0,3
I've verified Audio from Windows Media Player and it works fine with the workaround fix.
Adding another monitor model to the mix...I have my old Acer AL1917W monitor reporting "Input not supported" while connected to my Max Rev. A1. I'm connected via micro HDMI to female full HDMI adapter and a male full HDMI to DVI-D cable. This is a DVI-D/VGA only monitor so I can't verify that native HDMI might work.
Closed through work around. still awaiting a new GOP driver, but for now the work around is functional.
I'm not finding the workaround documented here or in Bug 6485, can someone post that here so Matt can try it in his scenario?
Matt, this workaround is available in the 8/13 firmware. As I understand it, you were running the latest firmware and collected what appeared to be a corrupted EDID?
Created attachment 2124 [details] AL1917W EDID dump Raw EDID dump from my monitor that doesn't work with the 8/13 firmware.
Darren, I'm running MNW2CRB1_X64_RELEASE_2014_08_13_1301.bin. I didn't look at the EDID closely to see if it was valid. I know Dave Anders mentioned that he would run it through his validation process and perhaps he confirmed it was corrupt, I'm not sure. I attached the EDID dump.
From: Wei, David Sent: Thursday, August 07, 2014 11:01 PM To: Rouzanov, Ivan; Krau, Michael P; He, Tim; Wu, Mike; Li, Kevin Y Subject: RE: Request Fix for HDMI-DVI converter Got it. But it should be 0x90000000 + 180000h + 61140h = 0x901e1140 . Microsoft got the correct address. From: Rouzanov, Ivan Sent: Friday, August 08, 2014 1:58 PM To: Wei, David; Krau, Michael P; He, Tim; Wu, Mike; Li, Kevin Y Subject: RE: Request Fix for HDMI-DVI converter I mean 2BF20h is incorrect, it should be 180000h: SDVOHDMIB: [GTTMMADR_LSB + 180000h h] + 61140h = 0x90000000 +180000h 61140h = 90241140 >>> +++++ irouzano 7/25/2014 3:45:34 PM Consistently across the display register documentation states that there is an additional offset of “0x2BF20” that needs to be added to access the display controller register. Here is an example on page 787: 14.11.277 SPACNTR—Offset 72180h Sprite A Control Register SPACNTR: [GTTMMADR_LSB + 2BF20h] + 72180h The actual offset value that need to be throughout is 180000h. So everywhere offset 2BF20h has to be replaced with 180000h. This appears to be conversion error - 180000 if treated as decimal becomes 2BF20h, however the correct offset is 180000h >>> From: Rouzanov, Ivan Sent: Thursday, August 07, 2014 10:55 PM To: Wei, David; Krau, Michael P; He, Tim; Wu, Mike; Li, Kevin Y Subject: RE: Request Fix for HDMI-DVI converter This is a bug in documentation, the correct offset is 180000h. HSD is filed: https://vthsd.intel.com/hsd/ebaytrail/sighting/default.aspx?sighting_id=4994662 From: Wei, David Sent: Thursday, August 07, 2014 10:52 PM To: Krau, Michael P; He, Tim; Wu, Mike; Li, Kevin Y Cc: Rouzanov, Ivan; Wei, David Subject: RE: Request Fix for HDMI-DVI converter I do not know how Micorsoft calculate the address of SDVOHDMIB. But according to following formula and the alignment requirement (4GB alignment) of GTTMMADR, we cannot get the GTTMMADR address value 0x901e1140 that Microsoft got. SDVOHDMIB: [GTTMMADR_LSB + 2BF20h] + 61140h Most of the time GTTMMADR is configured to be 0x90000000 by our PCI bus driver dynamically, so the SDVOHDMIB address should be 0x9008D060. Then I checked register 0x901e1140, it did have the value looks like Microsoft got. Shell> mm 901e1140 -w 4 MEM 0x00000000901E1140 : 0x80000A0C > So I guess Microsoft is talking about 0x901e1140, which is another register, not SDVOHDMIB. To make sure today’s image drop work with DVI, I will clean bit 9 of both above registers. Thanks, David
This was intended to be used as a tracking bug to monitor that the GOP driver was updated, and it's not clear that the GOP driver was updated to include this fix. If it has, please indicate the date / version when the provided GOP driver contained this fix, and the work-around reverted
Using 0.75 pre-release version: I wasn't sure which bit I'm supposed to be looking at, so here are the two registers I've seen listed in the bug: Shell> mm 901e1140 -w 4 MEM 0x00000000901E1140 : 0x0000081C > MEM 0x00000000901E1144 : 0x00000000 > q Shell> mm 9008D060 -w 4 MEM 0x000000009008D060 : 0x00000000 > MEM 0x000000009008D064 : 0x00000000 > q
Of the two, Shell> mm 901e1140 -w 4 MEM 0x00000000901E1140 : 0x0000081C > MEM 0x00000000901E1144 : 0x00000000 > q is the important one. I believe the correct value is Bit 9 clear so: 0x00000A1C Would be incorrect, and the corrected value should be: 0x0000081C
So this would suggest that the bit is set properly, despite the display not coming up in firmware? I will attempt to flash with a previous image and see if the display works (having trouble with my SPI flasher though).
Hi Darren, The actual address could be calculate out by following way: [GTTMMADR + 180000h h] + 61140h (GTTMMADR is one of the PCI BARs of IGD, which is supposed to be dynamically assigned a address) Typically, if Minnow Max board is under default configuration(no expansion card is plugged on Minnow Max), GTTMMADR would be assigned to be 0x90000000. So we could get following address: 0x90000000 + 180000h + 61140h = 0x901e1140 . But I suggest you read out GTTMMADR first and then calculate it.
I did a quick confirm the register (901e1140 ) value under uefi shell. Shell> mm 901e1140 -w 4 MEM 0x00000000901E1140 : 0x8000080C > MEM 0x00000000901E1144 : 0x00000000 > q Shell> Which above means that the bit9 have been cleared to 0.
I have verified that the latest GOP driver ( Revision: 7.2.1011 ) can already support HDMI-DVI converter. The register (901e1140 ) value under uefi shell : Shell> mm 901e1140 -w 4 MEM 0x00000000901E1140 : 0x8000081C Bit 9 have cleared.
Created attachment 2265 [details] GOP test image Attachment is the test image with new GOP driver 7.2.1011 which support HDMI-DVI converter and workaround has been removed already.
0.76 (preview) does work, seemingly without the work-around (as it has the new GOP driver). Once 0.76 is released this can be closed. We'll track the newly discovered hardware problem in bug #7027
0.76 released http://firmware.intel.com/projects/minnowboard-max this bug is complete.