All of lore.kernel.org
 help / color / mirror / Atom feed
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:01:02 +0200	[thread overview]
Message-ID: <20120812200102.GJ5575@phenom.ffwll.local> (raw)
In-Reply-To: <1344800880_81295@CP5-2952>

On Sun, Aug 12, 2012 at 08:47:56PM +0100, Chris Wilson wrote:
> On Sun, 12 Aug 2012 19:27:07 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Hi all,
> > 
> > I've noticed that a few prep patches of the modeset rework series haven't been
> > merged nor reviewed yet, so I've split them out in this resend. Mostly concern
> > really old gen2 stuff (dvo + pipe A quirk), but little patches in other areas.
> > 
> > Comments&review highly welcome.
> > 
> > Thanks, Daniel
> > 
> > Daniel Vetter (7):
> >   drm/i915: add missing gen2 pipe A quirk entries
> 
> I remain dubious whether the 855gm entry is genuine.

Ok, since we don't have a bug to support this, I'll drop it again.

> >   drm/i915/ns2501: kill pll A enabling hack
> >   drm/i915: rip out the overlay pipe A workaround
> 
> Look fine and a welcome reduction in code + confusion.
> 
> >   drm/i915: prepare load-detect pipe code for dpms changes
> 
> It is not immediately obvious from the function that there is a
> relationship between the connector and intel_encoder.  If we derived the
> encoder from the connector in that function, the reviewer's life gets a
> little easier. As it stands the code looks correct and rightly removes
> some internal details.

Hm, good point. I'll add a patch on top that drops the intel_encoder
argument (since it's redudant, all callers get it with
intel_attached_encoder). Or better if I squash it together with this one?

> >   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.

> >   drm/i915: kill a few unused things in dev_priv
> 
> +1
> 
> >   drm/i915: extract ironlake_fdi_pll_disable
> 
> Smaller more descriptive functions, what is not to like.
> 
> 2-7: Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> You can have an r-b for 1 if you drop the 855gm chunk. Then get someone
> else to a-b the 855gm entry :)

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-08-12 20:00 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 [this message]
2012-08-12 20:12     ` Chris Wilson
2012-08-12 20:26       ` Daniel Vetter
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=20120812200102.GJ5575@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 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.