Our checks for an invalid fence stride forgot to guard against
zero stride on gen4+. Fix it.

v2: Avoid duplicated code (danvet)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

IVB and HSW use different encodings for the PPGTT cacheability bits in
the GAM_ECOCHK register.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as
well. Configure it accordingly.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
the define, and enable it on SNB.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Requested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.

In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.

In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.

v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)

Reported-by: freezer from #intel-gfx on irc
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Workaround to avoid intermittent aux channel failures, per spec change.

v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Kill spurious tab spotted by Paulo.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I'm really not happy that we have to support this, but this will be the
simplest way to handle cases where PPGTT init can fail, which I promise
will be coming in the future.

v2: Resolve conflicts due to patch series reordering.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will allow us to carry on if we've cleaned up the PPGTT. The usage
for this is coming up - it simplifies handling a failed PPGTT init.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Spill the secrets about failing ppgtt init.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since we've already set up a nice vtable to abstract other PPGTT
functions, also abstract the actual register programming to enable
things.

This function will probably need to change a bit as we implement real
processes.

v2: Resolve conflicts due to patch series reordering.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This rework will help if future platforms choose to be a bit different.
Should have no functional impact.

v2: Don't move around the vtable setup (Daniel)

v3: Squash in the disable-by-default patch.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It only works that way on GEN6 and GEN7. Let's not assume GENn will be
the same.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The PPGTT scratch page is used for all gens, and doing it in the global
part of our PPGTT setup makes the code a bit nicer.

This was in a patch submitted earlier as part of the PPGTT cleanups.
Grumpy maintainer must have missed it, and I didn't yell when
appropriate. Apologies for everyone :-)

v2: Update commit message
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There used to be other fixes in this patch but they've slowly disappeared as
other parts have been fixed.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will allow us to read/write registers in GTT init.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Fix up error handling. We really should look into devres for
this stuff ...]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can assume that the PTE layout, and size changes for future
generations. To avoid confusion with the existing GEN6 PTE typedef, give
it a GEN6_ prefix.

v2: Fixup checkpatch warning and bikeshed commit message slightly.

v3: Rebase on top of Imre's for_each_sg_pages rework.

v4: Fixup conflicts in patch series reordering.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All gen6+ parts so far have 1 BAR which holds both the register space
and the GTT PTEs. Up until now, that was a 4MB BAR with half allocated
to each.

I have a strong hunch (wink, nod, wink) that future gens will also keep
a similar 50-50 split though the sizes may change. To help this along
change the code to obey the rule of half the total size instead of a
hard-coded 2MB.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render caches) our only option
is to select the generic mid-level cache. This reduces the latency of
the swap by about 5%.

Oddly this effect can be observed running smokin-guns on IVB at
1280x1024:
Using BLT copies for swaps: 151.67 fps
Using Render copies for swaps (unpatched):  141.70 fps
With contexts disabled: 150.23 fps
With contexts in L3$: 150.77 fps
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec has been been updated and dropped these two changes for non-sdv
LPT PCHs.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
manually flush writes to memory prior to writing the fence register in
conjunction with the memory barriers placed around the register write.

Fixes i-g-t/gem_fence_thrash

v2: Bring a bigger gun
v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
v4: Remove changes for working generations.
v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
v6: Rewrite comments to ellide forgotten history.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2)
Cc: stable@vger.kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Userspace can easily hit this and does since Ville added a new evil
igt testcase in:

commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Mar 4 15:34:06 2013 +0200

    kms_flip: Add flip-vs-bad-tiling test

v2: Fix the spelling in the added comment (Chris).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63246Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the ratio is different, we also need to pass in the parameters
for the reduced clock. Might or might not reduce flicker for the
auto-downclocking on lvds/eDP.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only on IBX should we set the limiting factor to 25 unconditionally
for dual-channel mode, on CPT/PPT 25 only applies when the lvds
refclock is 100MHz.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit de13a2e3
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Sep 20 18:36:05 2012 -0300

    drm/i915: extract compute_dpll from ironlake_crtc_mode_set

missed the subtle adjustment of the FP1 register. Fix this up by
passing a pointer around instead of the value.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The connector associated with the encoder is considered active when the
output associtated with this connector is active on the encoder. The
encoder itself is considered active when either there is an active
output on  it or the  respective SDVO channel is active.
Having active outputs when the SDVO channel is inactive seems to be
inconsistent: such states can be found when intel_modeset_setup_hw_state()
collects the hardware state set by the BIOS.
This inconsistency will be fixed in intel_sanitize_crtc()
(when intel_crtc_update_dpms() is called), this however only happens
when the encoder is associated with a crtc.

