We needed this originally for updating pagetables in plane commit
functions. But that's extracted into prepare/cleanup now. The other
issue was running updates when the pipe was off. That's also now
fixed.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Huzzah! \o/
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the breakage caused by

commit eddfcbcd
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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
    Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel 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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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=90396Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The src and crtc rectangles were never set, resulting in the primary
plane being made invisible on first atomic update.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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 eddfcbcd
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: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
    Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Don't touch disable_shared_dpll()
Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91203Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix alignment as spotted by Paulo.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because it makes more sense there, IMHO.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Burning cpu cycles isn't awesome, so use sleeps instead.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NChris wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So don't grab the lock before calling the function.
Reviewed-by: NChris wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So release the lock earlier.
Reviewed-by: NChris wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kill the extra intel_pre_plane_update() I accidentally added in

 commit 852eb00d
 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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NVandana 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

Depending on the platform the port clock fed to the pipe can be the PLL's
post-divided fast clock rate or a /5 divided version of it. To make this
more obvious across the platforms calculate this port clock along with
the rest of the PLL parameters.

This is also needed by the next patch where we can reuse the CHV helper
for the BXT PLL HW readout code; so export the corresponding helper.

While at it also add a more descriptive name to the helpers and a
comment explaining what's being calculated.

No functional change.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the helper next to the PLL helpers of the other platforms for
clarity.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Although we have a fixed setting for the PLL9 and EBB4 registers, it
still makes sense to check them together with the rest of PLL registers.

While at it also remove a redundant comment about 10 bit clock enabling.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CxSR (or maxfifo on VLV/CHV) blocks somne changes to the plane control
register (enable bit at least, not quite sure about the rest). So in
order to have the plane enable/disable when we want we need to first
kick the hardware out of cxsr.

Unfortunateloy this requires some extra vblank waits. For the CxSR
enable after the plane update we should eventually use an async
vblank worker, but since we don't have that just do sync vblank
waits. For the disable case we have no choice but to do it
synchronously.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>