All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 3/8] drm/i915: extract set_pipe_timings from ironlake_crtc_mode_set
Date: Thu, 20 Sep 2012 09:32:41 +0200	[thread overview]
Message-ID: <20120920073241.GA2844@bremse> (raw)
In-Reply-To: <CA+gsUGQ3vBVgj+2D49hN7TVHKyd+szAn8rwov6z3qH35zAxm_w@mail.gmail.com>

On Wed, Sep 19, 2012 at 03:11:33PM -0300, Paulo Zanoni wrote:
> Hi
> 
> 2012/9/12 Daniel Vetter <daniel@ffwll.ch>:
> > On Wed, Sep 12, 2012 at 10:06:31AM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >>
> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >
> > Hm, I think we should extract the same code from i9xx_crtc_set_mode, too
> > and share it in a common intel_set_pipe_timings. Their almost identical
> > safe for:
> > - vsyncshift is only gen4+
> 
> This is easy to solve.
> 
> > - source position handling is a bit different, but I think it'd be
> >   semantically clearer if we leave that out of set_pipe_timings. Imo that
> >   belongs to the panel fitter settings, which are currently splattered all
> >   over. Meh.
> 
> Well, the PIPESRC register is described inside the "pipe timings"
> documentation section, so I think it should be inside the
> set_pipe_timings function.
> 
> I actually implemented your suggestion locally and the only real
> problem is that on i9xx_crtc_mode_set we currently write to DSPSIZE
> and DSPPOS before writing to PIPESRC, so to make the code look good we
> have 2 options:
> 1 - Write to DSPPOS and DSPSIZE before writing all the timing registers
> 2 - Write to DSPPOS and DSPSIZE after writing all the timing registers
> 
> In both cases we are changing the writing order. I looked at the
> documentation and it seems we should be writing to the plane registers
> only after setting the pipe registers, so maybe solution 2 is the
> correct. The problem is that yes, we are changing the behavior and I
> don't even have such machines to test.
> 
> So, how do we proceed here? Want the version, keep the old one, or do
> something entirely different?

I guess a quick patch to move around the DSP* regs down and run it on a
few gen2/3 machines. Then move things around if it doesn't blow up. Since
I'm travelling I think you need to volunteer Chris for the testing ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2012-09-20  7:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 13:06 [PATCH 0/8] Rework ironlake_crtc_mode_set Paulo Zanoni
2012-09-12 13:06 ` [PATCH 1/8] drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set Paulo Zanoni
2012-09-12 14:03   ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 2/8] drm/i915: extract LVDS-specific code from ironlake_crtc_mode_set Paulo Zanoni
2012-09-12 13:56   ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 3/8] drm/i915: extract set_pipe_timings " Paulo Zanoni
2012-09-12 14:11   ` Daniel Vetter
2012-09-19 18:11     ` Paulo Zanoni
2012-09-20  7:32       ` Daniel Vetter [this message]
2012-09-12 13:06 ` [PATCH 4/8] drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set Paulo Zanoni
2012-09-12 14:12   ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 5/8] drm/i915: extract set_m_n from ironlake_crtc_mode_set Paulo Zanoni
2012-09-12 14:20   ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 6/8] drm/i915: extract compute_clocks " Paulo Zanoni
2012-09-12 14:31   ` Daniel Vetter
2012-09-12 14:34     ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 7/8] drm/i915: extract pch_pll_set " Paulo Zanoni
2012-09-12 14:40   ` Daniel Vetter
2012-09-18 20:18     ` Paulo Zanoni
2012-09-19  9:17       ` Daniel Vetter
2012-09-12 13:06 ` [PATCH 8/8] drm/i915: remove unused variables " Paulo Zanoni

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=20120920073241.GA2844@bremse \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@gmail.com \
    /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.