drm/i915: Fix noatomic crtc disabling, v2.

This fixes the breakage caused by

commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 15 12:33:53 2015 +0200

    drm/i915: Update less state during modeset.

    No need to repeatedly call update_watermarks, or update_fbc.
    Down to a single call to update_watermarks in .crtc_enable

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add missing shared dpll disable to the noatomic disable function.

This function will be replaced by its atomic counterpart soon.

Changes since v1:
- intel_crtc->active and watermarks are fixed by a patch from
  Patrik Jakobsson

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fill in more mode members

Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro

Updated the HAS_CORE_RING_FREQ macro to add the broxton check,
so as to disallow the programming & read of ring frequency
table for it.

Issue: VIZ-5144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add HAS_CORE_RING_FREQ macro

Added a new HAS_CORE_RING_FREQ macro, currently used in
gen6_update_ring_freq & i915_ring_freq_table debugfs function.
The programming & read of ring frequency table is needed for newer
GEN(>=6) platforms, except VLV/CHV.

Issue: VIZ-5144
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make intel_display_suspend atomic, try 2.

Calculate all state using a normal transition, but afterwards fudge
crtc->state->active back to its old value. This should still allow
state restore in setup_hw_state to work properly.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always force a modeset in intel_crtc_restore_mode, v2.

And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.

Because this is not yet done atomically, assume a full modeset is
needed and force a modeset on the crtc.

Changes since v1:
- s/reset/force modeset/

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update power domains on readout.

This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Get rid of unused transitional members.

The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert resume to atomic.

Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.

intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.

intel_display_setup_hw_state now only reads out the atomic state.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Readout initial hw mode.

drm/i915: Readout initial hw mode, v2.

Atomic requires a mode blob when crtc_state->enable is true, or
you get a huge warn_on.

With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so for now force a modeset the first time the mode blob's
updated.

This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.

Changes since v1:
- Add a description in intel_modeset_readout_hw_state of how the
  recalculation is done.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Calculate vblank timestamping constants before enabling vblank.

This is required to properly initialize vblanks on the active crtc.
Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
crtc 0: Noop due to uninitialized mode.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Zero the mode in intel_sanitize_crtc when force disabling.

There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property.
If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix reference leak in intel_modeset_readout_hw_state.

Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Rework plane readout.

All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Added Programming of the MOCS

This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.

It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.

v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)

Signed-off-by: Peter Antoine <peter.antoine@intel.com>
v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
  tables.  Prefix L3-specific defines consistently with L3_ and
  e/LLC-specific defines with LE_ to avoid this kind of confusion in
  the future.
