From: Chris Wilson <chris@chris-wilson.co.uk>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: don't disable disconnected outputs
Date: Fri, 12 Oct 2012 10:02:05 +0100 [thread overview]
Message-ID: <453bf0$626hb2@azsmga001.ch.intel.com> (raw)
In-Reply-To: <1349977587-7534-1-git-send-email-daniel.vetter@ffwll.ch>
On Thu, 11 Oct 2012 19:46:27 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> This piece of neat lore has been ported painstakingly and bug-for-bug
> compatible from the old crtc helper code.
>
> Imo it's utter nonsense.
>
> If you have disconnect a cable and before you reconnect it, userspace
> (or the kernel) does an set_crtc call, this will result in that
> connector getting disable. Which will result in a nice black screen
> when plugging in the cable again.
>
> There's absolutely no reason the kernel does such policy changes - if
> userspace tries to set up a mode on something disconnected we might
> fail loudly (since the dp link training fails), but silently adjusting
> the output configuration behind userspace's back is a recipe for
> disaster. Specifically I think that this could explain some of our
> MI_WAIT hangs around suspend, where userspace issues a scanline wait
> on a disable pipe. This mechanisims here could explain how that pipe
> got disabled without userspace noticing.
Indeed, it might just explain all those funky disables on other crtc
after a setcrtc.
Won't a side effect of this be that the system continues to power a
disconnected output if userspace is asleep and fails to notice the
disconnect?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-10-12 9:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 17:46 [PATCH] drm/i915: don't disable disconnected outputs Daniel Vetter
2012-10-12 9:02 ` Chris Wilson [this message]
2012-10-12 9:13 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2012-12-18 8:37 Daniel Vetter
2012-12-18 11:58 ` Rodrigo Vivi
2012-12-18 16:56 ` [Intel-gfx] " Jesse Barnes
2012-12-18 20:33 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='453bf0$626hb2@azsmga001.ch.intel.com' \
--to=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.