From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] modeset rework prep patches
Date: Sun, 12 Aug 2012 22:26:17 +0200 [thread overview]
Message-ID: <20120812202617.GK5575@phenom.ffwll.local> (raw)
In-Reply-To: <1344802342_81385@CP5-2952>
On Sun, Aug 12, 2012 at 09:12:14PM +0100, Chris Wilson wrote:
> On Sun, 12 Aug 2012 22:01:02 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Sun, Aug 12, 2012 at 08:47:56PM +0100, Chris Wilson wrote:
> > > > drm/i915: simplify dvo dpms interface
> > >
> > > This just looks like churn for churn's sake? The changes look correct.
> >
> > We don't bother with anything else than dpms on/off states in most of the
> > modeset code (even for crt newer hw drops the intermediate states). Hence
> > the new interfaces have only enable/disable functions at the encoder/crtc
> > level. I've figured it looks odd if we keep the full dpms interface for
> > dvo. But since it's rather independant churn I've moved it into this
> > odds bits series.
>
> The full fledged dpms mode isn't going to completely disappear thanks
> to the CRT dinosaur. I just wonder if we can achieve the same
> simplification by recognising that all non-zero dpms modes are off, e.g.
> s/dpms_mode/powersave/
>
> if (powersave)
> switch_off()
> else
> switch_on()
Yeah, I'm still handling the crt dinosaur (on hw that supports it) in the
modeset rework code. I've just noticed while planning the new modeset code
that we handle these dpms codes rather inconsistently. Hence the code has
grown a simple bool at the encoder level to track the desired state, which
then controls the on/off state of the entire output pipeline (the
additional dpms states of the dinosaur are just a nuisance on top of that
- every state that requires an active pipes force the entire pipe to be
on). This has the advantage that we don't force the pipe on for dpms ==
standby/suspend just in case we have a crt on it - the new code actually
shuts it off if possible.
So with the new code the only thing still even dealing with dpms codes is
at the connector level. And even there it's just crt (and sdvo, if anyone
would fancy writing the patch to enable that ...).
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-08-12 20:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-12 17:27 [PATCH 0/7] modeset rework prep patches Daniel Vetter
2012-08-12 17:27 ` [PATCH 1/7] drm/i915: add missing gen2 pipe A quirk entries Daniel Vetter
2012-08-12 19:19 ` [PATCH] " Daniel Vetter
2012-08-12 17:27 ` [PATCH 2/7] drm/i915/ns2501: kill pll A enabling hack Daniel Vetter
2012-08-12 17:27 ` [PATCH 3/7] drm/i915: rip out the overlay pipe A workaround Daniel Vetter
2012-08-12 17:27 ` [PATCH 4/7] drm/i915: prepare load-detect pipe code for dpms changes Daniel Vetter
2012-08-12 19:20 ` [PATCH] drm/i915: drop intel_encoder argument to load_detect_pipe functions Daniel Vetter
2012-08-12 17:27 ` [PATCH 5/7] drm/i915: simplify dvo dpms interface Daniel Vetter
2012-08-12 17:27 ` [PATCH 6/7] drm/i915: kill a few unused things in dev_priv Daniel Vetter
2012-08-12 17:27 ` [PATCH 7/7] drm/i915: extract ironlake_fdi_pll_disable Daniel Vetter
2012-08-12 19:47 ` [PATCH 0/7] modeset rework prep patches Chris Wilson
2012-08-12 20:01 ` Daniel Vetter
2012-08-12 20:12 ` Chris Wilson
2012-08-12 20:26 ` Daniel Vetter [this message]
2012-08-13 20:14 ` 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=20120812202617.GK5575@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).