* [PATCH 1/5] drm/edid: Add 6 bpc quirk for display AEO model 0.
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
@ 2016-07-06 10:05 ` Mario Kleiner
2016-07-06 10:05 ` [PATCH 2/5] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown" Mario Kleiner
` (4 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: Mario Kleiner @ 2016-07-06 10:05 UTC (permalink / raw)
To: dri-devel; +Cc: Jani Nikula, Daniel Vetter, stable
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.
A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.
The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.
Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.
Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.
This patch should be backported to stable.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_edid.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7df26d4..2cb472b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -74,6 +74,8 @@
#define EDID_QUIRK_FORCE_8BPC (1 << 8)
/* Force 12bpc */
#define EDID_QUIRK_FORCE_12BPC (1 << 9)
+/* Force 6bpc */
+#define EDID_QUIRK_FORCE_6BPC (1 << 10)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -100,6 +102,9 @@ static struct edid_quirk {
/* Unknown Acer */
{ "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
+ /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
+ { "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
@@ -4082,6 +4087,9 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
drm_add_display_info(edid, &connector->display_info, connector);
+ if (quirks & EDID_QUIRK_FORCE_6BPC)
+ connector->display_info.bpc = 6;
+
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
--
2.7.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 2/5] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
2016-07-06 10:05 ` [PATCH 1/5] drm/edid: Add 6 bpc quirk for display AEO model 0 Mario Kleiner
@ 2016-07-06 10:05 ` Mario Kleiner
2016-07-06 10:05 ` [PATCH 3/5] drm/dp: Add helper to find bpc of a connected DP sink Mario Kleiner
` (3 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: Mario Kleiner @ 2016-07-06 10:05 UTC (permalink / raw)
To: dri-devel; +Cc: Daniel Vetter, stable
This reverts commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.
Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.
The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.
DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.
Please backport to stable.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/intel_display.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0b2cd66..c7854f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12212,21 +12212,11 @@ connected_sink_compute_bpp(struct intel_connector *connector,
pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
}
- /* Clamp bpp to default limit on screens without EDID 1.4 */
- if (connector->base.display_info.bpc == 0) {
- int type = connector->base.connector_type;
- int clamp_bpp = 24;
-
- /* Fall back to 18 bpp when DP sink capability is unknown. */
- if (type == DRM_MODE_CONNECTOR_DisplayPort ||
- type == DRM_MODE_CONNECTOR_eDP)
- clamp_bpp = 18;
-
- if (bpp > clamp_bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of %d\n",
- bpp, clamp_bpp);
- pipe_config->pipe_bpp = clamp_bpp;
- }
+ /* Clamp bpp to 8 on screens without EDID 1.4 */
+ if (connector->base.display_info.bpc == 0 && bpp > 24) {
+ DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of 24\n",
+ bpp);
+ pipe_config->pipe_bpp = 24;
}
}
--
2.7.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 3/5] drm/dp: Add helper to find bpc of a connected DP sink.
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
2016-07-06 10:05 ` [PATCH 1/5] drm/edid: Add 6 bpc quirk for display AEO model 0 Mario Kleiner
2016-07-06 10:05 ` [PATCH 2/5] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown" Mario Kleiner
@ 2016-07-06 10:05 ` Mario Kleiner
2016-07-06 10:05 ` [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell Mario Kleiner
` (2 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: Mario Kleiner @ 2016-07-06 10:05 UTC (permalink / raw)
To: dri-devel; +Cc: Jani Nikula, Daniel Vetter
drm_dp_sink_bpc() is meant as a fallback to be used by
kms drivers if a DP sink doesn't provide supported color
depth bpc via EDID.
It parses dpcd registers and optionally downstream port
registers read by the driver from DP AUX and passed to
the function to find out what the bpc of the connected
sink likely is.
For a DP sink without downstream ports it assumes it is a
native DP display sink and applies the 6 bpc / 18 bpp
fallback as required by the DP spec.
For a DP sink with downstream ports, e.g., a DP -> legacy
converter it makes the following assignment:
If the converter is DP->DVI or DP->HDMI, it assumes 8 bpc
depth. If the converter is DP->VGA it assumes at least
8 bpc, but tries to get a more accurate value (8, 10, 12
or 16 bpc) if the converter exposes this info.
Tested with MiniDP->DP adapter, MiniDP->HDMI adapter,
MiniDP->single-link DVI adapter, MiniDP->dual-link DVI
active adapter, and a Apple MiniDP->VGA active adapter.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/drm_dp_helper.c | 90 +++++++++++++++++++++++++++++++++++++++++
include/drm/drm_dp_helper.h | 6 +++
2 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 091053e..2cf0289 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -160,6 +160,96 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
}
EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
+/**
+ * drm_dp_sink_bpc - Parse dpcd to derive bpc of a DP sink.
+ *
+ * @dpcd: dpcd registers, starting at offset 0
+ * @downstream_ports: downstream port info registers, starting at
+ * offset DP_DOWNSTREAM_PORT_0
+ * @index: Index of the downstream port to query
+ *
+ * Derive color depth bpc of the connected DP sink. This is meant as
+ * a fallback for getting the sink bpc if the DP sink doesn't provide
+ * a useable bpc via EDID. It returns 6 bpc for a native DP sink
+ * without any downstream ports, as the spec mandates to assume 6 bpc
+ * if the true bpc of a native DP sink can't be found out from EDID.
+ *
+ * If the sink has multiple downstream ports then @index selects the
+ * downstream port to query, otherwise the first and only one is
+ * queried.
+ *
+ * The function can return 0 to signal that it can't derive bpc from the
+ * given information.
+ */
+int drm_dp_sink_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS],
+ unsigned int index)
+{
+ uint8_t type;
+ bool detail = false;
+ int bpc = 0;
+
+ /*
+ * If there isn't any downstream port then this is a native DP sink.
+ * The standard requires to fall back to 6 bpc / 18 bpp for native DP
+ * sinks which don't provide bit depth via EDID.
+ */
+ if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+ return 6;
+
+ /* Basic type of downstream ports? */
+ type = dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_TYPE_MASK;
+
+ /*
+ * Lacking other info, 8 bpc is a reasonable start for analog out.
+ * E.g., Apple MiniDP->VGA adaptors don't provide more info than
+ * that. Despite having DP_DPCD_REV == 0x11, their downstream_ports
+ * descriptor is empty - all zeros. DVI and HDMI also support at least
+ * 8 bpc, so a TMDS port type also implies 8 bpc.
+ */
+ if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
+ type == DP_DWN_STRM_PORT_TYPE_TMDS)
+ bpc = 8;
+
+ if (dpcd[DP_DPCD_REV] < 0x11)
+ return bpc;
+
+ /* Rev 1.1+. More specific info available per downstream port. */
+
+ /* Detailed info of 4 Bytes per downstream port available? */
+ if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) {
+ index *= 4;
+ detail = true;
+ }
+
+ type = downstream_ports[index] & DP_DS_PORT_TYPE_MASK;
+
+ /* VGA, DVI and HDMI support at least 8 bpc */
+ if (type == DP_DS_PORT_TYPE_VGA || type == DP_DS_PORT_TYPE_DVI ||
+ type == DP_DS_PORT_TYPE_HDMI)
+ bpc = 8;
+
+ /* As of DP interop v1.1a only VGA defines additional detail */
+ if (detail && (type == DP_DS_PORT_TYPE_VGA)) {
+ /* VGA with detail provides bpc info */
+ switch (downstream_ports[index + 2] &
+ DP_DS_VGA_MAX_BPC_MASK) {
+ default:
+ case DP_DS_VGA_8BPC:
+ return 8;
+ case DP_DS_VGA_10BPC:
+ return 10;
+ case DP_DS_VGA_12BPC:
+ return 12;
+ case DP_DS_VGA_16BPC:
+ return 16;
+ }
+ }
+
+ return bpc;
+}
+EXPORT_SYMBOL(drm_dp_sink_bpc);
+
#define AUX_RETRY_INTERVAL 500 /* us */
/**
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4d85cf2..0737cd0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -203,6 +203,8 @@
* DP interop v1.1a only VGA defines additional detail.
*/
+#define DP_MAX_DOWNSTREAM_PORTS 0x10
+
/* offset 0 */
#define DP_DOWNSTREAM_PORT_0 0x80
# define DP_DS_PORT_TYPE_MASK (7 << 0)
@@ -630,6 +632,10 @@ void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
u8 drm_dp_link_rate_to_bw_code(int link_rate);
int drm_dp_bw_code_to_link_rate(u8 link_bw);
+int drm_dp_sink_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS],
+ unsigned int index);
+
struct edp_sdp_header {
u8 HB0; /* Secondary Data Packet ID */
u8 HB1; /* Secondary Data Packet Type */
--
2.7.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
` (2 preceding siblings ...)
2016-07-06 10:05 ` [PATCH 3/5] drm/dp: Add helper to find bpc of a connected DP sink Mario Kleiner
@ 2016-07-06 10:05 ` Mario Kleiner
2016-08-03 3:07 ` Dave Airlie
2016-07-06 10:05 ` [PATCH 5/5] drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS" Mario Kleiner
2016-07-30 15:08 ` Fwd: EDID/DP fixes for proper bpc detection of displays Mario Kleiner
5 siblings, 1 reply; 12+ messages in thread
From: Mario Kleiner @ 2016-07-06 10:05 UTC (permalink / raw)
To: dri-devel; +Cc: Jani Nikula, Daniel Vetter
For DP sinks which don't expose color depth via EDID, use
the drm_dp_sink_bpc() helper to derive the bpc of the sink.
This should handle DP native sinks with the "Assume 6 bpc if EDID
doesn't tell us" as mandated by DP spec. It gives more accurate
values for DP->legacy converters for HDMI, DVI and VGA.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 26 +++++++++++++++++++++-----
drivers/gpu/drm/i915/intel_dp.c | 7 +++++++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index c7854f4..1a5287f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12212,11 +12212,27 @@ connected_sink_compute_bpp(struct intel_connector *connector,
pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (connector->base.display_info.bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ /* Clamp bpp to default limit on screens without EDID 1.4 */
+ if (connector->base.display_info.bpc == 0) {
+ int type = connector->base.connector_type;
+ int clamp_bpp = 24;
+
+ /* On DisplayPort try harder to find sink bpc */
+ if (type == DRM_MODE_CONNECTOR_DisplayPort ||
+ type == DRM_MODE_CONNECTOR_eDP) {
+ int sink_bpc = intel_dp_sink_bpc(&connector->base);
+
+ if (sink_bpc) {
+ DRM_DEBUG_KMS("DP sink with bpc %d\n", sink_bpc);
+ clamp_bpp = 3 * sink_bpc;
+ }
+ }
+
+ if (bpp > clamp_bpp) {
+ DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of %d\n",
+ bpp, clamp_bpp);
+ pipe_config->pipe_bpp = clamp_bpp;
+ }
}
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ffa43ec..d8dab0b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5689,3 +5689,10 @@ void intel_dp_mst_resume(struct drm_device *dev)
}
}
}
+
+/* XXX Only supports up to 1 downstream port atm. */
+int intel_dp_sink_bpc(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ return drm_dp_sink_bpc(intel_dp->dpcd, intel_dp->downstream_ports, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 089a425..e8feac1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1335,6 +1335,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp);
void intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connector);
void intel_dp_mst_suspend(struct drm_device *dev);
void intel_dp_mst_resume(struct drm_device *dev);
+int intel_dp_sink_bpc(struct drm_connector *connector);
int intel_dp_max_link_rate(struct intel_dp *intel_dp);
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
void intel_dp_hot_plug(struct intel_encoder *intel_encoder);
--
2.7.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.
2016-07-06 10:05 ` [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell Mario Kleiner
@ 2016-08-03 3:07 ` Dave Airlie
2016-08-03 6:09 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Dave Airlie @ 2016-08-03 3:07 UTC (permalink / raw)
To: Mario Kleiner; +Cc: Jani Nikula, Daniel Vetter, dri-devel
On 6 July 2016 at 20:05, Mario Kleiner <mario.kleiner.de@gmail.com> wrote:
> For DP sinks which don't expose color depth via EDID, use
> the drm_dp_sink_bpc() helper to derive the bpc of the sink.
>
> This should handle DP native sinks with the "Assume 6 bpc if EDID
> doesn't tell us" as mandated by DP spec. It gives more accurate
> values for DP->legacy converters for HDMI, DVI and VGA.
Haswell says no.
ug 03 12:58:46 tyrion-bne-redhat-com kernel: fbcon: inteldrmfb (fb0)
is primary device
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: BUG: unable to handle
kernel NULL pointer dereference at 000000000000011b
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: IP: [<ffffffffa00e6cf5>]
drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: PGD 0
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Oops: 0000 [#1] SMP
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Modules linked in: i915
ccm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun
ip6t_rpfilter ip6t_
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: videobuf2_core
snd_hda_codec videodev mei_me mei snd_hwdep snd_seq snd_hda_core
rtsx_pci media i2c_i
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CPU: 1 PID: 752 Comm:
kworker/1:3 Not tainted 4.7.0+ #12
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Hardware name: LENOVO
20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Workqueue: events_long
drm_dp_mst_link_probe_work [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: task: ffff880308583a80
task.stack: ffff880309f20000
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP:
0010:[<ffffffffa00e6cf5>] [<ffffffffa00e6cf5>]
drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP:
0018:ffff880309f23b48 EFLAGS: 00010202
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RAX: 000000000000000a
RBX: 0000000000000006 RCX: 0000000000000000
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RDX: 0000000000000000
RSI: 0000000000000127 RDI: 0000000000000116
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RBP: ffff880309f23b50
R08: ffff880309734800 R09: 0000000000000024
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R10: 0000000000000000
R11: 0000000000000000 R12: ffff880309737800
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R13: ffff88030a334000
R14: ffff880309737000 R15: ffff880309737800
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: FS:
0000000000000000(0000) GS:ffff88031e240000(0000)
knlGS:0000000000000000
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
CR3: 0000000001c06000 CR4: 00000000001406e0
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Stack:
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffffffffa09d4295
ffff880309f23bd8 ffffffffa09a7c1f ffffffff8122544d
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffff880306660258
ffff880306660000 0000000009737800 ffff88030a331000
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: 0100880300000024
ffff880309f23bb8 ffffffff00000024 ffff880309737800
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Call Trace:
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09d4295>] ?
intel_dp_sink_bpc+0x25/0x30 [i915]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09a7c1f>]
intel_atomic_check+0xacf/0x1250 [i915]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8122544d>] ?
__kmalloc_track_caller+0x12d/0x210
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0097ea7>]
drm_atomic_check_only+0x187/0x610 [drm]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098857>] ?
drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098347>]
drm_atomic_commit+0x17/0x60 [drm]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f4e0c>]
restore_fbdev_mode+0x14c/0x260 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a23>]
drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a9d>]
drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f69b8>]
drm_fb_helper_hotplug_event+0x148/0x180 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09c238a>]
intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00e79c7>]
drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09cafa5>]
intel_dp_mst_hotplug+0x15/0x20 [i915]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee31a>]
drm_dp_send_link_address+0x19a/0x220 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810df553>] ?
put_prev_entity+0x33/0x410
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8111280b>] ?
add_timer_on+0xdb/0x1b0
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8102c766>] ?
__switch_to+0x2b6/0x600
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810e361e>] ?
pick_next_task_fair+0x10e/0x4d0
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee44d>]
drm_dp_check_and_send_link_address+0xad/0xc0 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee4b7>]
drm_dp_mst_link_probe_work+0x57/0xb0 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c086f>]
process_one_work+0x15f/0x410
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b6e>]
worker_thread+0x4e/0x480
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
process_one_work+0x410/0x410
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
process_one_work+0x410/0x410
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c64c8>]
kthread+0xd8/0xf0
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff817d527f>]
ret_from_fork+0x1f/0x40
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c63f0>] ?
kthread_worker_fn+0x170/0x170
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Code: b8 b0 1e 04 00 48
89 e5 74 11 40 80 ff 14 ba d0 78 02 00 b8 60 3d 08 00 0f 45 c2 5d c3
66 0f 1f
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP
[<ffffffffa00e6cf5>] drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP <ffff880309f23b48>
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ---[ end trace
d3270996301ba013 ]---
Possibly MST related.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.
2016-08-03 3:07 ` Dave Airlie
@ 2016-08-03 6:09 ` Daniel Vetter
2016-08-03 12:03 ` Mario Kleiner
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2016-08-03 6:09 UTC (permalink / raw)
To: Dave Airlie; +Cc: Jani Nikula, Daniel Vetter, dri-devel
On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
> On 6 July 2016 at 20:05, Mario Kleiner <mario.kleiner.de@gmail.com> wrote:
> > For DP sinks which don't expose color depth via EDID, use
> > the drm_dp_sink_bpc() helper to derive the bpc of the sink.
> >
> > This should handle DP native sinks with the "Assume 6 bpc if EDID
> > doesn't tell us" as mandated by DP spec. It gives more accurate
> > values for DP->legacy converters for HDMI, DVI and VGA.
>
> Haswell says no.
Yup indeed, sorry for missing that. Tomeu and Mika Kahola are working on
some fancy new dp helper to probe all that, and as part of that suitably
fill out connector->display_info, too. That would allow both the
inversion, and the dpcd transaction from within atomic_check (which is
kinda not that cool either).
-Daniel
>
> ug 03 12:58:46 tyrion-bne-redhat-com kernel: fbcon: inteldrmfb (fb0)
> is primary device
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: BUG: unable to handle
> kernel NULL pointer dereference at 000000000000011b
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: IP: [<ffffffffa00e6cf5>]
> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: PGD 0
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Oops: 0000 [#1] SMP
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Modules linked in: i915
> ccm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun
> ip6t_rpfilter ip6t_
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: videobuf2_core
> snd_hda_codec videodev mei_me mei snd_hwdep snd_seq snd_hda_core
> rtsx_pci media i2c_i
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CPU: 1 PID: 752 Comm:
> kworker/1:3 Not tainted 4.7.0+ #12
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Hardware name: LENOVO
> 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Workqueue: events_long
> drm_dp_mst_link_probe_work [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: task: ffff880308583a80
> task.stack: ffff880309f20000
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP:
> 0010:[<ffffffffa00e6cf5>] [<ffffffffa00e6cf5>]
> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP:
> 0018:ffff880309f23b48 EFLAGS: 00010202
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RAX: 000000000000000a
> RBX: 0000000000000006 RCX: 0000000000000000
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RDX: 0000000000000000
> RSI: 0000000000000127 RDI: 0000000000000116
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RBP: ffff880309f23b50
> R08: ffff880309734800 R09: 0000000000000024
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R10: 0000000000000000
> R11: 0000000000000000 R12: ffff880309737800
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R13: ffff88030a334000
> R14: ffff880309737000 R15: ffff880309737800
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: FS:
> 0000000000000000(0000) GS:ffff88031e240000(0000)
> knlGS:0000000000000000
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CS: 0010 DS: 0000 ES:
> 0000 CR0: 0000000080050033
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
> CR3: 0000000001c06000 CR4: 00000000001406e0
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Stack:
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffffffffa09d4295
> ffff880309f23bd8 ffffffffa09a7c1f ffffffff8122544d
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffff880306660258
> ffff880306660000 0000000009737800 ffff88030a331000
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: 0100880300000024
> ffff880309f23bb8 ffffffff00000024 ffff880309737800
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Call Trace:
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09d4295>] ?
> intel_dp_sink_bpc+0x25/0x30 [i915]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09a7c1f>]
> intel_atomic_check+0xacf/0x1250 [i915]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8122544d>] ?
> __kmalloc_track_caller+0x12d/0x210
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0097ea7>]
> drm_atomic_check_only+0x187/0x610 [drm]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098857>] ?
> drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098347>]
> drm_atomic_commit+0x17/0x60 [drm]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f4e0c>]
> restore_fbdev_mode+0x14c/0x260 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a23>]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a9d>]
> drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f69b8>]
> drm_fb_helper_hotplug_event+0x148/0x180 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09c238a>]
> intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00e79c7>]
> drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09cafa5>]
> intel_dp_mst_hotplug+0x15/0x20 [i915]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee31a>]
> drm_dp_send_link_address+0x19a/0x220 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810df553>] ?
> put_prev_entity+0x33/0x410
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8111280b>] ?
> add_timer_on+0xdb/0x1b0
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8102c766>] ?
> __switch_to+0x2b6/0x600
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810e361e>] ?
> pick_next_task_fair+0x10e/0x4d0
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee44d>]
> drm_dp_check_and_send_link_address+0xad/0xc0 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee4b7>]
> drm_dp_mst_link_probe_work+0x57/0xb0 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c086f>]
> process_one_work+0x15f/0x410
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b6e>]
> worker_thread+0x4e/0x480
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
> process_one_work+0x410/0x410
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
> process_one_work+0x410/0x410
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c64c8>]
> kthread+0xd8/0xf0
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff817d527f>]
> ret_from_fork+0x1f/0x40
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c63f0>] ?
> kthread_worker_fn+0x170/0x170
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Code: b8 b0 1e 04 00 48
> 89 e5 74 11 40 80 ff 14 ba d0 78 02 00 b8 60 3d 08 00 0f 45 c2 5d c3
> 66 0f 1f
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP
> [<ffffffffa00e6cf5>] drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP <ffff880309f23b48>
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ---[ end trace
> d3270996301ba013 ]---
>
> Possibly MST related.
>
> Dave.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.
2016-08-03 6:09 ` Daniel Vetter
@ 2016-08-03 12:03 ` Mario Kleiner
2016-08-07 16:10 ` Mario Kleiner
0 siblings, 1 reply; 12+ messages in thread
From: Mario Kleiner @ 2016-08-03 12:03 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie; +Cc: Jani Nikula, Daniel Vetter, dri-devel
On 08/03/2016 08:09 AM, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
>> On 6 July 2016 at 20:05, Mario Kleiner <mario.kleiner.de@gmail.com> wrote:
>>> For DP sinks which don't expose color depth via EDID, use
>>> the drm_dp_sink_bpc() helper to derive the bpc of the sink.
>>>
>>> This should handle DP native sinks with the "Assume 6 bpc if EDID
>>> doesn't tell us" as mandated by DP spec. It gives more accurate
>>> values for DP->legacy converters for HDMI, DVI and VGA.
>>
>> Haswell says no.
>
> Yup indeed, sorry for missing that. Tomeu and Mika Kahola are working on
> some fancy new dp helper to probe all that, and as part of that suitably
> fill out connector->display_info, too. That would allow both the
> inversion, and the dpcd transaction from within atomic_check (which is
> kinda not that cool either).
> -Daniel
>
Ups, sorry. They were only successfully tested with Ironlake and
Ivybridge, non-MST, all the Intel hw i have here.
Anyway, patches 1+2 and 5 are independent of those and will fix existing
bugs and regressions in stable kernels. Patch 1 fixes what the commit
reverted in patch 2 was fixing. Patch 2 fixes the DP->legacy regressions
which affect my users, patch 5 adds robustness for DVI sinks in general,
making full use of EDID 1.3 info.
Maybe the logic in patch 3 can be somehow useful for Tomeu and Mika, as
it was tested with different dp -> xx adapters. Happy to review or test
once they have stuff ready.
thanks,
-mario
>>
>> ug 03 12:58:46 tyrion-bne-redhat-com kernel: fbcon: inteldrmfb (fb0)
>> is primary device
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: BUG: unable to handle
>> kernel NULL pointer dereference at 000000000000011b
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: IP: [<ffffffffa00e6cf5>]
>> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: PGD 0
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Oops: 0000 [#1] SMP
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Modules linked in: i915
>> ccm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun
>> ip6t_rpfilter ip6t_
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: videobuf2_core
>> snd_hda_codec videodev mei_me mei snd_hwdep snd_seq snd_hda_core
>> rtsx_pci media i2c_i
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CPU: 1 PID: 752 Comm:
>> kworker/1:3 Not tainted 4.7.0+ #12
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Hardware name: LENOVO
>> 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Workqueue: events_long
>> drm_dp_mst_link_probe_work [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: task: ffff880308583a80
>> task.stack: ffff880309f20000
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP:
>> 0010:[<ffffffffa00e6cf5>] [<ffffffffa00e6cf5>]
>> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP:
>> 0018:ffff880309f23b48 EFLAGS: 00010202
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RAX: 000000000000000a
>> RBX: 0000000000000006 RCX: 0000000000000000
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RDX: 0000000000000000
>> RSI: 0000000000000127 RDI: 0000000000000116
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RBP: ffff880309f23b50
>> R08: ffff880309734800 R09: 0000000000000024
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R10: 0000000000000000
>> R11: 0000000000000000 R12: ffff880309737800
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R13: ffff88030a334000
>> R14: ffff880309737000 R15: ffff880309737800
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: FS:
>> 0000000000000000(0000) GS:ffff88031e240000(0000)
>> knlGS:0000000000000000
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CS: 0010 DS: 0000 ES:
>> 0000 CR0: 0000000080050033
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
>> CR3: 0000000001c06000 CR4: 00000000001406e0
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Stack:
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffffffffa09d4295
>> ffff880309f23bd8 ffffffffa09a7c1f ffffffff8122544d
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffff880306660258
>> ffff880306660000 0000000009737800 ffff88030a331000
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: 0100880300000024
>> ffff880309f23bb8 ffffffff00000024 ffff880309737800
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Call Trace:
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09d4295>] ?
>> intel_dp_sink_bpc+0x25/0x30 [i915]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09a7c1f>]
>> intel_atomic_check+0xacf/0x1250 [i915]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8122544d>] ?
>> __kmalloc_track_caller+0x12d/0x210
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0097ea7>]
>> drm_atomic_check_only+0x187/0x610 [drm]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098857>] ?
>> drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098347>]
>> drm_atomic_commit+0x17/0x60 [drm]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f4e0c>]
>> restore_fbdev_mode+0x14c/0x260 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a23>]
>> drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a9d>]
>> drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f69b8>]
>> drm_fb_helper_hotplug_event+0x148/0x180 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09c238a>]
>> intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00e79c7>]
>> drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09cafa5>]
>> intel_dp_mst_hotplug+0x15/0x20 [i915]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee31a>]
>> drm_dp_send_link_address+0x19a/0x220 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810df553>] ?
>> put_prev_entity+0x33/0x410
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8111280b>] ?
>> add_timer_on+0xdb/0x1b0
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8102c766>] ?
>> __switch_to+0x2b6/0x600
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810e361e>] ?
>> pick_next_task_fair+0x10e/0x4d0
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee44d>]
>> drm_dp_check_and_send_link_address+0xad/0xc0 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee4b7>]
>> drm_dp_mst_link_probe_work+0x57/0xb0 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c086f>]
>> process_one_work+0x15f/0x410
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b6e>]
>> worker_thread+0x4e/0x480
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
>> process_one_work+0x410/0x410
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
>> process_one_work+0x410/0x410
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c64c8>]
>> kthread+0xd8/0xf0
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff817d527f>]
>> ret_from_fork+0x1f/0x40
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c63f0>] ?
>> kthread_worker_fn+0x170/0x170
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Code: b8 b0 1e 04 00 48
>> 89 e5 74 11 40 80 ff 14 ba d0 78 02 00 b8 60 3d 08 00 0f 45 c2 5d c3
>> 66 0f 1f
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP
>> [<ffffffffa00e6cf5>] drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP <ffff880309f23b48>
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ---[ end trace
>> d3270996301ba013 ]---
>>
>> Possibly MST related.
>>
>> Dave.
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.
2016-08-03 12:03 ` Mario Kleiner
@ 2016-08-07 16:10 ` Mario Kleiner
0 siblings, 0 replies; 12+ messages in thread
From: Mario Kleiner @ 2016-08-07 16:10 UTC (permalink / raw)
To: Daniel Vetter, Dave Airlie; +Cc: Jani Nikula, Daniel Vetter, dri-devel
On 08/03/2016 02:03 PM, Mario Kleiner wrote:
> On 08/03/2016 08:09 AM, Daniel Vetter wrote:
>> On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote:
>>> On 6 July 2016 at 20:05, Mario Kleiner <mario.kleiner.de@gmail.com>
>>> wrote:
>>>> For DP sinks which don't expose color depth via EDID, use
>>>> the drm_dp_sink_bpc() helper to derive the bpc of the sink.
>>>>
>>>> This should handle DP native sinks with the "Assume 6 bpc if EDID
>>>> doesn't tell us" as mandated by DP spec. It gives more accurate
>>>> values for DP->legacy converters for HDMI, DVI and VGA.
>>>
>>> Haswell says no.
>>
>> Yup indeed, sorry for missing that. Tomeu and Mika Kahola are working on
>> some fancy new dp helper to probe all that, and as part of that suitably
>> fill out connector->display_info, too. That would allow both the
>> inversion, and the dpcd transaction from within atomic_check (which is
>> kinda not that cool either).
>> -Daniel
>>
>
> Ups, sorry. They were only successfully tested with Ironlake and
> Ivybridge, non-MST, all the Intel hw i have here.
>
> Anyway, patches 1+2 and 5 are independent of those and will fix existing
> bugs and regressions in stable kernels. Patch 1 fixes what the commit
> reverted in patch 2 was fixing. Patch 2 fixes the DP->legacy regressions
> which affect my users, patch 5 adds robustness for DVI sinks in general,
> making full use of EDID 1.3 info.
>
> Maybe the logic in patch 3 can be somehow useful for Tomeu and Mika, as
> it was tested with different dp -> xx adapters. Happy to review or test
> once they have stuff ready.
>
So, how to proceed? Will the good ones be merged for 4.8? I could also
add a NULL-Ptr check to patch 4 and let it fall back to reporting 8 bpc
in case of dp-mst trouble if that is preferred for the time being?
I'd really like to get at least the regression fixes in before Tomeu or
Mika, as i assume once their work gets merged, touching the same code in
intel-kms, it will be impossible to back port my fixes or their work to
stable kernels.
Thanks,
-mario
> thanks,
> -mario
>
>>>
>>> ug 03 12:58:46 tyrion-bne-redhat-com kernel: fbcon: inteldrmfb (fb0)
>>> is primary device
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: BUG: unable to handle
>>> kernel NULL pointer dereference at 000000000000011b
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: IP: [<ffffffffa00e6cf5>]
>>> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: PGD 0
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Oops: 0000 [#1] SMP
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Modules linked in: i915
>>> ccm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun
>>> ip6t_rpfilter ip6t_
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: videobuf2_core
>>> snd_hda_codec videodev mei_me mei snd_hwdep snd_seq snd_hda_core
>>> rtsx_pci media i2c_i
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CPU: 1 PID: 752 Comm:
>>> kworker/1:3 Not tainted 4.7.0+ #12
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Hardware name: LENOVO
>>> 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Workqueue: events_long
>>> drm_dp_mst_link_probe_work [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: task: ffff880308583a80
>>> task.stack: ffff880309f20000
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP:
>>> 0010:[<ffffffffa00e6cf5>] [<ffffffffa00e6cf5>]
>>> drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP:
>>> 0018:ffff880309f23b48 EFLAGS: 00010202
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RAX: 000000000000000a
>>> RBX: 0000000000000006 RCX: 0000000000000000
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RDX: 0000000000000000
>>> RSI: 0000000000000127 RDI: 0000000000000116
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RBP: ffff880309f23b50
>>> R08: ffff880309734800 R09: 0000000000000024
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R10: 0000000000000000
>>> R11: 0000000000000000 R12: ffff880309737800
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: R13: ffff88030a334000
>>> R14: ffff880309737000 R15: ffff880309737800
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: FS:
>>> 0000000000000000(0000) GS:ffff88031e240000(0000)
>>> knlGS:0000000000000000
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CS: 0010 DS: 0000 ES:
>>> 0000 CR0: 0000000080050033
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
>>> CR3: 0000000001c06000 CR4: 00000000001406e0
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Stack:
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffffffffa09d4295
>>> ffff880309f23bd8 ffffffffa09a7c1f ffffffff8122544d
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ffff880306660258
>>> ffff880306660000 0000000009737800 ffff88030a331000
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: 0100880300000024
>>> ffff880309f23bb8 ffffffff00000024 ffff880309737800
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Call Trace:
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09d4295>] ?
>>> intel_dp_sink_bpc+0x25/0x30 [i915]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09a7c1f>]
>>> intel_atomic_check+0xacf/0x1250 [i915]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8122544d>] ?
>>> __kmalloc_track_caller+0x12d/0x210
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0097ea7>]
>>> drm_atomic_check_only+0x187/0x610 [drm]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098857>] ?
>>> drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa0098347>]
>>> drm_atomic_commit+0x17/0x60 [drm]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f4e0c>]
>>> restore_fbdev_mode+0x14c/0x260 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a23>]
>>> drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f6a9d>]
>>> drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00f69b8>]
>>> drm_fb_helper_hotplug_event+0x148/0x180 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09c238a>]
>>> intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00e79c7>]
>>> drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa09cafa5>]
>>> intel_dp_mst_hotplug+0x15/0x20 [i915]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee31a>]
>>> drm_dp_send_link_address+0x19a/0x220 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810df553>] ?
>>> put_prev_entity+0x33/0x410
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8111280b>] ?
>>> add_timer_on+0xdb/0x1b0
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff8102c766>] ?
>>> __switch_to+0x2b6/0x600
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810e361e>] ?
>>> pick_next_task_fair+0x10e/0x4d0
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee44d>]
>>> drm_dp_check_and_send_link_address+0xad/0xc0 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffffa00ee4b7>]
>>> drm_dp_mst_link_probe_work+0x57/0xb0 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c086f>]
>>> process_one_work+0x15f/0x410
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b6e>]
>>> worker_thread+0x4e/0x480
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
>>> process_one_work+0x410/0x410
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c0b20>] ?
>>> process_one_work+0x410/0x410
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c64c8>]
>>> kthread+0xd8/0xf0
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff817d527f>]
>>> ret_from_fork+0x1f/0x40
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: [<ffffffff810c63f0>] ?
>>> kthread_worker_fn+0x170/0x170
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: Code: b8 b0 1e 04 00 48
>>> 89 e5 74 11 40 80 ff 14 ba d0 78 02 00 b8 60 3d 08 00 0f 45 c2 5d c3
>>> 66 0f 1f
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RIP
>>> [<ffffffffa00e6cf5>] drm_dp_sink_bpc+0x5/0xb0 [drm_kms_helper]
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: RSP <ffff880309f23b48>
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: CR2: 000000000000011b
>>> Aug 03 12:58:46 tyrion-bne-redhat-com kernel: ---[ end trace
>>> d3270996301ba013 ]---
>>>
>>> Possibly MST related.
>>>
>>> Dave.
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 5/5] drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
` (3 preceding siblings ...)
2016-07-06 10:05 ` [PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell Mario Kleiner
@ 2016-07-06 10:05 ` Mario Kleiner
2016-07-30 15:08 ` Fwd: EDID/DP fixes for proper bpc detection of displays Mario Kleiner
5 siblings, 0 replies; 12+ messages in thread
From: Mario Kleiner @ 2016-07-06 10:05 UTC (permalink / raw)
To: dri-devel; +Cc: Jani Nikula, Daniel Vetter
According to E-EDID spec 1.3, table 3.9, a digital video sink with the
"DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x
TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned".
For such displays, the DFP spec 1.0, section 3.10 "EDID support" says:
"If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.)
without extensions, the host will make the following assumptions:
1. 24-bit MSB-aligned RGB TFT
2. DE polarity is active high
3. H and V syncs are active high
4. Established CRT timings will be used
5. Dithering will not be enabled on the host"
So if we don't know the bit depth of the display from additional
colorimetry info we should assume 8 bpc / 24 bpp by default.
This patch adds info->bpc = 8 assignement for that case.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_edid.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2cb472b..637a0aa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3867,6 +3867,20 @@ static void drm_add_display_info(struct edid *edid,
/* HDMI deep color modes supported? Assign to info, if so */
drm_assign_hdmi_deep_color_info(edid, info, connector);
+ /*
+ * Digital sink with "DFP 1.x compliant TMDS" according to EDID 1.3?
+ *
+ * For such displays, the DFP spec 1.0, section 3.10 "EDID support"
+ * tells us to assume 8 bpc color depth if the EDID doesn't have
+ * extensions which tell otherwise.
+ */
+ if ((info->bpc == 0) && (edid->revision < 4) &&
+ (edid->input & DRM_EDID_DIGITAL_TYPE_DVI)) {
+ info->bpc = 8;
+ DRM_DEBUG("%s: Assigning DFP sink color depth as %d bpc.\n",
+ connector->name, info->bpc);
+ }
+
/* Only defined for 1.4 with digital displays */
if (edid->revision < 4)
return;
--
2.7.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 12+ messages in thread* Fwd: EDID/DP fixes for proper bpc detection of displays.
2016-07-06 10:05 EDID/DP fixes for proper bpc detection of displays Mario Kleiner
` (4 preceding siblings ...)
2016-07-06 10:05 ` [PATCH 5/5] drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS" Mario Kleiner
@ 2016-07-30 15:08 ` Mario Kleiner
2016-08-02 13:16 ` Daniel Vetter
5 siblings, 1 reply; 12+ messages in thread
From: Mario Kleiner @ 2016-07-30 15:08 UTC (permalink / raw)
To: dri-devel@lists.freedesktop.org; +Cc: Jani Nikula, Dave Airlie, Daniel Vetter
Three weeks have passed, so resending. Could i maybe excite somebody to
review/merge at least some of the really trivial but important patches
to fix regressions back-ported to all stable kernels, mostly in Intel
kms + DP legacy in this series before the 4.8 merge window closes?
Especially patch 2, "[PATCH 2/5] drm/i915/dp: Revert "drm/i915/dp: fall
back to 18 bpp when sink capability is unknown" a revert acked by Jani
for a patch of him, and patch 5 "[PATCH 5/5] drm/edid: Set 8 bpc color
depth for displays with "DFP 1.x compliant TMDS"?
Patch 5/5 would make our EDID parsing for DVI more complete and if also
back-ported to stable would at least prevent the worst fallout for
current users if patch 2/5 doesn't get applied.
thanks,
-mario
-------- Forwarded Message --------
Subject: EDID/DP fixes for proper bpc detection of displays.
Date: Wed, 6 Jul 2016 12:05:43 +0200
From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: dri-devel@lists.freedesktop.org
CC: mario.kleiner.de@gmail.com
Updated series to fix the regressions introduced into stable
kernels for active Displayport to dual-link DVI converters and
for active Displayport to VGA converters. Also to fix this stuff
better for Linux 4.8.
Patch 1 + 2 are needed to fix the regressions in the stable
kernels. These are meant for easy backporting to all affected
kernels.
Patch 3: A DP helper for parsing sink bpc from DP aux data to
assist drivers if they can't get bpc from EDID.
Patch 4: Make intel kms use patch 3.
Patch 5: Make the EDID parser recognize the "DFP1.x compatible TMDS"
bit by which DVI sinks can declare they support at least 8 bpc according
to DFP spec. This one if applied would let me sleep so much better, as
the common special display equipment for neuroscience research, which is
all DVI based atm., sets that bit in its EDID 1.3.
Thanks,
-mario
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Fwd: EDID/DP fixes for proper bpc detection of displays.
2016-07-30 15:08 ` Fwd: EDID/DP fixes for proper bpc detection of displays Mario Kleiner
@ 2016-08-02 13:16 ` Daniel Vetter
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2016-08-02 13:16 UTC (permalink / raw)
To: Mario Kleiner
Cc: Jani Nikula, Dave Airlie, dri-devel@lists.freedesktop.org,
Daniel Vetter
On Sat, Jul 30, 2016 at 05:08:03PM +0200, Mario Kleiner wrote:
> Three weeks have passed, so resending. Could i maybe excite somebody to
> review/merge at least some of the really trivial but important patches to
> fix regressions back-ported to all stable kernels, mostly in Intel kms + DP
> legacy in this series before the 4.8 merge window closes?
>
> Especially patch 2, "[PATCH 2/5] drm/i915/dp: Revert "drm/i915/dp: fall back
> to 18 bpp when sink capability is unknown" a revert acked by Jani for a
> patch of him, and patch 5 "[PATCH 5/5] drm/edid: Set 8 bpc color depth for
> displays with "DFP 1.x compliant TMDS"?
>
> Patch 5/5 would make our EDID parsing for DVI more complete and if also
> back-ported to stable would at least prevent the worst fallout for current
> users if patch 2/5 doesn't get applied.
I don't have the spec handy to review the details, but it all seems to
make sense. Ack: me.
Dave, probably simplest if you just pick up the entire pile into drm-fixes
directly? Or still offline because cold, and I should carry it in
drm-fixes?
-Daniel
>
> thanks,
> -mario
>
> -------- Forwarded Message --------
> Subject: EDID/DP fixes for proper bpc detection of displays.
> Date: Wed, 6 Jul 2016 12:05:43 +0200
> From: Mario Kleiner <mario.kleiner.de@gmail.com>
> To: dri-devel@lists.freedesktop.org
> CC: mario.kleiner.de@gmail.com
>
> Updated series to fix the regressions introduced into stable
> kernels for active Displayport to dual-link DVI converters and
> for active Displayport to VGA converters. Also to fix this stuff
> better for Linux 4.8.
>
> Patch 1 + 2 are needed to fix the regressions in the stable
> kernels. These are meant for easy backporting to all affected
> kernels.
>
> Patch 3: A DP helper for parsing sink bpc from DP aux data to
> assist drivers if they can't get bpc from EDID.
>
> Patch 4: Make intel kms use patch 3.
>
> Patch 5: Make the EDID parser recognize the "DFP1.x compatible TMDS"
> bit by which DVI sinks can declare they support at least 8 bpc according
> to DFP spec. This one if applied would let me sleep so much better, as
> the common special display equipment for neuroscience research, which is
> all DVI based atm., sets that bit in its EDID 1.3.
>
> Thanks,
> -mario
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 12+ messages in thread