commit 65ca7514
 Author: Damien Lespiau <damien.lespiau@intel.com>
 Date:   Mon Feb 9 19:33:22 2015 +0000

    drm/i915/skl: Implement WaBarrierPerformanceFixDisable

got misapplied and the code landed in chv_init_workarounds() instead of
the intended skl_init_workarounds(). Move it over to the right place.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Simplify intel_hpd_irq_handler() by extracting HPD irq storm detection
to a separate function.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Silence the following -Wmaybe-uninitialized warnings and make the code
more clear.

drivers/gpu/drm/i915/intel_display.c: In function ‘__intel_set_mode’:
drivers/gpu/drm/i915/intel_display.c:11844:14: warning: ‘crtc_state’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  return state->mode_changed || state->active_changed;
              ^
drivers/gpu/drm/i915/intel_display.c:11854:25: note: ‘crtc_state’ was declared here
  struct drm_crtc_state *crtc_state;
                         ^
drivers/gpu/drm/i915/intel_display.c:11868:6: warning: ‘crtc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (crtc != intel_encoder->base.crtc)
      ^
drivers/gpu/drm/i915/intel_display.c:11853:19: note: ‘crtc’ was declared here
  struct drm_crtc *crtc;
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The hotplug status is cached in hp_control, and will be passed on to
bottom halves through intel_hpd_irq_handler(), so we can clear the
sticky bits earlier.

While at it, drop the redundant logging of the hotplug status, which
will also be logged by pch_get_hpd_pins().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Split intel_hpd_irq_handler into platforms specific and platform
agnostic parts. The platform specific parts decode the registers into
information about which hpd pins triggered, and if they were long
pulses. The platform agnostic parts do further processing, such as
interrupt storm mitigation and scheduling bottom halves.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

As the hpd loops have been merged together, we don't have to maintain
state for all hpd triggers.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Nothing in the two consecutive loops over hpd pins depends on state in a
larger context than the single hpd pin. If we skip the rest of the loop
on short hpd pulses, we can merge the two loops into one.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

In an unfortunate back and forth stepping, retract the earlier change to
reduce indent. This is to make merging the two loops easier. No
functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Multiple positive and negative checks for hpd[i] & hotplug_trigger gets
hard to read. Simplify. This should make follow-up patches merging the
two loops easier. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Print a warning if we fall through the .get_display_clock_speed() function
pointer setup. We end up assuming a 133MHz cdclk which should mean that
at least we avoid any 0 deivisions and whatnot. But this could at least
help remind people that they have to provide this function for new platforms.

v2: Rebased to the latest
v3: Rebased to the latest

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Implement cdclk extraction for g33, 965gm and g4x platforms. The details
came from configdb. Sadly there isn't anything there for other gen3/gen4
chipsets.

So far I've tested this on one ELK where it gave me a HPLL VCO of 5333
MHz and cdclk of 444 MHz which seems perfectly sane for this machine.

v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

It seems 852GM/GMV uses a different HPLLCC encoding than the other
85x platforms. For 852GM/GMV cdclk is always 133MHz. Try to detect that
using the PCI revision (sinc the device ID seems useless for that). I'm
not at all sure this is a good idea, but according to the specs it
should work.

v2: Rebased to the latest
v3: Rebased to the latest

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Actually read the HPLLCC register insted of assuming it's 0. Fix the
HPLLCC bit definitions and all the missing ones from the 852GME spec.

852GME, 854 and 855 all seem to match the same HPLLC encoding even
though only some of the values are valid is some of the platforms.

v2: Rebased to the latest
v3: Rebased to the latest

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Printing it for PPGTT VMAs only adds noise since we have defined
view types are only applicable for GGTT.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The orignal code started by storing the actual central frequency (in Hz,
using a uint64_t) in a uint32_t which codes for the register value. That
can't be right.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Those functions were the only one in existence when they were
introduced. We now know they are only valid for HSW/BDW.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

abs_diff() properly protects its parameters, so no need for the outer ()
here.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

div_u64() can be either a inline function or a define, but in either
case it's safe to provide expressions as parameters without outer ()
around them.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This part doesn't depend on how we compute the DPLL dividers (p and
p0/p1/p2) and can be reused even if we change the algorithm to do so.
(something that is planned for a followup patch)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We can coalesce the WARN() condition with the WARN() itself and, as we
are returning early, we can de-intent the rest of the function.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

At the moment, even if we fail to find a suitable divider, we'll still
try to set the mode with bogus parameters.

Just fail the modeset if we can't generate the frequency.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This helps debugging.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Right now, when finishing the cycle with odd dividers without finding a
suitable candidate, we end up in an infinite loop. Make sure to break in
that case.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Not needed or used.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The hotplug callbacks for DP and DDI effectively did nothing. Remove
them.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

