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
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;
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; } }
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 */
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);
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.
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.
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.
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.
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;
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
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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Dave Airlie -
Mario Kleiner