[PATCH 3.13.y-ckt 11/60] drm: Stop resetting connector state to unknown

From: Kamal Mostafa
Date: Tue Sep 01 2015 - 21:11:24 EST

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)

- 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)
- }


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/