3.13.11-ckt26 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <daniel.vetter@xxxxxxxx>
commit 5677d67ae3949f09f57357241b88222d49b8c782 upstream.
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f02fbbfc6decc945a69aae011041a27
Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Date: Fri Mar 6 12:36:42 2015 +0000
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos <tiagomatos@xxxxxxxxx>
Cc: Julien Wajsberg <felash@xxxxxxxxx>
Cc: kuddel.mail@xxxxxx
Cc: Lennart Poettering <mzxreary@xxxxxxxxxxx>
Acked-by: Rob Clark <robdclark@xxxxxxxxx>
Tested-by: Rui Tiago Cação Matos <tiagomatos@xxxxxxxxx>
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
Signed-off-by: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
---
drivers/gpu/drm/drm_crtc.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 944ff1e..87591bb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3730,12 +3730,9 @@ void drm_mode_config_reset(struct drm_device *dev)
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- connector->status = connector_status_unknown;
-
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head)
if (connector->funcs->reset)
connector->funcs->reset(connector);
- }
}
EXPORT_SYMBOL(drm_mode_config_reset);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html