1. 05 Jun, 2013 2 commits
  2. 04 Jun, 2013 10 commits
    • Daniel Vetter's avatar
      drm/i915: check for strange pfit pipe assignemnt on ivb/hsw · cb8b2a30
      Daniel Vetter authored
      Panel fitters on ivb/hsw are not created equal since not all of them
      support the new high-quality upscaling mode. To offset this the hw
      allows us to freely assign the pfits to pipes.
      
      Since our code currently doesn't support this we might fall over when
      taking over firmware state. So check for this case and WARN about it.
      We can then improve the code once we've hit this in the wild. Or once
      we decide to support the improved upscale modes, though that requires
      global arbitrage of modeset resources across crtcs.
      
      v2: Check for IS_GEN7 instead of IS_IVB || IS_HSW as suggested by
      Paulo in his review comment.
      Suggested-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cb8b2a30
    • Daniel Vetter's avatar
      drm/i915: Drop some no longer required mode/adjusted_mode parameters · 8a654f3b
      Daniel Vetter authored
      We can get at this easily through intel_crtc->config now.
      
      v2: Drop more stuff gcc spotted.
      
      v3: Drop even more stuff gcc spotted.
      
      v4: Yet more ...
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8a654f3b
    • Daniel Vetter's avatar
      drm/i915: store adjusted dotclock in adjusted_mode->clock · ff9a6750
      Daniel Vetter authored
      ... not the port clock. This allows us to kill the funny semantics
      around pixel_target_clock.
      
      Since the dpll code still needs the real port clock, add a new
      port_clock field to the pipe configuration. Handling the default case
      for that one is a bit tricky, since encoders might not consistently
      overwrite it when retrying the crtc/encoder bw arbitrage step in the
      compute config stage. Hence we need to always clear port_clock and
      update it again if the encoder hasn't put in something more specific.
      This can't be done in one step since the encoder might want to adjust
      the mode first.
      
      I was a bit on the fence whether I should subsume the pixel multiplier
      handling into the port_clock, too. But then I decided against this
      since it's on an abstract level still the dotclock of the adjusted
      mode, and only our hw makes it a bit special due to the separate pixel
      mulitplier setting (which requires that the dpll runs at the
      non-multiplied dotclock).
      
      So after this patch the adjusted_mode accurately describes the mode we
      feed into the port, after the panel fitter and pixel multiplier (or
      line doubling, if we ever bother with that) have done their job.
      Since the fdi link is between the pfit and the pixel multiplier steps
      we need to be careful with calculating the fdi link config.
      
      v2: Fix up ilk cpu pll handling.
      
      v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
      to make it clearer that we transmit the adjusted_mode without the
      pixel multiplier taken into account. The old code multiplied the the
      available link bw with the pixel multiplier, which results in the same
      fdi configuration, but is much more confusing.
      
      v4: Rebase on top of Imre's is_cpu_edp removal.
      
      v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
      a new place which looked at the pixel_clock and so needed conversion.
      
      v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
      on top of the fdi dotclock handling fix in the fdi lanes/bw
      computation code.
      
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ff9a6750
    • Daniel Vetter's avatar
      drm/i915: refactor cpu eDP PLL handling a bit · 7c62a164
      Daniel Vetter authored
      This prepares a bit for the next big patch, where we switch the
      semantics of the different clocks in the pipe config around.
      
      Since I've broken cpu eDP PLL handling in the first version I've
      figured some refactoring is in order.
      
      Split out on request from Paulo Zanoni.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7c62a164
    • Daniel Vetter's avatar
      drm/i915: clear up the fdi dotclock semantics for M/N computation · 2bd89a07
      Daniel Vetter authored
      We currently mutliply the link_bw of the fdi link with the pixel
      multiplier, which is wrong: The FDI link doesn't suddenly grow more
      bandwidth. In reality the pixel mutliplication only happens in the PCH,
      before the pixels are fed into the port.
      
      But since we our code treats the uses the target clock after pixels
      are doubled (tripled, ...) already, we need to correct this.
      
      Semantically it's clearer to divide the target clock to get the fdi
      dotclock instead of multiplying the bw, so do that instead.
      
      Note that the target clock is already multiplied by the same factor,
      so the division will never loose accuracy for the M/N computation.
      
      The lane computation otoh used the wrong value, we also need to feed
      the fdi dotclock to that.
      
      Split out on a request from Paulo Zanoni.
      
      v2: Also fix the lane computation, it used the target clock to compute
      the bw requirements, not the fdi dotclock (i.e. adjusted with the
      pixel multiplier). Since sdvo only uses the pixel multiplier for
      low-res modes (with a dotclock below 100MHz) we wouldn't ever have
      rejected a bogus mode, but just used an inefficient fdi config.
      
      v3: Amend the commit message to explain better what the change for the
      fdi lane config computation is all about. Requested by Paulo.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2bd89a07
    • Daniel Vetter's avatar
      drm/i915: fold in IS_PNV checks from the split up find_dpll functions · c0efc387
      Daniel Vetter authored
      Since I stand by my rule that splitting functions should only do an
      exact copy, this is a follow-up patch.
      Suggested-by: default avatarPaulo Zanoni <przanoni@gmail.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c0efc387
    • Daniel Vetter's avatar
      drm/i915: move find_pll callback to dev_priv->display · ee9300bb
      Daniel Vetter authored
      Now that the DP madness is cleared out, this is all only per-platform.
      So move it out from the intel clock limits structure.
      
      While at it drop the intel prefix on the static functions, call the
      vtable entry find_dpll (since it's for the display pll) and rip out
      the now unnecessary forward declarations.
      
      Note that the parameters of ->find_dpll are still unchanged, but they
      eventually need to be moved over to just take in a pipe configuration.
      But currently a lot of things are still missing from the pipe
      configuration (reflock, output-specific dpll limits and preferences,
      downclocked dotclock). So this will happen in a later step.
      
      Note that intel_g4x_limit has a peculiar case where it selects
      intel_limits_i9xx_sdvo as the limit. This is pretty bogus and also not
      used since the only output types left are DP and native TV-out which
      both use special pre-tuned dpll values.
      
      v2: Re-add comment for the find_pll callback (requested by Paulo) and
      elaborate on why the transformation is correct for g4x platforms (to
      clarify a review question from Paulo). Double up on that by adding a
      WARN as suggested by Paulo Zanoni on irc.
      
      v3: Initialize limits to NULL since gcc is now unhappy.
      
      v4: v2/3 will blow up with a NULL dereference in ->find_dpll for dp and
      TV-out ports, spotted by Paulo on irc. So just give up on this madness for
      now, and leave this to be fixed in a later patch.
      
      v5: Since the ever-so-slight change for g4x might result in some dpll
      parameter computation failing spuriously where before it didn't for
      ports with preset dpll settings (DP & TV-out) override this. For
      paranoia also do it in the ilk+ code.
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ee9300bb
    • Daniel Vetter's avatar
      drm/i915: split out intel_pnv_find_best_PLL · ac58c3f0
      Daniel Vetter authored
      Pineview is just different.
      
      Also split out i9xx_clock from intel_clock and drop the now redundant
      struct device * parameter.
      
      Note that in this patch I kill an XXX comment about 100MHz clocks. I
      couldn't figure out what this is about, and we don't seem to have any
      bug reports about this either. I suspect that it's a remnant from when
      the i9xx and ilk+ modeset code was all in the same file since ilk+
      does indeed have a 100MHz clock. So I've just killed it to stop the
      cargo-culting.
      Reviewed-by: default avatarPaulo Zanoni <przanoni@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ac58c3f0
    • Daniel Vetter's avatar
      drm/i915: fix EDID/sink-based bpp clamping · 1b829e05
      Daniel Vetter authored
      Since this is run in the compute config stage we need to check
      the new_ pointers, i.e the stage output routing, not the current
      modeset layout. Also there was a little logic bug in properly skipping
      connectors: The old code did not skip any unused connectors and so
      clamped to whatever was left in there (usually 0 if that connector
      hasn't seen a EDID 1.4 screen ever since boot-up).
      
      This has been broken when moving the pipe bpp selection in
      
      commit 4e53c2e0
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Mar 27 00:44:58 2013 +0100
      
          drm/i915: precompute pipe bpp before touching the hw
      
      To avoid too much casting switch from drm_ to intel_ types.
      
      Also add a bit of debug output to help reconstructing what's going
      on.
      
      v2: Try to clarify this a bit:
      - s/pipe_config_set_bpp/compute_baseline_pipe_bpp/ to make it clearer
        at which stage this function is run. Also add a comment about what
        it does.
      - Extract the sink clamping into it's own function.
      
      v3: Actually make it compile.
      
      v4: Split out all the prep refactoring to make the bugfix stick out
      really badly. Also elaborate a bit in the commit message about the
      nature of the bugfix.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1b829e05
    • Daniel Vetter's avatar
      drm/i915: refactor sink bpp clamping · 050f7aeb
      Daniel Vetter authored
      As a prep work to fix it up:
      - Use intel_connector instead of drm_connector to avoid too much
        upcasting in the bugfix patch.
      - Extract the connector bpp clamping from the loop-over-connectors
        logic.
      - Bikeshed function names (to make it clearer that
        acompute_baseline_pipe_bpp runs in the compute stage of the modeset
        sequence) and add a comment to make it clearer what it does.
      
      No functional change in this patch.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      050f7aeb
  3. 03 Jun, 2013 10 commits
  4. 31 May, 2013 18 commits