This patch also reverts:

     commit bd6946e8
     Author: Daniel Vetter <daniel.vetter@ffwll.ch>
     Date:   Tue Apr 2 21:30:34 2013 +0200

         drm/i915: Fix sdvo connector get_hw_state function
Signed-off-by: NEgbert Eich <eich@suse.de>
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

FIXME: This is based on some HW being used for a demo. We should
probably wait until we have confirmation on the IDs before upstreaming
this patch.

v2: Use GEN7_FEATURES (Chris)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Set up PCH_NOP when we match a certain platform.

v2: Just do a num_pipes check + comment instead of trying to check the
platform (Daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BIOS should be setting this, but in case it doesn't...

v2: Define the bits we actually want to clear (Jesse)
Make it an RMW op (Jesse)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
be bad for CPU" range when we have PCH_NOP.

There is a bit of a hack in init clock gating. We want to do most of the
clock gating, but the part we skip will hang the system. It could
probably be abstracted a bit better, but I don't feel it's too
unsightly.

v2: Use inverse HAS_PCH_NOP check (Jani)

v3: Actually do what I claimed in v2 (spotted by Daniel)
Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
Move LVDS bail into this patch (Ben)

v4: logical rebase conflict resolution with SDEIIR (Ben)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

Brush up patch a bit and resolve conflicts:
- Adjust PCH_NOP checks due to Egbert's hpd handling rework.
- Addd a PCH_NOP check in the irq uninstall code.
- Resolve conflicts with Paulo's SDE irq handling race fix.

v5: Drop the added hunks in the ilk irq handler again, they're bogus.
OOps.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Given certain fusing options discussed in the previous patch, it's
possible to end up with platforms that normally have PCH but that PCH
doesn't actually exist. In many cases, this is easily remedied with
setting 0 pipes. This covers the other corners.

Requiring this is a symptom of improper code splitting (using
HAS_PCH_SPLIT instead of proper GEN checking, basically). I do not want
to fix this.

v2: Remove PCH reflck after change in previous patch (Daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

GEN supports a fusing option which subtracts the PCH display (making the
CPU display also useless). In this configuration MMIO which gets decoded
to a certain range will hang the CPU.

For us, this is sort of the equivalent of having no pipes, and we can
easily modify some code to not do certain things with no pipes.

v2: Moved the num pipes check up in the call chain, and removed extra
checks noted by Daniel. For more details, see:
http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html

v3: Drop the intel_setup_overlay check (Daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise running igt will fill your dmesg with hang notices and it's
hard to judge from a quick look whether they're expected or not.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The behaviour around handling the eDP bpp value from vbt has been
slightly changed in

commit 36008365
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:59 2013 +0100

    drm/i915: convert DP autodither code to new infrastructure

The old behaviour was that we used the plane's bpp (usually 24bpp) for
computing the dp link bw, but set up the pipe with the bpp value from
vbt if available. This takes the vbt bpp override into account even
for the dp link bw configuration.

On Paulo's hsw machine this resulted in a slower link clock and a
black screen - but the mode actually /should/ fit even with the lower
clock. Until we've cleared up simply stay bug-for-bug compatible with
the old code.

While at it, also restore a debug message lost 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

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit deb18211.

It completely breaks the logic, since when we fall through to the end
of the function we actually _have_ figured out the correct pipe.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV docs still list the the color range selection bit for the HDMI
ports, but for DP ports it has been repurposed.

I have no idea whether the HDMI color range selection bit still works
on VLV, but since we now have to use the PIPECONF color range bit for
DP, we might as well do the same for HDMI.
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>

VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
[danvet: fixup rebase issues due to slightly different baseline.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prep-patch to improve the bpc handling in a next patch.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.

So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To facility
this, add a pipe_config->clocks_set boolean.

This patch here is only prep work, it simply sets the computed clock
values in pipe_config->dpll, and uses that data in the hw clock
setting functions.

Haswell code isn't touched, simply because Haswell clocks work much
different and need their own infrastructure (with probably a
Haswell-specific config->ddi_clock substruct).
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now we can ditch the checks in the Haswell disable code.

v2: add support for Haswell
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>