From f6a1906674005377b64ee5431c1418077c1b2425 Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Thu, 16 Oct 2014 20:46:09 +0300 Subject: drm/i915: Do a dummy DPCD read before the actual read MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sometimes we seem to get utter garbage from DPCD reads. The resulting buffer is filled with the same byte, and the operation completed without errors. My HP ZR24w monitor seems particularly susceptible to this problem once it's gone into a sleep mode. The issue seems to happen only for the first AUX message that wakes the sink up. But as the first AUX read we often do is the DPCD receiver cap it does wreak a bit of havoc with subsequent link training etc. when the receiver cap bw/lane/etc. information is garbage. A sufficient workaround seems to be to perform a single byte dummy read before reading the actual data. I suppose that just wakes up the sink sufficiently and we can just throw away the returned data in case it's crap. DP_DPCD_REV seems like a sufficiently safe location to read here. Signed-off-by: Ville Syrjälä Reviewed-by: Todd Previte Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f6a3fdd5589e..f9c5f17af9d8 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2806,6 +2806,13 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset, ssize_t ret; int i; + /* + * Sometime we just get the same incorrect byte repeated + * over the entire buffer. Doing just one throw away read + * initially seems to "solve" it. + */ + drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1); + for (i = 0; i < 3; i++) { ret = drm_dp_dpcd_read(aux, offset, buffer, size); if (ret == size) -- cgit v1.2.3 From 7a7f84ccb82e542c845c43f604665ccea1247866 Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Thu, 16 Oct 2014 20:46:10 +0300 Subject: drm/i915: Ignore long hpds on eDP ports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Turning vdd on/off can generate a long hpd pulse on eDP ports. In order to handle hpd we would need to turn on vdd to perform aux transfers. This would lead to an endless cycle of "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." So ignore long hpd pulses on eDP ports. eDP panels should be physically tied to the machine anyway so they should not actually disappear and thus don't need long hpd handling. Short hpds are still needed for link re-train and whatnot so we can't just turn off the hpd interrupt entirely for eDP ports. Perhaps we could turn it off whenever the panel is disabled, but just ignoring the long hpd seems sufficient. Signed-off-by: Ville Syrjälä Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie Reviewed-by: Todd Previte Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f9c5f17af9d8..464d8ad9bb71 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4498,6 +4498,18 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd) if (intel_dig_port->base.type != INTEL_OUTPUT_EDP) intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT; + if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) { + /* + * vdd off can generate a long pulse on eDP which + * would require vdd on to handle it, and thus we + * would end up in an endless cycle of + * "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..." + */ + DRM_DEBUG_KMS("ignoring long hpd on eDP port %c\n", + port_name(intel_dig_port->port)); + return false; + } + DRM_DEBUG_KMS("got hpd irq on port %c - %s\n", port_name(intel_dig_port->port), long_hpd ? "long" : "short"); -- cgit v1.2.3 From 6be1e3d3ea29354d7c834a3936e796e185d5c73b Mon Sep 17 00:00:00 2001 From: Ville Syrjälä Date: Thu, 16 Oct 2014 20:52:31 +0300 Subject: drm/i915: Fix GMBUSFREQ on vlv/chv MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider. This is a regression from: commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727 Author: Ville Syrjälä Date: Fri Jun 13 13:37:54 2014 +0300 drm/i915: Kill duplicated cdclk readout code from i2c Signed-off-by: Ville Syrjälä Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c9e220963a78..07ff29589d37 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4585,7 +4585,7 @@ static void vlv_update_cdclk(struct drm_device *dev) * BSpec erroneously claims we should aim for 4MHz, but * in fact 1MHz is the correct frequency. */ - I915_WRITE(GMBUSFREQ_VLV, dev_priv->vlv_cdclk_freq); + I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->vlv_cdclk_freq, 1000)); } /* Adjust CDclk dividers to allow high res or save power if possible */ -- cgit v1.2.3 From b2a9601c587dbc5536546aa54009d1130adedd72 Mon Sep 17 00:00:00 2001 From: jens stein Date: Tue, 28 Oct 2014 20:25:53 +0100 Subject: drm/i915: Ignore VBT backlight check on Macbook 2, 1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT check so backlight is set up properly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438 Signed-off-by: Jens Stein Jørgensen Cc: stable@vger.kernel.org (3.15+) Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 07ff29589d37..f0a1a56406eb 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12885,6 +12885,9 @@ static struct intel_quirk intel_quirks[] = { /* Acer C720 Chromebook (Core i3 4005U) */ { 0x0a16, 0x1025, 0x0a11, quirk_backlight_present }, + /* Apple Macbook 2,1 (Core 2 T7400) */ + { 0x27a2, 0x8086, 0x7270, quirk_backlight_present }, + /* Toshiba CB35 Chromebook (Celeron 2955U) */ { 0x0a06, 0x1179, 0x0a88, quirk_backlight_present }, -- cgit v1.2.3 From 7809a61176b385ebb3299ea43c58b1bb31ffb8c0 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Wed, 29 Oct 2014 11:03:26 +0200 Subject: drm/i915/dp: only use training pattern 3 on platforms that support it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by: Dave Airlie Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte Cc: stable@vger.kernel.org (3.15+) Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 464d8ad9bb71..5ad45bfff3fe 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3731,9 +3731,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) } } - /* Training Pattern 3 support */ + /* Training Pattern 3 support, both source and sink */ if (intel_dp->dpcd[DP_DPCD_REV] >= 0x12 && - intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED) { + intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED && + (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)) { intel_dp->use_tps3 = true; DRM_DEBUG_KMS("Displayport TPS3 supported\n"); } else -- cgit v1.2.3 From d6a8b72edc92471283925ceb4ba12799b67c3ff8 Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Wed, 5 Nov 2014 16:56:36 -0800 Subject: drm/i915: Disable caches for Global GTT. Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000; So the only way to avoid screen corruptions is setting PAT 0 to Uncached. MOCS can still be used though. But if userspace is trusting PTE for cache selection the safest thing to do is to let caches disabled. BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry, so RTL will always use the value corresponding to pat_sel = 000" - System agent ggtt writes (i.e. cpu gtt mmaps) already work before this patch, i.e. the same uncached + snooping access like on gen6/7 seems to be in effect. - So this just fixes blitter/render access. Again it looks like it's not just uncached access, but uncached + snooping. So we can still hold onto all our assumptions wrt cpu clflushing on LLC machines. v2: Cleaner patch as suggested by Chris. v3: Add Daniel's comment Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576 Cc: Chris Wilson Cc: James Ausmus Cc: Daniel Vetter Cc: Jani Nikula Cc: Stable@vger.kernel.org Tested-by: James Ausmus Reviewed-by: James Ausmus Signed-off-by: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index b672b843fd5e..728938f02341 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1902,6 +1902,22 @@ static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv) GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) | GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3)); + if (!USES_PPGTT(dev_priv->dev)) + /* Spec: "For GGTT, there is NO pat_sel[2:0] from the entry, + * so RTL will always use the value corresponding to + * pat_sel = 000". + * So let's disable cache for GGTT to avoid screen corruptions. + * MOCS still can be used though. + * - System agent ggtt writes (i.e. cpu gtt mmaps) already work + * before this patch, i.e. the same uncached + snooping access + * like on gen6/7 seems to be in effect. + * - So this just fixes blitter/render access. Again it looks + * like it's not just uncached access, but uncached + snooping. + * So we can still hold onto all our assumptions wrt cpu + * clflushing on LLC machines. + */ + pat = GEN8_PPAT(0, GEN8_PPAT_UC); + /* XXX: spec defines this as 2 distinct registers. It's unclear if a 64b * write would work. */ I915_WRITE(GEN8_PRIVATE_PAT, pat); -- cgit v1.2.3 From a024d2e6f11836493d9e1751fca7b3c50fbfd215 Mon Sep 17 00:00:00 2001 From: Imre Deak Date: Wed, 10 Sep 2014 18:16:54 +0300 Subject: drm/i915: vlv: fix gunit HW state corruption during S4 suspend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit During S4 freeze we don't call intel_suspend_complete(), which would save the gunit HW state, but during S4 thaw/restore events we call intel_resume_prepare() which restores it, thus ending up in a corrupted HW state. Fix this by calling intel_suspend_complete() from the corresponding freeze_late event handler. The issue was introduced in commit 016970beb05da6285c2f3ed2bee1c676cb75972e Author: Sagar Kamble Date: Wed Aug 13 23:07:06 2014 +0530 CC: Sagar Kamble Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 055d5e7fbf12..2318b4c7a8f8 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -986,6 +986,15 @@ static int i915_pm_freeze(struct device *dev) return i915_drm_freeze(drm_dev); } +static int i915_pm_freeze_late(struct device *dev) +{ + struct pci_dev *pdev = to_pci_dev(dev); + struct drm_device *drm_dev = pci_get_drvdata(pdev); + struct drm_i915_private *dev_priv = drm_dev->dev_private; + + return intel_suspend_complete(dev_priv); +} + static int i915_pm_thaw_early(struct device *dev) { struct pci_dev *pdev = to_pci_dev(dev); @@ -1570,6 +1579,7 @@ static const struct dev_pm_ops i915_pm_ops = { .resume_early = i915_pm_resume_early, .resume = i915_pm_resume, .freeze = i915_pm_freeze, + .freeze_late = i915_pm_freeze_late, .thaw_early = i915_pm_thaw_early, .thaw = i915_pm_thaw, .poweroff = i915_pm_poweroff, -- cgit v1.2.3 From e1c412e75754ab7b7002f3e18a2652d999c40d4b Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Wed, 5 Nov 2014 14:46:31 +0200 Subject: drm/i915: safeguard against too high minimum brightness Never trust (your interpretation of) the VBT. Regression from commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness causing div by zero if VBT minimum brightness equals maximum brightness. Despite my attempts I've failed in my detective work to figure out what the root cause is. This is not the real fix, but we have to do something. Reported-by: Mike Auty Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86551 Cc: stable@vger.kernel.org (v3.17+) Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 0e018cb49147..41b3be217493 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1098,12 +1098,25 @@ static u32 get_backlight_min_vbt(struct intel_connector *connector) struct drm_device *dev = connector->base.dev; struct drm_i915_private *dev_priv = dev->dev_private; struct intel_panel *panel = &connector->panel; + int min; WARN_ON(panel->backlight.max == 0); + /* + * XXX: If the vbt value is 255, it makes min equal to max, which leads + * to problems. There are such machines out there. Either our + * interpretation is wrong or the vbt has bogus data. Or both. Safeguard + * against this by letting the minimum be at most (arbitrarily chosen) + * 25% of the max. + */ + min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 64); + if (min != dev_priv->vbt.backlight.min_brightness) { + DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to %d/255\n", + dev_priv->vbt.backlight.min_brightness, min); + } + /* vbt value is a coefficient in range [0..255] */ - return scale(dev_priv->vbt.backlight.min_brightness, 0, 255, - 0, panel->backlight.max); + return scale(min, 0, 255, 0, panel->backlight.max); } static int bdw_setup_backlight(struct intel_connector *connector) -- cgit v1.2.3 From e9d784d535e43777f9ff44d7e582946f4776c000 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 6 Nov 2014 08:40:35 +0000 Subject: drm/i915: Fix obj->map_and_fenceable across tiling changes As obj->map_and_fenceable computation has changed to only be set when the object is bound inside the global GTT (and is suitable aligned to a fence region) we need to accommodate those changes when the tiling is adjusted. The easiest solution is to unbind from the global GTT if we are currently fenceable, but will not be after the tiling change. The bug has been exposed by commit f8fcadba218fe6d23b2e353fea1cf0a4be4c9454 Author: Chris Wilson Date: Fri Oct 31 13:53:52 2014 +0000 drm/i915: Only mark as map-and-fenceable when bound into the GGTT which tried to fix an oversight from commit e6a844687cf929ec053c7578d5ecc794a8a6c5cf Author: Chris Wilson Date: Mon Aug 11 12:00:12 2014 +0200 drm/i915: Force CPU relocations if not GTT mapped which changed the handling of obj->map_and_fenceable. Note that the alignment check is a vestige from our attempts to reduce the alignment requirements of tiled but unfenced buffers on gen2/3. Also, that was when unbinding from the GTT meant UC writes and clflushing, so we went to great pains to avoid such. That leaves the actual bug of setting map_and_fenceable to true if we're not bound to ggtt, which violates the change introduced in the above patch. Unbinding in that case really looks like the simplest and safest option, we have to do it anyway. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85896 Testcase: igt/gem_concurrent_blit/gttX* Tested-by: huax.lu@intel.com Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Tested-by: Valtteri Rantala [Jani: amend commit message per input from Daniel and bisect result from Valtteri] Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_gem_tiling.c | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c b/drivers/gpu/drm/i915/i915_gem_tiling.c index 2cefb597df6d..2b1eaa29ada4 100644 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c @@ -364,22 +364,9 @@ i915_gem_set_tiling(struct drm_device *dev, void *data, * has to also include the unfenced register the GPU uses * whilst executing a fenced command for an untiled object. */ - - obj->map_and_fenceable = - !i915_gem_obj_ggtt_bound(obj) || - (i915_gem_obj_ggtt_offset(obj) + - obj->base.size <= dev_priv->gtt.mappable_end && - i915_gem_object_fence_ok(obj, args->tiling_mode)); - - /* Rebind if we need a change of alignment */ - if (!obj->map_and_fenceable) { - u32 unfenced_align = - i915_gem_get_gtt_alignment(dev, obj->base.size, - args->tiling_mode, - false); - if (i915_gem_obj_ggtt_offset(obj) & (unfenced_align - 1)) - ret = i915_gem_object_ggtt_unbind(obj); - } + if (obj->map_and_fenceable && + !i915_gem_object_fence_ok(obj, args->tiling_mode)) + ret = i915_gem_object_ggtt_unbind(obj); if (ret == 0) { obj->fence_dirty = -- cgit v1.2.3 From 2208d655a91f9879bd9a39ff9df05dd668b3512c Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 14 Nov 2014 09:25:29 +0100 Subject: drm/i915: drop WaSetupGtModeTdRowDispatch:snb This reverts the regressing commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f Author: Daniel Vetter Date: Fri Dec 14 23:38:29 2012 +0100 drm/i915: Implement WaSetupGtModeTdRowDispatch that causes GPU hangs immediately on boot. Reported-by: Leo Wolf Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996 Cc: stable@vger.kernel.org (v3.8+) Signed-off-by: Daniel Vetter [Jani: amended the commit message slightly.] Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_pm.c | 5 ----- 1 file changed, 5 deletions(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index c27b6140bfd1..ad2fd605f76b 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5469,11 +5469,6 @@ static void gen6_init_clock_gating(struct drm_device *dev) I915_WRITE(_3D_CHICKEN, _MASKED_BIT_ENABLE(_3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB)); - /* WaSetupGtModeTdRowDispatch:snb */ - if (IS_SNB_GT1(dev)) - I915_WRITE(GEN6_GT_MODE, - _MASKED_BIT_ENABLE(GEN6_TD_FOUR_ROW_DISPATCH_DISABLE)); - /* WaDisable_RenderCache_OperationalFlush:snb */ I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE)); -- cgit v1.2.3 From 0485c9dc24ec0939b42ca5104c0373297506b555 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 14 Nov 2014 10:09:49 +0100 Subject: drm/i915: Kick fbdev before vgacon It's magic, but it seems to work. This fixes a regression introduced in commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2 Author: Daniel Vetter Date: Tue Jul 8 10:02:43 2014 +0200 drm/i915: Only unbind vgacon, not other console drivers My best guess is that the vga fbdev driver falls over if we rip out parts of vgacon. Hooray. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439 Cc: stable@vger.kernel.org (v3.16+) Reported-and-tested-by: Lv Zheng Signed-off-by: Daniel Vetter Acked-by: Chris Wilson Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_dma.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'drivers/gpu/drm/i915') diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 1403b01e8216..318ade9bb5af 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1670,15 +1670,17 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) goto out_regs; if (drm_core_check_feature(dev, DRIVER_MODESET)) { - ret = i915_kick_out_vgacon(dev_priv); + /* WARNING: Apparently we must kick fbdev drivers before vgacon, + * otherwise the vga fbdev driver falls over. */ + ret = i915_kick_out_firmware_fb(dev_priv); if (ret) { - DRM_ERROR("failed to remove conflicting VGA console\n"); + DRM_ERROR("failed to remove conflicting framebuffer drivers\n"); goto out_gtt; } - ret = i915_kick_out_firmware_fb(dev_priv); + ret = i915_kick_out_vgacon(dev_priv); if (ret) { - DRM_ERROR("failed to remove conflicting framebuffer drivers\n"); + DRM_ERROR("failed to remove conflicting VGA console\n"); goto out_gtt; } } -- cgit v1.2.3