Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.
With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same way. This seems to agree with what register
dumps from the hpd storm handling code shows, where the LIVE bit and
the short/long pulse STATUS bits light up at the same time with this
enumeration (but no with the one from Bspec).
Also tested on my gm45 which has two DP+ ports, and everything seems
to still work as expected.
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
Cc: Egbert Eich <eich@suse.com>
Cc: Jan Niggemann <jn@hz6.de>
Tested-by: Jan Niggemann <jn@hz6.de>
[danvet: Add a big warning that Bspec seems to be wrong for these
bits, suggested by Jani.]
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
#define CRT_HOTPLUG_DETECT_VOLTAGE_475MV (1 << 2)
#define PORT_HOTPLUG_STAT (dev_priv->info->display_mmio_offset + 0x61114)
-/* HDMI/DP bits are gen4+ */
-#define PORTB_HOTPLUG_LIVE_STATUS (1 << 29)
+/*
+ * HDMI/DP bits are gen4+
+ *
+ * WARNING: Bspec for hpd status bits on gen4 seems to be completely confused.
+ * Please check the detailed lore in the commit message for for experimental
+ * evidence.
+ */
+#define PORTD_HOTPLUG_LIVE_STATUS (1 << 29)
#define PORTC_HOTPLUG_LIVE_STATUS (1 << 28)
-#define PORTD_HOTPLUG_LIVE_STATUS (1 << 27)
+#define PORTB_HOTPLUG_LIVE_STATUS (1 << 27)
#define PORTD_HOTPLUG_INT_STATUS (3 << 21)
#define PORTC_HOTPLUG_INT_STATUS (3 << 19)
#define PORTB_HOTPLUG_INT_STATUS (3 << 17)