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] drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo
Date: Tue, 24 Apr 2012 17:37:56 +0200	[thread overview]
Message-ID: <20120424153756.GB2017@phenom.ffwll.local> (raw)
In-Reply-To: <1335280337_38538@CP5-2952>

On Tue, Apr 24, 2012 at 04:11:43PM +0100, Chris Wilson wrote:
> On Tue, 24 Apr 2012 15:41:37 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > the only places we actually need the crtc timings is in the mode_set
> > function.
> > 
> > So we can now safely rip out all the remaining calls to set_crtcinfo
> > left in the driver and clean up this confusion.
> 
> I have a little flicker of doubt because these tend to end up being
> passed into the core drm as well as used during modeset. Even looking
> through the instances of drm_mode_set_crtcinfo() in the core, I'm left
> no the wiser as to which functions expect crtc_* to be filled in. As far
> I can see the only place where set_crtcinfo() must be called is prior to
> the final modeset, and so the crtc_* values are only ever used on the
> adjusted_mode. Hence why the drm usage leaves me slightly puzzled.

I guess the idea of the drm core is that every time it creates a drm mode,
it also sets the timings. But afaics it never uses them, safe for the
precise vblank timestamp code (but that can only run on active modes, i.e.
after our mode_fixup functions have been called). The problem is that drm
core always sets CRTC_INTERLACE_HALVE_V, so the timings are pretty much
bogus for us anyway (at least with interlaced support).

So I guess it's the drivers job that every active modes needs to have crtc
timings that suits it, and with these patches we should have that. drm
core doesn't seem to care about modes that just get passed around.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-04-24 15:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 13:41 [PATCH] drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo Daniel Vetter
2012-04-24 15:11 ` Chris Wilson
2012-04-24 15:37   ` Daniel Vetter [this message]
2012-05-03 14:26     ` Chris Wilson
2012-05-03 13:51       ` Daniel Vetter
2012-05-04  9: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=20120424153756.GB2017@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.