Since I'll need to modify i915_gem_object_bind_to_gtt(), fix the errors
now to get checkpatch to not complain.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Chris' improved debug output, and
bikeshed the new variable with s/max/gtt_max/ a bit while at it.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Found with kmemleak.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In preparation to track per ring progress in hangcheck,
add i915_hangcheck_ring_hung.

v2: omit dev parameter (Ben Widawsky)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of relying in acthd, track ring seqno progression
to detect if ring has hung.

v2: put hangcheck stuff inside struct (Chris Wilson)

v3: initialize hangcheck.seqno (Ben Widawsky)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In preparation for next commit, pass seqno as a parameter
to i915_hangcheck_ring_idle as it will be used inside
i915_hangcheck_elapsed.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On Haswell, whenever we change the sprites we need to completely
recalculate all the watermarks, because the sprites are one of the
parameters to the LP watermarks, so a change on the sprites may
trigger a change on which LP levels are enabled.

So on this commit we store all the parameters we need to store for
proper recalculation of the Haswell WMs and then call
haswell_update_wm.

Notice that for now our haswell_update_wm function is not really using
these parameters we're storing, but on the next commits we'll use
these parameters.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because we want to call it from the "sprite disable" paths, since on
Haswell we need to update the sprite watermarks when we disable
sprites.

For now, all this patch does is to add the "enable" argument and call
intel_update_sprite_watermarks from inside ivb_disable_plane. This
shouldn't change how the code behaves because on
sandybridge_update_sprite_wm we just ignore the "!enable" case. The
patches that implement Haswell watermarks will make use of the changes
introduced by this patch.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We never check the return values, and there's not much we could do on
errors anyway. Just simplify the signatures. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rename all VLV IOSF sideband register accessor functions to
vlv_<port>_{read,write}. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The lower level sideband read/write functions already do this.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Both the intel_dpio_{read,write} and valleyview_{punit,nc}_{read,write}
use the IOSF sideband interface. They access the same registers and do
mostly the same stuff, but no shared code. There are even duplicate
register defines for the same registers. Both have locking, but the
former use dpio_lock and the latter rps.hw_lock. It's racy.

This patch refactors the sideband access to a single function that
expects dpio_lock to be held. The dpio_lock is only used for sideband
stuff, so it's a better match than rps.hw_lock for the purpose. The rps
stuff still needs rps.hw_lock, since it's used to protect more than just
the register access, so rps code will need to hold both locks.

Based on the work by Shobhit Kumar <shobhit.kumar@intel.com> and Yogesh
Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Group both the HSW/LPT SBI interface and VLV IOSF sideband register
accessor functions into a new file. No functional changes.

v2: also move intel_sbi_{read,write} (Daniel)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sometimes when user is trying to get error state out from
debugfs after gpu hang, the memory is low and/or fragmented
enough that kmalloc in seq_file will fail.

Prevent big kmalloc by avoiding seq_file and instead convert
error state to string in smaller chunks.

v2: better alloc flags, better truncate, correct
locking, and error handling improvements (Chris Wilson)

v3: printf annotations (Daniel Vetter)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In commit 25ff1195
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Apr 4 21:31:03 2013 +0100

    drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

we introduced an empirical workaround for memory corruption when using
fences from multiple CPUs. At the time, we did not have any results for
Valleyview, so the presumption was that it was limited to recent
generations using LLC. Now we have evidence that Valleyview also suffers
incoherence and requires a similar but different workaround. For
Valleyview, the wbinvd instruction is insufficient and we require the
serialising register write per-CPU. Conversely, that serialising
register write is not enough for SNB/IVB/HSW. To compromise and keep the
code relatively clean, employ both serialisation techniques in the same
workaround.
Reported-by: NJon Bloomfield <jon.bloomfield@intel.com>
Tested-by: NJon Bloomfield <jon.bloomfield@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

WARN_ON(!spin_is_locked()) is not a good idea on a UP system w/o
spinlock debugging. Use WARN_ON_SMP() instead.

This check has been added in