There are plenty of hotplug related fields in struct drm_i915_private
scattered all around. Group them under one hotplug struct. Clean up
naming while at it. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Continue to loop early if there's nothing to do. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Move dp aux irq handling within the same branch instead of duplicating
the conditions. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Bail out early if nothing to do. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Export a new context parameter that can be set/queried through the
context_{get,set}param ioctls.  This parameter is passed as a context
flag and decides whether or not a GPU address mapping is allowed to
be made at address zero.  The default is to allow such mappings.
Signed-off-by: David Weinehall <david.weinehall@intel.com>
Acked-by: "Zou, Nanhai" <nanhai.zou@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This commit is the "sink CRC" version of:

commit 8c740dce
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Oct 17 18:42:03 2014 -0300
    drm/i915: disable IPS while getting the pipe CRCs.

For some unknown reason, when IPS gets enabled, the sink CRC changes.
Since hsw_enable_ips() doesn't really guarantee to enable IPS (it
depends on package C-states), we can't really predict if IPS is
enabled or disabled while running our CRC tests, so let's just
completely disable IPS while sink CRCs are being used.

If we find a way to make IPS not change the pipe CRC result, we may
want to fix IPS and then revert this patch (and 8c740dce too). While
this doesn't happen, let's merge this patch, so the IGT tests relying
on sink CRCs can work properly.

This was discovered while developing a new IGT test, which will
probably be called kms_frontbuffer_tracking.

Testcase: igt/kms_frontbuffer_tracking (not on upstream IGT yet)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

It's totally broken, and since

commit d328c9d7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Apr 10 16:22:37 2015 +0200

    drm/i915: Select starting pipe bpp irrespective or the primary plane

the kernel will try to use it even for the common rgb888 framebuffers.
Ville has patches to fix it all up properly, but unfortunately they're
stuck in review limbo. And since the 4.2 feature cutoff has passed we
need to somehow  handle this regression.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

chv_enable_pll() doesn't need to hold sb_lock for the entire duration of
the function. Drop the lock as soon as possible.

valleyview_set_cdclk() does a potential lock+unlock+lock+unlock cycle
with sb_lock. Grab the lock a few lines earlier so we can make do
with a single lock+unlock cycle always.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Rename dpio_lock to sb_lock to inform the reader that its primary
purpose is to protect the sideband mailbox rather than some DPIO
state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The primary plane frobbing was removed from the sprite code in
 commit ecce87ea
 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
 Date:   Tue Apr 21 17:12:50 2015 +0300

    drm/i915: Remove implicitly disabling primary plane for now

but the intel_flush_primary_plane() calls were left behind. Replace them
with straight forward POSTING_READ() of the sprite surface address
register.

The other user of intel_flush_primary_plane() is g4x_disable_trickle_feed()
where we can just inline the steps directly.

This allows intel_flush_primary_plane() to be killed off.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Expecting CHV power wells to be just an extended versions of the VLV
power wells, a bunch of commented out power wells were added in
anticipation when Punit folks would implement it all. Turns out they
never did, and instead CHV has fewer power wells than VLV. Rip out all
the #if 0'ed junk that's not needed.

v2: Rename the "pipe-a" well to "display" to match VLV
    Clarify the pipe A power well relationship to pipes B and C (Deepak)
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Not sure which LDO programming sequence delay should be used for the CHV
PHY, but the spec says that 600ns is "Used by default for initial
bringup", and the BIOS seems to use that, so let's do the same.
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 53292cdb ("drm/i915: Workaround
to avoid lite restore with HEAD==TAIL") added a check for req0 != null
which is unnecessary.

The only way req0 could be null is if the list was empty, and this is
already addressed at the beginning of execlists_context_unqueue().
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

In commit 1854d5ca
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 7 16:20:32 2015 +0100

    drm/i915: Deminish contribution of wait-boosting from clients

we removed an atomic timer based check for allowing waitboosting and
moved it below the mutex taken during RPS. However, that mutex can be
held for long periods of time on Vallyview/Cherryview as communication
with the PCU is slow. As clients may frequently wait for results (e.g.
such as tranform feedback) we introduced contention between the client
and the RPS worker. We can take advantage of the RPS worker, by
switching the wait boost decision to use spin locks and defer the
actual reclocking to the worker.

Fixes a regression of up to 45% on Baytrail and Baswell!

v2 (Daniel):
- Use max_freq_softlimit instead of the not-yet-merged boost
  frequency.
- Don't inject a fake irq into the boost work, instead treat
  client_boost as just another legit waker.

v3: Drop the now unused mask (Chris).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>