- Change L3CC WT define back to RESERVED (matches my hardware
  documentation and the original patch, probably a misunderstanding
  of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
  open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
  (Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
  Wilson).
- Add comment about undefined entries being implicitly set to uncached
  for forwards compatibility.
v9 (Francisco Jerez):
- Minor style fixes.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove unused compat32 code

Totatlly forgotten that we have these when nuking all the UMS code.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove plane_config from struct intel_crtc, v2.

Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.

Changes since v1:
- Remove unrelated changes.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update missing properties in find_initial_plane_obj

The src and crtc rectangles were never set, resulting in the primary
plane being made invisible on first atomic update.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allow fuzzy matching in pipe_config_compare, v2.

Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.

Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.

Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.

Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
- Add adjust parameter to intel_compare_link_m_n, which is
  used to adjust m2_n2 if it's a multiple of m_n.
- Add exact parameter intel_compare_m_n.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not use plane_config in intel_fbdev.c

Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.

The size can be found in the fb, no need for the plane_config.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Do not update pfit state when toggling crtc enabled.

There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.

This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only update state on crtc's that are part of the atomic state.

This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc->config pointer, resulting in hard
to find bugs.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Restrict the ring frequency table programming to SKL

Ring frequency table programming is not required on BXT. Added separate
checks to enable the programming only for SKL & skip for BXT.

v2: Removed the BXT check from gen6_update_ring_freq function

Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't forget to mark crtc as inactive after disable

Watermark calculations depend on the intel_crtc->active flag to be set
properly. Suspend/resume is broken on SKL and we also get DDB mismatches
without this patch.

The regression was introduced in:

commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 15 12:33:53 2015 +0200

    drm/i915: Update less state during modeset.

    No need to repeatedly call update_watermarks, or update_fbc.
    Down to a single call to update_watermarks in .crtc_enable

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Don't touch disable_shared_dpll()

Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91203
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update PM interrupts before updating the freq

Currently we update the freq before masking the interrupts, which can
allow new interrupts to occur before the frequency has changed. These
extra interrupts might waste some cpu cycles. This patch corrects
this by masking interrupts prior to updating the frequency.

Note from Chris:
"Well it won't waste CPU cycles as the interrupt is also masked by the
threshold limits, but there should be no harm at all in reordering the
patch so, and it does make a certain amount of sense."

Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Praveen Paneri <praveen.paneri@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note from Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: storm detection documentation update

Update the hotplug documentation to explain that hotplug storm
is not expected for Display port panels and hence is not handled
in current code.

v2: update the statements as recommended by Daniel

Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Adjust BXT HDMI port clock limits

Since
 commit e62925567c7926e78bc8ca976cde5c28ea265a49
 Author: Vandana Kannan <vandana.kannan@intel.com>
 Date:   Wed Jul 1 17:02:57 2015 +0530

    drm/i915/bxt: BUNs related to port PLL

BXT DPLL can now generate frequencies in the 216-223 MHz range.
Adjust the HDMI port clock checks to account for the reduced range
of invalid frequencies.

Cc: Vandana Kannan <vandana.kannan@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Refactor VLV display power well init/deinit

We do the exact same steps around the disp2d/pipe A power well
enable/disable on VLV and CHV. Refactor the shared code into
some helpers.

Note that this means we now call vlv_power_sequencer_reset() before
turning off the power well, whereas before we did it after. That
doesn't matter though since vlv_power_sequencer_reset() just resets
the power sequencer software tracking and doesn't touch the hardware
at all.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Simplify CHV pipe A power well code

The pipe A power well is the "disp2d" well on CHV and pipe B and C wells
don't even exist. Thereforce we can remove the checks for pipe A vs.
others and just assume it's always pipe A.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Apply OCD to VLV/CHV DPLL defines

Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Keep GMCH DPLL VGA mode always disabled

We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep things
as similar as possible between them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Updated the i915_ring_freq_table debugfs function

Updated the i915_ring_freq_table debugfs function to support the read
of ring frequency table, through Punit interface, for SKL also.

Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Ring frequency table programming changes

Ring frequency table programming changes for SKL. No need for a
floor on ring frequency, as the issue of performance impact with
ring running below DDR frequency, is believed to be fixed on SKL

v2: Removed the check for avoiding ring frequency programming for BXT (Rodrigo)

Issue: VIZ-5144
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Retrieve the Rpe value from Pcode

Read the efficient frequency (aka RPe) value through the the mailbox
command (0x1A) from the pcode, as done on Haswell and Broadwell.
The turbo minimum frequency softlimit is not revised as per the
efficient frequency value.

v2: Replaced the conditional expression operator with 'if' statement (Tom)
v3: Corrected the derivation of efficient frequency & shifted the
    GEN9_FREQ_SCALER multiplications downwards (Ville)

Issue: VIZ-5143
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fbdev restore mode needs to invalidate frontbuffer

This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.

So let's also add the invalidate hack here while we don't have
a reliable dirty fbdev op.

v2: As pointed by Paulo: removed seg fault risk, used fb_helper
    when possible and put brackets on if.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_fbcon_fbt/psr
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fbdev_set_par reliably invalidating frontbuffer

fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in

commit 031b698a77a70a6c394568034437b5486a44e868
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 26 19:35:16 2015 +0200

    drm/i915: Unconditionally do fb tracking invalidate in set_domain

Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.

Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.

So this patch fixes this issue.

v2: Make invalidate directly and unconditionally and
    fix commit message indicating the set_domain fix
    as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: PSR: Increase idle_frames

Idle frames the number of identical frames needed
before panel can enter PSR.

There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and VBT isn't being
set at all.

Let's trust VBT when it is set + 1  and use minimum of 4 + 1
when VBT isn't set. "+1" covers the "of-by-one" case.

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

drm/i915: PSR: Remove Low Power HW tracking mask.

By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.

Apparently audio driver is tying power well management
and runtime PM for some reason. But with audio runtime
PM working or with audio completely out of picture
we should remove this mask, otherwise we have a high
risk of miss screen updates as faced by Matthew.

WARNING: With this patch if snd_intel_hda driver is
running and not releasing power well properly PSR will
constant Exit and Performance Counter will be 0.

But the best thing of this patch is that with one more
HW tracking working the risks of missed blank screen
are minimized at most.

This affects just core platforms where PSR exit are also
helped by HW tracking: Haswell, Broadwell and Skylake
for now.

v2: Fix commit message explanation. It has nothing to do
with runtime PM on i915 as previously advertised.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix intel_frontbuffer_flip documentation

Reported by the kbuild test robot.

Regression introduced by:
commit fdbff9282c0f5f61ffc87d57461b04d943250910
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jun 18 11:23:24 2015 +0200
    drm/i915: Clear fb_tracking.busy_bits also for synchronous flips

(I reviewed this commit, so it's also my fault)

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

drm/i915: intel_frontbuffer_flush can now be static

So make it static.

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

drm/i915: fix intel_fb_obj_flush documentation

Reported by the kbuild test robot.

Regression introduced by:
commit de152b627eb3018de91ec5c5a50b38e17d80a88b
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Tue Jul 7 16:28:51 2015 -0700
    drm/i915: Add origin to frontbuffer tracking flush

(I reviewed this commit, so it's also my fault)

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>

drm/i915: dirty fb operation flushsing frontbuffer

Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.

This patch solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like Plymouth.

Previously PSR was being invalidated by fbdev and Plymounth
was taking control with PSR yet invalidated and could get screen
updates normally. However with some atomic modeset changes
Pymouth modeset over ioctl was now causing frontbuffer flushes
making PSR gets back to work while it cannot track the
screen updates and exit properly.

By adding this flush on dirtyfb we properly track frontbuffer
writes and properly exit PSR.

Actually all mmap_wc users should call this dirty callback
in order to have a proper frontbuffer tracking.

In the future it can be extended to return 0 if the whole
screen has being flushed or the number of rects flushed
as Chris suggested.

v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
    callback is just called after few screen updates and not on
    everyone as pointed by Daniel.

v3: Use flush instead of invalidate since flush means
    invalidate + flush and dirty means drawn had finished and
    it can be flushed.

v4: Remove PSR from subject since it is purely frontbuffer tracking
    change and that can be useful for FBC as well.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix alignment as spotted by Paulo.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: PSR: Flush means invalidate + flush

Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.

On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracking like when flush has been originated by a flip.
Also flip had just invalidated it already.

It also uses origin to minimize the a bit the amount of
disable/enabled, mainly when flip already had invalidated.

With this patch in place it is possible to do a flush on dirty areas
properly in a following patch.

v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.

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

drm/i915: Add origin to frontbuffer tracking flush

This will be useful to PSR and FBC once we start making
dirty fb calls to also flush frontbuffer.

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

drm/i915: Update wa_ctx_emit() macro as per kernel coding guidelines

wa_ctx_emit() depends on the name of a local variable; if the name of that
variable is changed then we get compile errors. In this case it is unlikely
to be changed as this macro is only used in this set of functions but
Kernel coding guidelines doesn't recommend doing this. It was my mistake
as I should have corrected it at the beginning but missed so correct
this before there are more usages of this macro (Bob Beckett).

https://www.kernel.org/doc/Documentation/CodingStyle,
Chapter 12, "Things to avoid when using macros", point 2):

"
2) macros that depend on having a local variable with a magic name:

   #define FOO(val) bar(index, val)

might look like a good thing, but it's confusing as hell when one reads the
code and it's prone to breakage from seemingly innocent changes.
"

v2: Optimization to avoid multiple evaluation of 'index' in the macro.
Since we invoke it multiple times, compiler, if it can, should be able to coalesce
them into a single condition and remove multiple WARN_ON checks (Chris).

Suggested-by: Robert Beckett <robert.beckett@intel.com>
Cc: Robert Beckett <robert.beckett@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Handle HPD when it has actually occurred

Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
v3: Add check for ibx/cpt both (Ville).
    While at it, remove the redundant check for hotplug_trigger from
    pch_get_hpd_pins
v4: Indentation (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move set_no_fbc_reason() call out of intel_fbc_find_crtc()

So now all the calls are inside __intel_fbc_update(). Consistency!

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract FBC_MULTIPLE_PIPES check

I have two separate refactor ideas that require extracting this to a
separate function. I'm not sure which idea I'll end choosing, but
since both will require extracting this function, let's do this now.

Notice that this is just code moving. Any possible problems with the
current multiple pipes check should be fixed in later commits.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add FBC_IN_DBG_MASTER no_fbc_reason

The poor in_dbg_master() check was the only one without a reason
string. Give it a reason string so it won't feel excluded.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use intel_crtc for the FBC functions

This is all internal i915.ko work, let's start using intel_crtc for
everything.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use dev_priv for the FBC functions

Because the cool kids use dev_priv and FBC wants to be cool too.

We've been historically using struct drm_device on the FBC function
arguments, but we only really need it for intel_vgpu_active(): we can
use dev_priv everywhere else. So let's fully switch to dev_priv since
I'm getting tired of adding "struct drm_device *dev = dev_priv->dev"
everywhere.

If I get a NACK here I'll propose the opposite: convert all the
functions that currently take dev_priv to take dev.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move FBC vfuncs to struct i915_fbc

Because it makes more sense there, IMHO.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Inline SUPPORTS_DIGITAL_OUTPUTS

After the register save/restore code is gone there's just one user
left and it just obfuscates that one. Remove it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/mdelay/msleep/

Burning cpu cycles isn't awesome, so use sleeps instead.

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

drm/i915: Ditch SUPPORTS_INTEGRATED_HDMI|DP and use IS_G4X instead

Since that's really what we want to test for. Note remove the gen5
case doesn't change anything: In intel_setup_outputs ilk is handled
already in the HAS_PCH_SPLIT case, and the register save/restore code
touches registers which simply doesn't exist anymore at all.

v2: Drop UMS parts.

v3: Update commit message to reflect that the reg save/restore code is
gone (Ville).

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

drm/i915: Disable LVDS port after the pipe on PCH

Follow the correct pipe vs port disable sequence for the PCH LVDS
ports, ie. disable the port after the pipe.

Other PCH port were already converted in the following commits:
 1ea56e269e136544c0a76dc831c5edc27c47cb3c drm/i915: Disable CRT port after pipe on PCH platforms
 3c65d1d1bb92ea959e8bce3eeae90fe5c3daa58a drm/i915: Disable SDVO port after the pipe on PCH platforms
 a4790cec3adf5eec91f397b1884706a71c70730f drm/i915: Disable HDMI port after the pipe on PCH platforms
 08aff3fe26ae7a0d6f302ac2e1b7e2eb9933cd42 drm/i915: Move DP port disable to post_disable for pch platforms
but LVDS was forgotten.

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

drm/i915: Don't dereference NULL plane while setting up scalers

intel_atomic_setup_scalers() dereferences 'plane' before the plane has
been assigned.  The plane ID assignment doing this dereference is only
needed for debugging messages later in the function, so just move the
assignment farther down the function to a point where plane will no
longer be NULL.

This was introduced in:

        commit 133b0d128be39e308ccd3b3d765c31ebdbf5380e
        Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
        Date:   Mon Jun 15 12:33:39 2015 +0200

            drm/i915: Clean up intel_atomic_setup_scalers slightly.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Reported-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Mark elsps submitted when they are pushed to hw

Now when we have requests this deep on call chain, we can mark
the elsp being submitted when it actually is. Remove temp variable
and readjust commenting to more closely fit to the code.

v2: Avoid tmp variable and reduce number of writes (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert execlists_ctx_descriptor() for requests

Pass around requests to carry context deeper in callchain.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert execlists_elsp_writ() for requests

Pass around requests to carry context deeper in callchain.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert intel_lr_context_pin() for requests

Pass around requests to carry context deeper in callchain.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Assign request ringbuf before pin

In preparation to make intel_lr_context_pin|unpin to accept
requests, assign ringbuf into request before we call the pinning.

v2: No need to unset ringbuf on error path (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert execlists_update_context() for requests

Pass around requests to carry context deeper in callchain.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert execlist_submit_contexts() for requests

Pass around requests to carry context deeper in callchain.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Also perform gpu reset under execlist mode.

It is found that i915 will not reset gpu under execlist mode when
unload module. that will lead to some issues when unload/load module
with different submission mode. e.g. from execlist mode to ring
buffer mode via loading/unloading i915. Because HW is not in a reset
state and registers are not clean under such condition.

Signed-off-by: Niu,Bing <bing.niu@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update WaFlushCoherentL3CacheLinesAtContextSwitch

In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after PIPE_CONTROL
instruction but there is a slight complication as this is applied in WA batch
where the values are only initialized once.
Dave identified an issue with the current implementation where the register value
is read once at the beginning and it is reused; this patch corrects this by saving
the register value to memory, update register with the bit of our interest and
restore it back with original value.

This implementation uses MI_LOAD_REGISTER_MEM which is currently only used
by command parser and was using a default length of 0. This is now updated
with correct length and moved to appropriate place.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: protect FBC functions with FBC checks

Now all the functions called by other files check whether FBC has been
initialized. This allows us to drop the checks on the static
functions.

v2:
 - s/HAS_FBC/dev_priv->display.enable_fbc/ everywhere but the init
   function (Chris).

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: FBC doesn't need struct_mutex anymore

Everything is covered either by fbc.lock or mm.stolen_lock, and
intel_fbc.c is already responsible for grabbing the appropriate locks
when it needs them.

Reviewed-by: Chris wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: intel_unregister_dsm_handler() doesn't need struct_mutex

So don't grab the lock before calling the function.

Reviewed-by: Chris wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: intel_frontbuffer_flip_prepare() doesn't need struct_mutex

So release the lock earlier.

Reviewed-by: Chris wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add the FBC mutex

Make sure we're not going to have weird races in really weird cases
where a lot of different CRTCs are doing rendering and modesets at the
same time.

With this change and the stolen_lock from the previous patch, we can
start removing the struct_mutex locking we have around FBC in the next
patches.

v2:
 - Rebase (6 months later)
 - Also lock debugfs and stolen.
v3:
 - Don't lock a single value read (Chris).
 - Replace lockdep assertions with WARNs (Daniel).
 - Improve commit message.
 - Don't forget intel_pre_plane_update() locking.
v4:
 - Don't remove struct_mutex at intel_pre_plane_update() (Chris).
 - Add comment regarding locking dependencies (Chris).
 - Rebase after the stolen code rework.
 - Rebase again after drm-intel-nightly changes.
v5:
 - Rebase after the new stolen_lock patch.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add dev_priv->mm.stolen_lock

Which should protect dev_priv->mm.stolen usage. This will allow us to
simplify the relationship between stolen memory, FBC and struct_mutex.

v2:
  - Rebase after the stolen_remove_node() dev_priv patch move.
  - I realized that after we fixed a few things related to the FBC CFB
    size checks, we're not reallocating the CFB anymore with FBC
    enabled, so we can just move all the locking to i915_gem_stolen.c
    and stop worrying about freezing all the stolen alocations while
    freeing/rellocating the CFB. This allows us to fix the "Too
    coarse" observation from Chris.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move FBC code out of i915_gem_stolen.c

With the abstractions created by the last patch, we can move this code
and the only thing inside intel_fbc.c that knows about dev_priv->mm is
the code that reads stolen_base.

We also had to move a call to i915_gem_stolen_cleanup_compression()
- now called intel_fbc_cleanup_cfb() - outside i915_gem_stolen.c.

v2:
  - Rebase after the remove_node() changes on the previous patch.

Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add simple wrappers for stolen node insertion/removal

We want to move the FBC code out of i915_gem_stolen.c, but that code
directly adds/removes stolen memory nodes. Let's create this
abstraction, so i915_gme_stolen.c is still in control of all the
stolen memory handling. The abstraction will also allow us to add
locking assertions later.

v2:
  - Add dev_priv as remove_node() argument since we'll need it later
    (Chris).

Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop a spurious intel_pre_plane_update() call

Kill the extra intel_pre_plane_update() I accidentally added in

 commit 852eb00dc44ea2b8896e2fa27c6a36a1f697ba5a
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Wed Jun 24 22:00:07 2015 +0300

    drm/i915: Try to make sure cxsr is disabled around plane
    enable/disable

This fixes a load of warnings from the frontbuffer tracking.

Testcase: igt/kms_frontbuffer_tracking/fbc-1p-rte
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/opregion: start using extended didl

Adding support for did2, or the extended support display devices ID
list, increases the total to 15.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/opregion: abstract didl and did2 getter and setter

Make it easier to handle the extended didl. No functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/opregion: prefer DRM logging functions over pr_warn and dev_dbg

Conform to same style as the rest of the driver.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/opregion: add new opregion stuff

Inluding extended didl and cpdl fields

Present since opregion version 3.0.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/opregion: use BUILD_BUG_ON to verify mailbox struct sizes

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/hotplug: document the hotplug handling in the driver

Add an overview of the drm/i915 hotplug handling.

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

drm/i915/audio: clarify HD audio documentation wrt modeset

Clarify that audio enable/disable sequences are part of the modeset
sequence.

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

drm/i915: set FDI translations to NULL on SKL

drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_prepare_ddi’:
drivers/gpu/drm/i915/intel_ddi.c:517:6: warning:
‘ddi_translations_fdi’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   if (ddi_translations_fdi)
      ^
drivers/gpu/drm/i915/intel_ddi.c:446:30: note: ‘ddi_translations_fdi’
was declared here
  const struct ddi_buf_trans *ddi_translations_fdi;
                              ^

This line used to be there, but was removed by:

commit f8896f5d58e64bfd3c2b5f7c5ba5c3f3967e93c7
Author: David Weinehall <david.weinehall@linux.intel.com>
Date:   Thu Jun 25 11:11:03 2015 +030
    drm/i915/skl: Buffer translation improvements

Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Expose I915_EXEC_RESOURCE_STREAMER flag and getparam

Ensures that the batch buffer is executed by the resource streamer.
And will let userspace know whether Resource Streamer is supported in
the kernel.

v2: Don't skip 1<<15 for the exec flags (Jani Nikula)
v3: Use HAS_RESOURCE_STREAMER macro for execbuf validation (Chris Wilson)

(from getparam patch)

v2: Update I915_PARAM_HAS_RESOURCE_STREAMER so it's after
    I915_PARAM_HAS_GPU_RESET.
v3: Only advertise RS support for hardware that supports it.
v4: Add HAS_RESOURCE_STREAMER() macro (Chris)

Testcase: igt/gem_exec_params
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
[danvet: squash in getparam patch since it'd break bisect, suggested
by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable resource streamer on Execlists

GEN8 and above uses Execlists by default instead of the legacy
ringbuffer for batch execution. This patch enables the resource
streamer bits when required.

Patch is based on the initial work by Minu Mathai <minu.mathai@intel.com>
This version also adds the required bits to enable GEN8 Resource
Streamer context save and restore for Execlists.

Cc: ville.syrjala@linux.intel.com
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable Resource Streamer state save/restore on MI_SET_CONTEXT

Also clarify comments on context size that the extra state for
Resource Streamer is included.

v2: Don't remove the extended save/restore enabled for older
    platforms. (Ville)
    Use new MI_SET_CONTEXT defines for HSW RS save/restore state
    instead of extended save/restore. (Daniel)

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable resource streamer bits on MI_BATCH_BUFFER_START

Adds support for enabling the resource streamer on the legacy
ringbuffer for HSW and GEN8.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: BUNs related to port PLL

This patch contains changes based on 2 updates to the spec:
Port PLL VCO restriction raised up to 6700.
Port PLL now needs DCO amp override enable for all VCO frequencies.

v2: Sonika's review comment addressed
- dcoampovr_en_h variable not required
Based on a discussion with Siva, the following changes have been made.
- replace dco_amp var with #define BXT_DCO_AMPLITUDE
- set pll10 in a single assignment

v3:
Move DCO amplitude default value to i915_reg.h. Suggested by Siva.

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> [v2]
[danvet: Spell out BUN since not everyone knows what this means.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: Disable 12bpc hdmi for now"

HDMI 12bpc should be working fine now. Let it loose.

This reverts commit 5e3daaca09f5158eff9c92290faa1d2001ecc6e4.

v2: Rebased due to CHV/BXT port clock check improvemnts

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-and-tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Account for CHV/BXT DPLL clock limitations

CHV/BXT DPLL can't generate frequencies in the 216-240 MHz range.
Account for that when checking whether the HDMI port clock is valid.
This is particularly important for BXT since it can otherwise do
12bpc, and standard 1920x1080p60 CEA modes land right in the middle
of that range when the clock gets multiplied to account for 12bpc.

With the extra checks we will now filter out any mode where both
8bpc and 12bpc clock are within the gap. During modeset we then
pick whichever mode works, favoring 12bpc if both are possible.

12bpc isn't supported on CHV so we simply end up filtering out any
mode where the 8bpc port clock is in the gap.

v2: Fix crtc_clock vs. port_clock fumble in compute_config() (Imre)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-and-tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Bump HDMI min port clock to 25 MHz

Increase the HDMI port minimum port clock from 20 to 25 MHz. This is
is the minimum listed in the DVI/HDMI specs, and it's also the
documented minimum DPLL frequency for most of our platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-and-tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix HDMI 12bpc and pixel repeat clock readout for DDI platforms

Take the HDMI 12bpc mode and pixel repeat into account when extracting
the dotclock from the hardware on DDI platforms.

Tested on HSW only.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-and-tested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

GPU-DRM: Delete an unnecessary check before drm_property_unreference_blob()

The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Zhao Junwang <zhjwpku@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update DRIVER_DATE to 20150703

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gtt: Per ppgtt scratch page

Previously we have pointed the page where the individual ppgtt
scratch structures refer to, to be the instance which GGTT setup have
allocated. So it has been shared.

To achieve full isolation between ppgtts also in this regard,
allocate per ppgtt scratch page.

Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Changes required to enable DSI Video Mode on CHT

On CHT, changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct
dividor & ctrl values are written in cck regs for DSI. This patch has
been tested on CHT RVP with 1200 x 1920 panel.

v2 by Jani, rebased on earlier refactoring, original at [1].

[1] http://mid.gmane.org/1431368400-1942-5-git-send-email-rodrigo.vivi@intel.com

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Support for higher DSI clk

For MIPI panels requiring higher DSI clk, values needs to be added
in lfsr_converts table for getting the correct values of pll ctrl
and dividor values which gets programmed in cck regs, otherwise DSI
PLL does not get locked leading to no display on the MIPI panel.

Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/dsi: abstract dsi bpp derivation from pixel format

Nuke three copies of the same switch case.

Hopefully we can switch to a drm generic function later on, but that
will require us to swich to enum mipi_dsi_pixel_format first.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't increment the FBC threshold at fbc_enable

We first set the threshold value when we're allocating the CFB, and
then later at {ilk,gen7}_fbc_enable() we increment it in case we're
using 16bpp. While that is correct, it is dangerous: if we rework the
code a little bit in a way that allows us to call intel_fbc_enable()
without necessarily calling i915_gem_stolen_setup_compression() first,
we might end up incrementing threshold more than once. To prevent
that, increment a temporary variable instead.

v2: Rebase.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Report correct GGTT space usage

Currently only normal views were accounted which under-accounts
the usage as reported in debugfs.

Introduce new helper, i915_gem_obj_total_ggtt_size, and use it
from call sites which want to know how much GGTT space are
objects using.

v2: Single loop in i915_gem_get_aperture_ioctl. (Chris Wilson)

v3: Walk GGTT active/inactive lists in i915_gem_get_aperture_ioctl
    for better efficiency. (Chris Wilson, Daniel Vetter)

v4: Make i915_gem_obj_total_ggtt_size private to debugfs. (Chris Wilson)

v5: Change unsigned long to u64. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>