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>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup
Date: Wed, 30 May 2012 14:51:39 +0200 [thread overview]
Message-ID: <20120530125139.GG6888@phenom.ffwll.local> (raw)
In-Reply-To: <1338380345_356426@CP5-2952>
On Wed, May 30, 2012 at 01:18:35PM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > ... instead of changing mode->clock, which we should leave as-is.
> >
> > We only touch that if it's a panel, and then adjusted mode->clock
> > equals adjusted_mode->clock. Outside of intel_dp.c we only use
> > ajusted_mode->clock in the mode_set functions.
> >
> > Within intel_dp.c we only use it to calculate the dp dithering
> > and link bw parameters, so that's the only thing we need to fix
> > up.
> >
> > As a temporary ugliness (until the cleanup in the next patch) we
> > pass the adjusted_mode into dp_dither for both parameters (because
> > that one still looks at mode->clock).
> >
> > Note that we do overwrite adjusted_mode->clock with the selected dp
> > link clock, but that only happens after we've calculated everything we
> > need based on the dotclock of the adjusted output configuration.
> >
> > v2: Adjust the debug message to also use adjusted_mode->clock.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 11 +++--------
> > 1 file changed, 3 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 296cfc2..a9dffa6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct drm_display_mode *mode,
> > intel_fixed_panel_mode(intel_dp->panel_fixed_mode, adjusted_mode);
> > intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
> > mode, adjusted_mode);
> > - /*
> > - * the mode->clock is used to calculate the Data&Link M/N
> > - * of the pipe. For the eDP the fixed clock should be used.
> > - */
> > - mode->clock = intel_dp->panel_fixed_mode->clock;
>
> But in ironlake_crtc_mode_set() we have:
>
> if (is_cpu_edp) {
> target_clock = mode->clock;
> } else {
> if (is_dp)
> target_clock = mode->clock;
> else
> target_clock = adjusted_mode->clock;
> }
>
> It would seem like eDP would have had mode->clock adjusted previously.
> Similarly PCH eDP uses the adjusted mode->clock in intel_dp_set_m_n().
Well, adjusted_mode->clock after we've run intel_dp_mode_fixup should be
the same in all cases, because we overwrite it with the fixed dp link
clock we're selecting. The target_clock otoh looks more worrisome. I guess
I've managed to not hit this because I don't have an eDP panel (where we
change mode->clock), but still I guess we need to clean this up a bit.
I'll try to come up with a way to avoid this maze.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-05-30 12:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 10:28 [PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup Daniel Vetter
2012-05-30 10:58 ` Chris Wilson
2012-05-30 11:32 ` Daniel Vetter
2012-05-30 11:52 ` [PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup Daniel Vetter
2012-05-30 11:52 ` [PATCH 2/2] drm/i915: don't chnage the original mode in dp_mode_fixup Daniel Vetter
2012-05-30 13:34 ` Paul Menzel
2012-05-30 12:18 ` [PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup Chris Wilson
2012-05-30 12:51 ` Daniel Vetter [this message]
2012-05-30 13:34 ` [PATCH] drm/i915: compute the target_clock for edp directly Daniel Vetter
2012-05-31 9:49 ` Chris Wilson
2012-05-31 10:03 ` Daniel Vetter
2012-05-31 10:31 ` Chris Wilson
2012-05-31 10:49 ` 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=20120530125139.GG6888@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--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.