1. 10 Jun, 2013 3 commits
  2. 07 Jun, 2013 8 commits
  3. 06 Jun, 2013 19 commits
  4. 05 Jun, 2013 5 commits
  5. 04 Jun, 2013 5 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