All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/6] drm/i915: enable VT switchless resume v2
Date: Tue, 26 Mar 2013 08:35:45 -0700	[thread overview]
Message-ID: <20130326083545.7ec9c0d9@jbarnes-desktop> (raw)
In-Reply-To: <20130326121448.GS9021@phenom.ffwll.local>

On Tue, 26 Mar 2013 13:14:48 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Mar 19, 2013 at 06:13:09PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 19, 2013 at 5:56 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >> > I think it just needs to be a low level call to crtc disable on each
> > >> > pipe, otherwise we'll zap the state we're trying to save.
> > >>
> > >> That just reminded me that we also should restore the right dpms state
> > >> I think. At least I'm not too sure whether we'll currently do that
> > >> (and whether the modeset state tracker would catch it). Otoh dpms
> > >> standby/suspend died with gen4 ;-)
> > >
> > > Hm yeah haven't tested that at all.  One typical kind of suspend will
> > > happen after DPMS off when the machine has been idle for some period.
> > > When it comes back up the user will probably want to see the display.
> > > But we don't have to enforce that on the kernel side; we can leave it
> > > to userspace.
> > 
> > Note that this isn't about dpms state in general, we'll take care of
> > that. The problem is with intermediate dpms levels, which requires us
> > to keep the pipe partially running. If you force-restore such a thing
> > we'll end up at dpms ON. Which isn't quite what we want.
> > 
> > Otoh it's old hw, so I don't think we need to spill too many brain
> > cycles on this issue. But if we do fix it, I think we should implement
> > proper support to read out that hw state and cross-check it -
> > otherwise it's pretty much guaranteed to be broken.
> 
> Ajax just submitted a patch to fix restoring of intermediate dpms levels,
> so we should be good here. Another idea for safe/restore around suspend
> which should just work is loop over all connectors and adjust the dpms
> state (and safe just that piece somewhere). That way we get nice implicit
> coverag of our dpms code while doing suspends and suspend doesn't need
> anything in addition infrastructure wise.
> 
> The only downside is that we need to make the power wells stuff work with
> dpms, too. But that's a requirement, anyway.
> 
> Now the real reason for writing this mail: 3.10 feature merge is drawing
> to a close (in about a month I think) and imo we should get switchless
> resume in a few weeks ahead. That way we can give it a decent beating
> before it reaches Linus' upstream git. And I like switchless resume a lot.
> 
> So what's your plan here?

What's left?  Just dealing with the shut down at suspend time (so that
suspend testing and RTD3 works) and Paulo's issue?

I'm not sure what to do about the latter, but I can spin up a new patch
with the shutdown bits in place.

-- 
Jesse Barnes, Intel Open Source Technology Center

  reply	other threads:[~2013-03-26 15:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-19 20:11 VT switchless suspend/resume Jesse Barnes
2013-02-19 20:11 ` [PATCH 1/6] drm/i915: don't restore LVDS enable state blindly v2 Jesse Barnes
2013-02-19 20:39   ` Paulo Zanoni
2013-02-19 21:35     ` Daniel Vetter
2013-02-19 20:11 ` [PATCH 2/6] drm/i915: add sprite restore function v3 Jesse Barnes
2013-02-19 20:11 ` [PATCH 3/6] drm/i915: restore cursor and sprite state when forcing a config restore Jesse Barnes
2013-02-19 20:11 ` [PATCH 4/6] drm/i915: enable VT switchless resume v2 Jesse Barnes
2013-03-18  7:49   ` Daniel Vetter
2013-03-18 17:42     ` Jesse Barnes
2013-03-18 18:50       ` Daniel Vetter
2013-03-19 16:56         ` Jesse Barnes
2013-03-19 17:13           ` Daniel Vetter
2013-03-26 12:14             ` Daniel Vetter
2013-03-26 15:35               ` Jesse Barnes [this message]
2013-02-19 20:11 ` [PATCH 5/6] drm/i915: emit a hotplug event on resume Jesse Barnes
2013-02-19 20:11 ` [PATCH 6/6] drm/i915: remove disabled memset of framebuffer from intel_fb Jesse Barnes
2013-02-19 21:17   ` Paulo Zanoni
2013-03-04 22:04     ` Daniel Vetter
2013-02-19 21:25 ` VT switchless suspend/resume Paulo Zanoni
2013-02-25 19:19   ` Paulo Zanoni
2013-02-25 21:31     ` Jesse Barnes
2013-03-07 16:38       ` Jesse Barnes
  -- strict thread matches above, loose matches on Subject: below --
2013-02-15 21:23 VT switchless v3 Jesse Barnes
2013-02-15 21:23 ` [PATCH 4/6] drm/i915: enable VT switchless resume v2 Jesse Barnes

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=20130326083545.7ec9c0d9@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=daniel@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.