From 591a0ac7f14aae6bf11b1cb6b5a68480bd644ddb Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Thu, 23 May 2013 12:07:50 +0300 Subject: OMAPDSS: Fix crash with DT boot When booting with DT, there's a crash when omapfb is probed. This is caused by the fact that omapdss+DT is not yet supported, and thus omapdss is not probed at all. On the other hand, omapfb is always probed. When omapfb tries to use omapdss, there's a NULL pointer dereference crash. The same error should most likely happen with omapdrm and omap_vout also. To fix this, add an "initialized" state to omapdss. When omapdss has been probed, it's marked as initialized. omapfb, omapdrm and omap_vout check this state when they are probed to see that omapdss is actually there. Signed-off-by: Tomi Valkeinen Tested-by: Peter Ujfalusi --- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 079c54c6f94..902074bbd1f 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -548,6 +548,9 @@ static void pdev_shutdown(struct platform_device *device) static int pdev_probe(struct platform_device *device) { + if (omapdss_is_initialized() == false) + return -EPROBE_DEFER; + DBG("%s", device->name); return drm_platform_init(&omap_drm_driver, device); } -- cgit v1.2.3-70-g09d2 From 7abb690a0e095717420ba78dcab4309abbbec78a Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 24 May 2013 21:29:32 +0200 Subject: drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus Chris Wilson noticed that since commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9] Author: Daniel Vetter Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions X can again get -EIO when it does not expect it. And even worse score a SIGBUS when accessing gtt mmaps. The established ABI is that we _only_ return an -EIO from execbuf - all other ioctls should just work. And since the reset code moves all bos out of gpu domains and clears out all the last_seqno/ring tracking there really shouldn't be any reason for non-execbuf code to ever touch the hw and see an -EIO. After some extensive discussions we've noticed that these spurios -EIO are caused by i915_gem_wait_for_error: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html That is easy to fix by returning 0 instead of -EIO, since grabbing the dev->struct_mutex does not yet mean that we actually want to touch the hw. And so there is no reason at all to fail with -EIO. But that's not the entire since, since often (at least it's easily googleable) dmesg indicates that the reset fails and we declare the gpu wedged. Then, quite a bit later X wakes up with the "Timed out waiting for the gpu reset to complete" DRM_ERROR message in wait_for_errror and brings down the desktop with an -EIO/SIGBUS. So clearly we're missing a wakeup somewhere, since the gpu reset just doesn't take 10 seconds to complete. And indeed we're do handle the terminally wedged state wrong. Fix this all up. References: https://bugs.freedesktop.org/show_bug.cgi?id=63921 References: https://bugs.freedesktop.org/show_bug.cgi?id=64073 Cc: Chris Wilson Cc: Daniel Vetter Cc: Damien Lespiau Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index a6cf8e84397..970ad17c99a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -91,14 +91,11 @@ i915_gem_wait_for_error(struct i915_gpu_error *error) { int ret; -#define EXIT_COND (!i915_reset_in_progress(error)) +#define EXIT_COND (!i915_reset_in_progress(error) || \ + i915_terminally_wedged(error)) if (EXIT_COND) return 0; - /* GPU is already declared terminally dead, give up. */ - if (i915_terminally_wedged(error)) - return -EIO; - /* * Only wait 10 seconds for the gpu reset to complete to avoid hanging * userspace. If it takes that long something really bad is going on and -- cgit v1.2.3-70-g09d2 From d62cf62ad07d5584da1f2132641928ded8216327 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Wed, 29 May 2013 10:41:29 +0200 Subject: drm/i915: Quirk the pipe A quirk in the modeset state checker If we always force the pipe A to on we can't use the hw state to decide whether it should be on. Hence quirk the quirk. The problem is that crtc->active tracks the state of the entire display pipe, i.e. including planes, encoders and all. But our hw state readout simply looks at the pipe. But with the pipe A quirk we force-enable that (together with it's pll). To fix that mismatch we have two options: - Quirk the checked state to match what our sw tracking states if the pipe A quirk is in effect. - Improve the hw state readout to not get fooled by the pipe A quirk. Since we already have similar state clamping in e.g. assert_pipe I've opted for the first variant. Also note that we don't really loose any state checking: Individual pieces of the abstract crtc pipe are checked in the enable/disable functions with the various asssert_* checks we have, and the hw state check code doesn't check anything if the pipe is off anyway. v2: Pimp commit message after discussion with Chris and only apply the quirk for the quirk if we're checking pipe A. Otherwise we'll miss state checking for pipe B on i830M ... v3: Make the code comment consistent with the improved commit message, too (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64764 Cc: stable@vger.kernel.org Cc: Chris Wilson Reported-and-Tested-by: mlsemon35@gmail.com (v1) Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ad1117bebd7..56746dcac40 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7937,6 +7937,11 @@ intel_modeset_check_state(struct drm_device *dev) memset(&pipe_config, 0, sizeof(pipe_config)); active = dev_priv->display.get_pipe_config(crtc, &pipe_config); + + /* hw state is inconsistent with the pipe A quirk */ + if (crtc->pipe == PIPE_A && dev_priv->quirks & QUIRK_PIPEA_FORCE) + active = crtc->active; + WARN(crtc->active != active, "crtc active state doesn't match with hw state " "(expected %i, found %i)\n", crtc->active, active); -- cgit v1.2.3-70-g09d2 From 45a211d75137b1ac869a8a758a6667f15827a115 Mon Sep 17 00:00:00 2001 From: Ben Mesman Date: Tue, 16 Apr 2013 20:00:28 +0200 Subject: drm/i915: no lvds quirk for hp t5740 Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_lvds.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index f36f1baabd5..29412cc89c7 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -815,10 +815,10 @@ static const struct dmi_system_id intel_no_lvds[] = { }, { .callback = intel_no_lvds_dmi_callback, - .ident = "Hewlett-Packard HP t5740e Thin Client", + .ident = "Hewlett-Packard HP t5740", .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), - DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin Client"), + DMI_MATCH(DMI_PRODUCT_NAME, " t5740"), }, }, { -- cgit v1.2.3-70-g09d2 From 53d3b4d7778daf15900867336c85d3f8dd70600c Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Tue, 4 Jun 2013 17:13:21 +0200 Subject: drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_sdvo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/gpu/drm') diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index d15428404b9..4c47b449b77 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1776,7 +1776,7 @@ static void intel_sdvo_get_lvds_modes(struct drm_connector *connector) * Assume that the preferred modes are * arranged in priority order. */ - intel_ddc_get_modes(connector, intel_sdvo->i2c); + intel_ddc_get_modes(connector, &intel_sdvo->ddc); if (list_empty(&connector->probed_modes) == false) goto end; -- cgit v1.2.3-70-g09d2