commit 8ba2d185
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Apr 12 15:18:37 2013 +0300

    drm/i915: protect backlight registers and data with a spinlock
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should help debugging the truly unexpected cases where it occurs -
in particular to see which value is garbage.

References: https://bugzilla.kernel.org/show_bug.cgi?id=58511Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: s/%ld/%zd/ as spotted by Wu Fengguang's autobuilder.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 1544d9d5 added a workaround
inside haswell_init_clock_gating and mentioned it is "a workaround for
early silicon revisions and should be removed later". This workaround
is documented in bit 31 of PRI_CTL. I asked Arthur and he mentioned
that setting FORCE_ARB_IDLE_PLANES replaces that workaround for the
newer machines. So use the new one.

Also notice that there's still another workaround for PRI_CTL that
involves WM_DBG, but it's not the one we're reverting. And notice that
we were previously setting WM_DBG_DISALLOW_MULTIPIPE_LP which disables
the LP watermarks when more than one pipe is used, and we really don't
want this because we need the LP watermarks if we want to reach deeper
PC states.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a comment for the w/a name Ville dug out of Bspec.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And the SNB_READ_WM0_LATENCY macro is not valid anymore because we
have the "New WM0" at 63:56, so the "Old WM0" could maybe be zero if
the new one is not zero.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove the "placeholder" comment and set the actual value described by
the specification. We still don't enable IPS, but it won't hurt to
already have the value set here.

While at it, fully set the register value instead of just masking the
values we're changing.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With this, that 338 can finally become the correct 337500.

Due to the change we need to adjust the intel_dp_aux_ch function to
set the correct value, so adjust the division and also use
DIV_ROUND_CLOSEST instead of the old "round down" behavior because the
spec says the value "should be programmed to get as close as possible
to the ideal rate of 2MHz".

Quoting Paulo's follow-up to a question from Chris Wilson to explain
what exactly will change:

I use the 337500 value on the next patch, when setting the
ips_linetime value. The correct frequency is 337500, not 338000.

ips_linetime = DIV_ROUND_CLOSEST(mode->htotal * 1000 * 8,
intel_ddi_get_cdclk_freq);
For a mode with htotal of 2640 [0] we'll have: (i) (2640 * 1000 * 8) /
338000 = 62.48, resulting in 62 and (ii) (2640 * 1000 * 8) / 337500 =
62.57 resulting in 63.

For the case inside intel_dp.c:
Previously we were using 338. So with the old formula we were writing
338/2 = 169 to the register. And 337500 / 169 = 1997.04 (we use 337500
here because it's the real clock value). With the new value of
337500/2000 we'll have 168.75, which is 168 on the round-down case and
169 on the round-closest case. If we write 168 to the register, 337500
/ 168 = 2008.92, and 2008.92 is more distant from 2000 than 1997.04.
So with this patch we're changing the formula but still writing the
same correct value to the DP AUX register.

[0]: That's 1920x1080@50Hz on my DP monitor.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp the commit message with Paulo's follow-up.]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the "*8"  calculation to the left side so we don't propagate
rounding errors. Also use DIV_ROUND_CLOSEST because that's what the
spec says we need to do.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... instead of mode->crtc_display. The spec says "pipe horizontal
total number of pixels" and the "Haswell Watermark Calculator" tool
uses the "Pipe H Total" instead of "Pipe H Src" as the value.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The spec says the linetime watermarks must be programmed before
enabling any display low power watermarks, but we're currently
updating the linetime watermarks after we call intel_update_watermarks
(and only at crtc_mode_set, not at crtc_{enable,disable}). So IMHO the
best way guarantee the linetime watermarks will be updated before the
low power watermarks is inside the update_wm function, because it's
the function that enables low power watermarks. And since Haswell is
the only platform that has linetime watermarks, let's completely kill
the "intel_update_linetime_watermarks" abstraction and just use the
intel_update_watermarks abstraction by creating haswell_update_wm.

For now haswell_update_wm is still calling sandybridge_update_wm, but
in the future I plan to implement a function specific to Haswell.

