Skip to content

L
linux
Switch branch/tag
  1. 07 Jun, 2013 8 commits
  3. 06 Jun, 2013 19 commits
  5. 05 Jun, 2013 5 commits
  7. 04 Jun, 2013 8 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7