Re: [PATCH 01/12] drm/i915: Grab the pixel clock from adjusted_mode not requested_mode

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Sep 03, 2013 at 03:08:50PM +0300, Ville Syrjälä 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älä 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älä <ville.syrjala@linux.intel.com>
> > > > > 
> > > > > 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älä <ville.syrjala@linux.intel.com>
> > > > > ---
> > > > >  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/drm/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 data
> > 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 broken
> > Chris' ilk+sdvo machine a few times in the process of getting this fleshed
> > 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