v2: - Rename patch
    - Disable LP watermarks before changing linetime WMs (Chris)
    - Add a comment explaining that this is just temporary code.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So don't call intel_update_linetime_watermarks from
ironlake_crtc_mode_set. Only Haswell has these watermarks.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can use this for fetching encoder specific pipe_config state, like
mode flags, adjusted clock, etc.

Just used for mode flags atm, so we can check the pipe config state at
mode set time.

v2: get_config when checking hw state too
v3: fix DVO and LVDS mode flags (Ville)
    get SDVO DTD for flag fetch (Ville)
v4: use input timings (Ville)
    correct command used (Ville)
    remove gen4 check (Ville)
v5: get DDI flag config too
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4)
Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch add dvo detection for the Chrontel 7010B on some old hardware.

References: https://bugzilla.kernel.org/show_bug.cgi?id=55101
Signed-off-by: Braggle <braggle at free.fr>
[danvet: Fix up whitespace mangling.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Allows us to rip out a few fragile checks (which are duplicated in the
hw state readout now, too). Also prepares us a bit for more than one
panel/pfit.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No more need to guard the write with a power well check on Haswell now
that we have proper pfit state readout: We can simply only clear the
pfit if it's actually on.

This removes some duplication of knowledge between the haswell pfit
disable and pfit state readout code about.

While at it extract a little helper for this.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pfit state readout is a bit ugly on gen2/3 due to the intermingling
with the lvds state, but alas.

Also note that since state is always cleared to zero we can
unconditonally compare all the state and completely neglect the actual
platform we're running on.

v2: Properly check for the pfit power domain on haswell.

v3: Don't check pgm_ratios on gen4+, they're auto-computed by the hw.

v4: Properly clear the lvds border bits, upset the state checker a
bit.

v5: Unconditionally read out panel dither settings on gen2/3.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should prevent mode set failures on LPT.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Pimp the w/a tag to fit into Damien's new scheme.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There was a race between Rodrigo writing those patches and me
formalizing the addition of platform tags. This patches fixes it.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Somehow this has been forgotten in

commit 1974cad0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 26 17:22:09 2012 +0100

    drm/i915: move is_dual_link_lvds to intel_lvds.c
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Up to now, we were using a static table to match the clock frequency
with a (r2,n2,p) triplet. Despite this table being big, it's by no mean
comprehensive and we had to fall back to the closest frequency when the
requested TMDS clock wasn't in the table.

This patch computes (r2,n2,p) dynamically and get rid of The Big Table.

v2: Replace the floating point constant 1e6 by 1000000

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
[danvet: s/        /^T/]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.

v2: Ville suggested to enable it back when disabling fbc to avoid wasting
    power.

v3: RMW to preserve other bits (by Ville)
v4: Fix from Ville: sed &/| at RMW
v5: Too far on sed.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Insert missing space that checkpatch spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Display register 420B0h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch introduce Frame Buffer Compression (FBC) support for HSW.
FBC is tied to primary plane A in HSW.

v2: Ville pointed out docs say FBC must be disabled before disabling
    the plane on HSW.
v3: Really enabling it by default at HSW.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Display register 42020h bit 9 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.

v2: RMW to preserve other bits (by Ville)
v3: Fix from Ville: sed &/| at RMW
v4: Too far on sed.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Display register 42000h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch introduce Frame Buffer Compression (FBC) support for IVB,
without enabling it by default.
It adds a new function gen7_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_IVYBRIDGE checks.

v2: Fixes from Ville.
     	*  Fix Plane. FBC is tied to primary plane A in HSW
    	*  Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
v4: Ville pointed out that according to BSpec FBC_CTL bits 0:3 must be 0.
v5: Up to v4 this work was entirely focused on Haswell. However Ville
    noticed I could reuse the FBC work done for HSW and get FBC for free
    at Ivybridge. So it makes more sense enable FBC for IVB first.
    FBC for HSW comming on next patches. We are just not enabling it by
    default on IVB.
v6: Fix confused commit name (by Matt Turner).
v7: Remove gtt_offset shift since it is page aligned byte offset (by Ville).

Cc: Matt Turner <mattst88@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>