Re: drm i915 weirdness with /sys/class/drm/card0*/status

From: Daniel Vetter <daniel@ffwll.ch>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Lennart Poettering <lennart@poettering.net>,
	David Airlie <airlied@linux.ie>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: drm i915 weirdness with /sys/class/drm/card0*/status
Date: Wed, 17 Jun 2015 13:11:14 +0200	[thread overview]
Message-ID: <20150617111114.GE23637@phenom.ffwll.local> (raw)
In-Reply-To: <CANq1E4ThiQ5uLEJBJ7WTg3U1PruwBQa3xBWoZ7w4USqpmY_KvQ@mail.gmail.com>

On Wed, Jun 17, 2015 at 10:29:48AM +0200, David Herrmann wrote:
> Hi
> 
> On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
> <lennart@poettering.net> wrote:
> > On Tue, 16.06.15 13:47, Daniel Vetter (daniel@ffwll.ch) wrote:
> >
> >> > But what does that actually mean? should logind ever echo "detect"
> >> > itself into the file? Should it follow uevents for the files? How
> >> > should treat this file?
> >>
> >> Ok here's how this is supposed to work:
> >> - If anything changes the kernel will send out an uevent and compositors/X
> >>   or anyone else interested can listen for them. We've had a few bugs in
> >>   the past where such events where lost in a combination of bad luck and
> >>   bad hw, but that should all be fixed now.
> >>
> >> - Userspace should never poll these things on its own since probing is
> >>   ridiculously expensive. Unfortunately years of closing bugs as wontfix
> >>   hasn't lead to userspace stop polling (despite that the kernel does that
> >>   too if it's needed) which resulted in the above patch to take away the
> >>   those from at least system deamons.
> >
> > I find the kernel patch you applied a bit drastic, it broke userspace,
> > returning rubbish unless somebody echoes the "detect" into the file --
> > which apparently nothing does, at least not after we came back from a
> > suspend...
> 
> I don't think it was supposed to work this way. If I read Daniel's
> reply correctly, then the kernel is supposed to re-read connector
> state after resume (without explicit trigger from user-space). It
> might return 'unknown' for some time, but once it was refreshed, it
> should send out a uevent and the correct state should now be read. And
> logind works fine with this behavior.
> 
> Anyway, I'm not sure why your machine doesn't work that way. I cannot
> see the problems here on my machine.

Yes there seems to be something amiss with the reprobing. Does the below
kernel patch help?
-Daniel

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 04203c0d2ecb..aa0fae2f24d1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -497,10 +497,6 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
 	mutex_lock(&dev->mode_config.mutex);
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
 
-		/* Only handle HPD capable connectors. */
-		if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
-			continue;
-
 		old_status = connector->status;
 
 		connector->status = connector->funcs->detect(connector, false);
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
