From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 01/12] drm/i915: Grab the pixel clock from adjusted_mode not requested_mode Date: Tue, 3 Sep 2013 15:45:33 +0200 Message-ID: <20130903134533.GH5767@phenom.ffwll.local> References: <1378145619-22655-1-git-send-email-ville.syrjala@linux.intel.com> <1378145619-22655-2-git-send-email-ville.syrjala@linux.intel.com> <20130902183816.GA9374@phenom.ffwll.local> <20130903100114.GE11428@intel.com> <20130903112323.GF5767@phenom.ffwll.local> <20130903120850.GH11428@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 51ADFE61C0 for ; Tue, 3 Sep 2013 06:45:20 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so3010036ead.17 for ; Tue, 03 Sep 2013 06:45:18 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20130903120850.GH11428@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, Sep 03, 2013 at 03:08:50PM +0300, Ville Syrj=E4l=E4 wrote: > On Tue, Sep 03, 2013 at 01:23:23PM +0200, Daniel Vetter wrote: > > On Tue, Sep 03, 2013 at 01:01:14PM +0300, Ville Syrj=E4l=E4 wrote: > > > On Mon, Sep 02, 2013 at 08:38:16PM +0200, Daniel Vetter wrote: > > > > On Mon, Sep 02, 2013 at 09:13:28PM +0300, ville.syrjala@linux.intel= .com wrote: > > > > > From: Ville Syrj=E4l=E4 > > > > > = > > > > > intel_crtc_compute_config() and i9xx_set_pipeconf() attempt to get > > > > > the current pixel clock from requested_mode. requested_mode.clock= may > > > > > be totally bogus, so the clock should come from adjusted_mode. > > > > > = > > > > > Signed-off-by: Ville Syrj=E4l=E4 > > > > > --- > > > > > drivers/gpu/drm/i915/intel_display.c | 5 ++--- > > > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > = > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/d= rm/i915/intel_display.c > > > > > index ecb8b52..cab1319 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > > > @@ -4124,8 +4124,7 @@ static int intel_crtc_compute_config(struct= intel_crtc *crtc, > > > > > = > > > > > if (HAS_PCH_SPLIT(dev)) { > > > > > /* FDI link clock is fixed at 2.7G */ > > > > > - if (pipe_config->requested_mode.clock * 3 > > > > > - > IRONLAKE_FDI_FREQ * 4) > > > > > + if (adjusted_mode->clock * 3 > IRONLAKE_FDI_FREQ * 4) > > > > = > > > > Note quite: The fdi dotclock is the adjusted mode's clock but with = the > > > > pixel multiplier _not_ taken into account. See > > > > ironlake_fdi_compute_config. Maybe we need a fdi_dotclock_from_pipe= _config > > > > helper function? > > > = > > > Dang those pixel multipliers. I need to study on the topic a bit more. > > > I'm confused whether the pipe is actually pushing out pixels at the > > > non-multiplied rate or the multiplied rate. That's an important detail > > > when we consider the CDCLK vs. pipe pixel rate limitations. > > = > > On pch ports the pixel multiplier is in the pch dpll, so I think the da= ta > > pushed over the fdi link isn't multiplied. Iirc I've even bothered with > > some tests, but not sure any more ... I vaguely remember that I've brok= en > > Chris' ilk+sdvo machine a few times in the process of getting this fles= hed > > out ;-) > = > Right, so at least on SDVO the multiplier is added to keep the SDVO > clock on the above 100 MHz. So the multiplier won't actually affect > the pixel clock. > = > So could we just make port_clock be the multiplied clock for SDVO > and make adjusted_mode.clock be the actual pixel clock? There's also the pixel multiplier thing for hdmi and I'm not sure how it works there. But generally I think using the port clock with the pixel multiplier but excluding it from the adjusted mode is a sensible approach. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch