drm/i915: Enforce execobject.alignment to be a power-of-two

Internal requirement for the alignment is that it must be a
power-of-two, so enforce rejection at the user interface to execbuffer
(which allows the caller to specify a stricter-than-expected alignment
criterion).

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

drm/i915: Remove unused ring argument from frontbuffer invalidate and busy functions.

This patch doesn't have any functional change, but organize fruntbuffer
invalidate and busy by removing unecesarry signature argument for ring.

It was unsed on mark_fb_busy and only used on fb_obj_invalidate for the
same ORIGIN_CS usage. So let's clean it a bit

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Factor out p2 divider selection for pre-ilk platforms

The same dpll p2 divider selection is repeated three times in the
gen2-4 .find_dpll() functions. Factor it out.

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: reduce line width in {pch, i9xx}_get_hpd_pins()

Make Paulo happier.

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

drm/i915: move generic hotplug code into new intel_hotplug.c file

We have enough generic hotplug functions sprinkled all over i915_irq.c
to warrant moving them to a file of their own. This should further
underline the distinction between generic code in the new file and
platform specific hotplug and irq code that remains in i915_irq.c.

Add new intel_hpd_init_work to keep work functions static, and rename
get_port_from_pin to intel_hpd_pin_to_port while increasing its
visibility, but keep everything else the same.

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

drm/i915/irq: clarify irq storm related function naming

We'll have three functions:

intel_hpd_irq_storm_detect for detecting irq storms,
intel_hpd_irq_storm_disable for disabling hotplugs after detected storms,
intel_hpd_irq_storm_reenable_work for re-enabling hotplug.

No functional changes.

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

drm/i915/irq: abstract irq storm hotplug disabling

Continue abstracting hotplug storm related functions to clarify the
code. This time, abstract hotplug irq storm related hotplug
disabling. While at it, clean up the loop iterating over connectors for
readability.

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

drm/i915/irq: move hotplug even debug print to second connector loop

The hotplug work function has two loops iterating over connectors, the
first for handling hotplug disabling due to irq storms and the second
for actually handling the hotplug events. Move the debug printing into
the second one, so we can abstract the storm handling better. This may
change the output ordering slightly when there are multiple simultaneous
hotplug events.

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

drm/i915: Make cdclk part of the atomic state.

The skylake scalers depend on the cdclk freq, but that frequency can
change during a modeset. So when a modeset happens calculate the new
cdclk in the atomic state. With the transitional helpers gone the
cached value can be used in the scaler, and committed after all
crtc's are disabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874
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>

drm/i915: Remove transitional references from intel_plane_atomic_check.

All transitional plane helpers are gone, party!

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>

drm/i915: Make setting color key atomic.

By making color key atomic there are no more transitional helpers.
The plane check function will reject the color key when a scaler is
active.

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>

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>

drm/i915: atomic plane updates in a nutshell

Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.

The code is shared with atomic_begin/flush, except watermark updating
and vblank evasion are not used.

This is needed for proper atomic suspend/resume support.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868
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>

drm/i915: Handle disabling planes better, v2.

Read out the initial state, and add a quirk to force add all planes
to crtc_state->plane_mask during initial commit. This will disable
all planes during the initial modeset.

The initial plane quirk is temporary, and will go away when hardware
readout is fully atomic, and the watermark updates in intel_sprite.c
are removed.

Changes since v1:
- Unset state->visible on !primary planes.
- Do not rely on the plane->crtc pointer in intel_atomic_plane,
  instead assume planes are invisible until modeset.

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>

drm/i915: Do not run most checks when there's no modeset.

All the checks in intel_modeset_checks are only useful when a modeset
occurs, because there is nothing to update otherwise.

Same for power/cdclk changes, if there is no modeset they are noops.

Unfortunately intel_modeset_pipe_config still gets called without
modeset, because atomic hw readout isn't done yet.

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>

drm/i915: Move crtc commit updates to separate functions.

To allow them to be used in intel_set_mode.

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>

drm/i915: move detaching scalers to begin_crtc_commit, v2.

This is probably intended to be be done during vblank evasion.

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>

drm/i915: remove force argument from disable_plane

The idea was good, but planes can have a fb even though
they're disabled. This makes the force argument useless
and always true, because only the commit function updates
state.

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>

drm/i915: clean up atomic plane check functions, v2.

By passing crtc_state to the check_plane functions a lot of duplicated
code can be removed. There are still some transitional helper calls,
they will be removed later.

Changes since v1:
- Revert state->visible changes.
- Use plane->state->crtc instead of plane->crtc.
- Use drm_atomic_get_existing_crtc_state.

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>

drm/i915: clean up plane commit functions

No point in hiding behind big ifs. This will be true most of the time.

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>

drm/i915: Split plane updates of crtc->atomic into a helper, v2.

This makes it easier to verify that no changes are done when
calling this from crtc instead.

Changes since v1:
 - Make intel_wm_need_update static and always check it.

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>

drm/i915: Split skl_update_scaler, v4.

commit 2c310b9d2859863826c3688c88218d607d5dd19a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon May 18 12:28:52 2015 +0200

drm/i915: Split skl_update_scaler, v4.

It's easier to read separate functions for crtc and plane scaler state.

Changes since v1:
 - Update documentation.
Changes since v2:
 - Get rid of parameters to skl_update_scaler only used for traces.
   This avoids needing to document the other parameters.
Changes since v3:
 - Rename scaler_idx to scaler_user.

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>

drm/i915: Assign a new pll from the crtc check function, v2.

It saves another loop over all crtc's in the state, and computing
clock is more of a per crtc thing.

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>

drm/i915: Move scaler setup to check crtc function, v2.

The scaler setup may add planes, but since they're unchanged we only
have to wait for primary flips. Also set planes_changed to indicate
at least 1 plane is modified.

Changes since v1:
- Instead of removing planes, do minimal validation needed.

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>

drm/i915: Add a simple atomic crtc check function, v2.

Move the check for encoder cloning here.

Changes since v1:
- Remove was/is crtc_disabled. (mattrope)
- Rename function to intel_crtc_atomic_check. (mattrope)

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>

drm/i915: Clean up intel_atomic_setup_scalers slightly.

Get rid of a whole lot of ternary operators and assign the index
in scaler_id, instead of the id. They're the same thing.

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>

drm/i915: Use crtc state in intel_modeset_pipe_config

Grabbing crtc state from atomic state is a lot more involved,
and make sure connectors are added before calling this function.

Move check_digital_port_conflicts to intel_modeset_checks,
it's only useful to check it on a modeset.

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>

drm/i915: Update DRIVER_DATE to 20150619

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

drm/i915: Reset request handling for gen8+

In order for gen8+ hardware to guarantee that no context switch
takes place during engine reset and that current context is properly
saved, the driver needs to notify and query hw before commencing
with reset.

There are gpu hangs where the engine gets so stuck that it never will
report to be ready for reset. We could proceed with reset anyway, but
with some hangs with skl, the forced gpu reset will result in a system
hang. By inspecting the unreadiness for reset seems to correlate with
the probable system hang.

We will only proceed with reset if all engines report that they
are ready for reset. If root cause for system hang is found and
can be worked around with another means, we can reconsider if
we can reinstate full reset for unreadiness case.

v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel)
v3: updated commit msg
v4: timeout_ms, simpler error path (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=89959
References: https://bugs.freedesktop.org/show_bug.cgi?id=90854
Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked
Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tomas Elf <tomas.elf@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/bxt: eDP Panel Power sequencing

Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.

v2:
[Jani] Added 2nd set of PPS registers and the macro
Jani's review comments
- remove reference in i915_suspend.c
- Use BXT PP macro
Squashing all PPS related patches into one.

v3: Jani's review comments addressed
- Use pp_ctl instead of pp
- ironlake_get_pp_control() is not required for BXT
- correct the use of && in the print statement
- drop the shift in the print statement

v4: Jani's comments
- modify ironlake_get_pp_control() - dont set unlock key for bxt

v5: Sonika's comments addressed
- check alignment
- move pp_ctrl_reg write (after ironlake_get_pp_control())
to !IS_BROXTON case.
- check before subtracting 1 for t11_t12

Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use helper to set CRTC state's mode

We need to call drm_atomic_set_mode_for_crtc() rather than copying the
mode in manually.  As of commit

        commit 99cf4a29fa24461bbfe22125967188a18383eb5c
        Author: Daniel Stone <daniels@collabora.com>
        Date:   Mon May 25 19:11:51 2015 +0100

            drm/atomic: Add current-mode blob to CRTC state

the helper now also takes care of setting up the mode property blob for
us; if we don't use the helper and never setup the mode blob, this will
also trigger a failure in drm_atomic_crtc_check() when we have the
DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support
via i915.nuclear_pageflip kernel command line parameter).

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

drm/i915: Remove more ilk rc6 remnants

Leftover from the big purge

commit a561165493e5fec2f74bd3ae0577ed659e44ab7f
Author: John Harrison <John.C.Harrison@Intel.com>
Date:   Thu Mar 5 14:03:03 2015 +0000

    drm/i915: Remove ironlake rc6 support

Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Reported-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Limit CHV max cdclk

Limit CHV maximum cdclk to 320MHz.

v2: Rebase to the latest
v3: Clean up of if-else tree

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

drm/i915: don't set the FBC plane select bits on HSW+

This commit is just to make the intentions explicit: on HSW+ these
bits are MBZ, but since we only support plane A and the macro
evaluates to zero when plane A is the parameter, we're not fixing any
bug.

v2:
 - Remove useless extra blank like (Chris).
 - Init dpfc_ctl in another place (Chris).

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: unify no_fbc_reason message printing

This commit has two main advantages: simplify intel_fbc_update()
and deduplicate the strings.

v2:
 - Rebase due to changes on P1.
 - set_no_fbc_reason() can now return void (Chris).

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_ROTATION to enum no_fbc_reason

Because we're currently using FBC_UNSUPPORTED_MODE for two different
cases.

This commit will also allow us to write the next one without hiding
information from the user.

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: print FBC compression status on debugfs

We already had a few bugs in the past where FBC was compressing
nothing when it was enabled, which makes the feature quite useless.
Add this information to debugfs so the test suites can check for
regressions in this piece of the code.

Our igt/tests/kms_frontbuffer_tracking already has support for this
message.

v2: - Remove pointless VLV check (Ville).

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 the 64k linear scanout alignment on gen2/3

The docs don't support the 64k linear scanout alignment we impose
on gen2/3. And it really makes no sense since we have no DSPSURF
register, so the only thing that the hardware will see is the linear
offset which will be just pixel aligned anyway.

There is one case where 64k comes into the picture, and that's FBC.
The start of the line length buffer corresponds to a 64k aligned
address of the uncompressed framebuffer. So if the uncompressed fb is
not 64k aligned, the first actually used entry in the line length
buffer will not be byte 0. There are 32 extra entries in the line
length buffer to account for this extra alignment so we shouldn't
have to worry about it when mapping the uncompressed fb to the GTT.

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

drm/i915: Align DSPSURF to 128k on VLV/CHV

VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV
docs got updated at some point to say that we need to align them to
128k, just like we do on gen4.

So far I've seen the problem manifest when the stride is an odd multiple
of 512 bytes, and the surface address meets the following pattern
'(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The
result is a starcase effect (so some pages get dropped maybe?), with a
few pages here and there clearly getting scannout out at the wrong position.

I've not actually been able to reproduce this problem on gen4, so it's
not clear of the issue is any way related to the 128k restrictions
supposedly inherited from gen4. But let's hope the 128k alignment is
sufficient to hide it all.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Actually respect DSPSURF alignment restrictions

Currently intel_gen4_compute_page_offset() simply picks the closest
page boundary below the linear offset. That however may not be suitably
aligned to satisfy any hardware specific restrictions. So let's make
sure the page boundary we choose is properly aligned.

Also to play it a bit safer lets split the remaining linear offset into
x and y values instead of just x. This should make no difference for
most platforms since we convert the x and y offsets back into a linear
offset before feeding them to the hardware. HSW+ are different however
and use x and y offsets even with linear buffers, so they might have
trouble if either the x or y get too big.

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

drm/i915: Delete duplicate #defines added for DCx

Delete the duplicate #defines introduced by:

commit 6b457d31ea0465fcadcf6d5044f5f71398954727
Author: A.Sunil Kamath <sunil.kamath@intel.com>
Date:   Thu Apr 16 14:22:09 2015 +0530

drm/i915/skl: Implement enable/disable for Display C5 state.

Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Restarting the Idleness DRRS in drrs_flush

Corrected the documentation on the intel_edp_drrs_flush and
intel_edp_drrs_invalidate.

And accordingly edp_drrs_flush function is modified to restart the idleness
detection after upclocking.

v2: Update kerneldoc

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1)
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'topic/atomic-conversion' into drm-intel-next-queued

The i915 atomic conversion is a real beast and it's not getting easier
wrangling in a separate branch. I'm might be regretting this, but
right after vacation nothing can burst my little bubble here!

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Report to userspace if we have a (presumed) working GPU reset

In igt, we want to test handling of GPU hangs, both for recovery
purposes and for reporting. However, we don't want to inject a genuine
GPU hang onto a machine that cannot recover and so be permenantly
wedged. Rather than embed heuristics into igt, have the kernel report
exactly when it expects the GPU reset to work.

This can also be usefully extended in future to indicate different
levels of fine-grained resets.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tim Gore <tim.gore@intel.com>
Cc: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix build without CONFIG_PM

drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’:
drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’
      atomic_read(&dev->dev->power.usage_count));

Regression from commit a6aaec8be22652a808d6e316d4a92e58cb75e986
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Thu Jun 4 18:23:58 2015 +0100

    drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make sure our labels start at column 0

I noticed one of those and it turned out we have a few lingering around.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/skl: Add debug messages at the start/end of DMC firmware loading

It's handy to have debug message for the "big" events and this one
qualifies IMHO. Also helpful to see what's happening while we're loading
the firwmare and how much time it takes.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove unnecessary () used with WARN()

In Linux, macros are usually well done and protect their arguments
properly, even avoiding multiple evaluations of the parameters. Extra ()
are really not needed.

Cc: Suketu Shah <suketu.j.shah@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.

Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be
set because of security-sensitive bits we don't want userspace to mess
with.  On HSW hardware the whitelisted bits control whether atomic
read-modify-write operations are performed on L3 or on GTI, and when
set to L3 (which can be 10x-30x better performing than on GTI,
depending on the application) require great care to avoid a system
hang, so we currently program them to be handled on GTI by default.

Beignet can immediately start taking advantage of this change to
enable L3 atomics.  Mesa should eventually switch to L3 atomics too,
but a number of non-trivial changes are still required so it will
continue using GTI atomics for now.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Extend the parser to check register writes against a mask/value pair.

In some cases it might be unnecessary or dangerous to give userspace
the right to write arbitrary values to some register, even though it
might be desirable to give it control of some of its bits.  This patch
extends the register whitelist entries to contain a mask/value pair in
addition to the register offset.  For registers with non-zero mask,
any LRM writes and LRI writes where the bits of the immediate given by
the mask don't match the specified value will be rejected.

This will be used in my next patch to grant userspace partial write
access to some sensitive registers.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix command parser to validate multiple register access with the same command.

Until now the software command checker assumed that commands could
read or write at most a single register per packet.  This is not
necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length
list of offset/value pairs and writes them in sequence.  The previous
code would only check whether the first entry was valid, effectively
allowing userspace to write unrestricted registers of the MMIO space
by sending a multi-register write with a legal first register, with
potential security implications on Gen6 and 7 hardware.

Fix it by extending the drm_i915_cmd_descriptor table to represent
multi-register access and making validate_cmd() iterate for all
register offsets present in the command packet.

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Bump CHV PFI credits to 63 when cdclk>=czclk

Switch from using 31 PFI credits to 63 PFI credits when cdclk>=czclk on
CHV. The spec lists both 31 and 63 as "suggested" values, but based on
feedback from hardware folks we should actually be using 63. Originally
I picked the 31 basically by flipping a coin.

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

Fix resume from suspend on IBM X30

This patch fixes the resume from suspend-to-ram on the IBM X30
laptop. The problem is caused by the Bios missing to re-initialize
the iVCH registers, especially the PLL registers.

This patch records the iVCH registers during initialization, and
re-installs this register set when resuming.

Signed-off-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/gtt: Remove _single from page table allocator

We are always allocating a single page. No need to be verbose so
remove the suffix.

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

drm/i915/gtt: Don't leak scratch page on mapping error

Free the scratch page if dma mapping fails.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/vlv: fix RC6 residency time calculation

The divider value to convert from CZ clock rate to ms needs a +1
adjustment on VLV just like on CHV. This matches both the spec and
the accuracy test by pm_rc6_residency.

v2:
- simplify logic checking for the CHV 320MHz special case (Rodrigo)

Testcase: igt/pm_rc6_residency
Signed-off-by: Imre Deak <imre.deak@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76877
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Double the port clock when using double clocked modes with 12bpc

Currently we're forgetting to double the port clock when using double
clocked modes with 12bpc on HDMI. We're only accounting for the 1.5x
factor due to the 12bpc. So further double the 1.5x port clock when we
have a double clocked mode.

Unfortunately I don't have any displays that support both 12bpc and
double clocked modes, so I was unable to test this.

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

drm/i915: Fix hdmi clock readout with pixel repeat

Account for the pixel multiplier when reading out the HDMI
mode dotclock. Makes the state checked happier on my ILK when using
double clocked modes.

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

drm/i915: Check infoframe state more diligently.

Check that the DIP is enabled on the right port on IBX and VLV/CHV as
we're doing on g4x, and also check for all the infoframe enable bits on
all platforms.

Eventually we should track each infoframe type independently, and also
their contents. This is a small step in that direction as .infoframe_enabled()
return value could be easily turned into a bitmask.

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

drm/i915: Disable all infoframes when turning off the HDMI port

Currently we just disable the GCP infoframe when turning off the port.
That means if the same transcoder is used on a DP port next, we might
end up pushing infoframes over DP, which isn't intended. Just disable
all the infoframes when turning off the port.

Also protect against two ports stomping on each other on g4x due to
the single video DIP instance. Now only the first port to enable
gets to send infoframes.

v2: Rebase

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

drm/i915: Fix 12bpc HDMI enable for IBX

Follow the procedure listed in Bspec to toggle the port enable bit off
and on when enabling HDMI with 12bpc and pixel repeat on IBX. The old
code didn't actually enable the port before "toggling" the bit back off,
so the whole workaround was essentially a nop.

Also take the opportunity to clarify the code by splitting the gmch
platforms to a separate (much more straightforward) function.

v2: Rebased due to crtc->config changes

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

drm/i915: Fix HDMI 12bpc TRANSCONF bpc value

IBX BSpec says we must specify 8bpc in TRANSCONF for both 8bpc
and 12bpc HDMI output. Do so.

v2: Pass intel_crtc to intel_pipe_has_type()

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

drm/i915: Enable default_phase in GCP when possible

When the video timings are suitably aligned so that all different
periods start at phase 0 (ie. none of the periods start mid-pixel)
we can inform the sink about this. Supposedly the sink can then
optimize certain things. Obviously this is only relevant when
outputting >8bpc data since otherwise there are no mid-pixel phases.

v2: Rebased due to crtc->config changes

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

drm/i915: Send GCP infoframes for deep color HDMI sinks

GCP infoframes are required to inform the HDMI sink about the color
depth.

Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.

BSpec says we should disable GCP after disabling the port, so do that as
well.

v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
    Rebased due to crtc->config changes

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict with lack of chv phy patches and fixup typo
Chandra spotted.]
Reviewed-by: Chandra Konduru <Chandra.konduru@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement WaEnableHDMI8bpcBefore12bpc:snb, ivb

CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement
it, and to keep things neat pull the code into a function.

v2: Rebased due to crtc->config changes
    s/HDMI_GC/HDMIUNIT_GC/ to match spec better
    Factor out intel_enable_hdmi_audio()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-By: Chandra Konduru <Chandra.konduru@intel.com>
Testecase: igt/kms_render/*
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge remote-tracking branch 'origin/drm-intel-next-queued' into drm-intel-next-queued

Pull in patches Jani applied while I was on vacation.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915: Only enable cursor if it can be enabled.

The cursor should only be enabled if it's visible. This fixes
igt/kms_cursor_crc, which may otherwise produce the following
warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3425 at drivers/gpu/drm/i915/intel_display.c:9995 intel_crtc_update_cursor+0x14c/0x4d0 [i915]()
Missing switch case (0) in i9xx_update_cursor
Modules linked in: i915
CPU: 0 PID: 3425 Comm: kms_cursor_crc Tainted: G        W       4.1.0-rc7-patser+ #4079
Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
 ffffffffc01aad10 ffff8800b083faa8 ffffffff817f7827 0000000080000001
 ffff8800b083faf8 ffff8800b083fae8 ffffffff81084955 ffff8800b083fad8
 ffff8800c4931148 0000000001200000 ffff8800c48b0000 0000000000000000
Call Trace:
 [<ffffffff817f7827>] dump_stack+0x4f/0x7b
 [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0
 [<ffffffff810849d1>] warn_slowpath_fmt+0x41/0x50
 [<ffffffffc0139f2c>] intel_crtc_update_cursor+0x14c/0x4d0 [i915]
 [<ffffffffc01497f4>] __intel_set_mode+0x6c4/0x750 [i915]
 [<ffffffffc0150143>] intel_crtc_set_config+0x473/0x5c0 [i915]
 [<ffffffff81467da9>] drm_mode_set_config_internal+0x69/0x120
 [<ffffffff8146c1b9>] drm_mode_setcrtc+0x189/0x540
 [<ffffffff8145c7e0>] drm_ioctl+0x1a0/0x6a0
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff811e9c28>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff810d0f7d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff812e7746>] ? selinux_file_ioctl+0x56/0x100
 [<ffffffff811e9ee1>] SyS_ioctl+0x81/0xa0
 [<ffffffff81801617>] system_call_fastpath+0x12/0x6f
---[ end trace abf0f71163290a96 ]---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Set hwmode during readout.

This was introduced after converting hw readout to atomic,
so it should have been part of the revert too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: get rid of intel_plane_restore in intel_crtc_page_flip

Use a full atomic call instead. intel_crtc_page_flip will still
have to live until async updates are allowed.

This doesn't seem to be a regression from the convert to atomic,
part 3 patch. During GPU reset it fixes the following warning:

 ------------[ cut here ]------------
WARNING: CPU: 0 PID: 752 at drivers/gpu/drm/drm_crtc.c:5337 drm_mode_page_flip_ioctl+0x27b/0x360()
Modules linked in: i915
CPU: 0 PID: 752 Comm: Xorg Not tainted 4.1.0-rc7-patser+ #4090
Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
 ffffffff81c90866 ffff8800d87c3ca8 ffffffff817f7d87 0000000080000001
 0000000000000000 ffff8800d87c3ce8 ffffffff81084955 ffff880000000000
 ffff8800d87c3dc0 ffff8800d93d1208 0000000000000000 ffff8800b7d1f3e0
Call Trace:
 [<ffffffff817f7d87>] dump_stack+0x4f/0x7b
 [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0
 [<ffffffff81084a35>] warn_slowpath_null+0x15/0x20
 [<ffffffff8146dffb>] drm_mode_page_flip_ioctl+0x27b/0x360
 [<ffffffff8145ccb0>] drm_ioctl+0x1a0/0x6a0
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff812e5540>] ? avc_has_perm+0x20/0x280
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff811ea0f8>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff811f6001>] ? expand_files+0x261/0x270
 [<ffffffff812e7c16>] ? selinux_file_ioctl+0x56/0x100
 [<ffffffff811ea3b1>] SyS_ioctl+0x81/0xa0
 [<ffffffff81801b97>] system_call_fastpath+0x12/0x6f
---[ end trace 9ce834560085bd64 ]---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Do not use atomic modesets in hw readout.

This should fix fallout caused by making intel_crtc_control
and update_dpms atomic, which became a problem after reverting the
atomic hw readout patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Revert "drm/i915: Read hw state into an atomic state struct, v2."

This reverts commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a.

Seems it introduces regressions for 3 different reasons, oh boy..

In bug #90868 as I can see the atomic state will be restored on
resume without the planes being set up properly. Because plane
setup here requires the atomic state, we'll have to settle
for committing atomic planes first.

In bug #90861 the failure appears to affect mostly DP devices,
and happens because reading out the atomic state prevents a modeset
on boot, which would require better hw state readout.

In bug #90874 it's shown that cdclk should be part of the atomic
state, so only performing a single modeset during resume excarbated
the issue.

It's better to fix those issues first, and then commit this patch,
so do that temporarily.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Revert "drm/i915: Make intel_display_suspend atomic, v2."

This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b.

We're not ready yet to make it atomic, we calculate some state in
advance, but without atomic plane support atomic the hw readout will
fail.

It's required to revert this commit to revert the atomic hw
state readout patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: use calculated state for vblank evasion

crtc->active will be gone eventually, and this check should be just as good.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use atomic state for calculating DVO_2X_MODE on i830.

This is a small behavioral change because it leaves DVO_2X_MODE
set between crtc_disable and crtc_enable. This is probably harmless
though and if not should be fixed by calculating 2x mode before
enable/disable pll.

This is needed because intel_crtc->active will be removed eventually.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Calculate haswell plane workaround, v5.

This needs to be done last after all modesets have been calculated.

A modeset first disables all crtc's, so any crtc that undergoes a
modeset counts as inactive.

If no modeset's done, or > 1 crtc's stay w/a doesn't apply.
Apply workaround on the first crtc if 1 crtc stays active.
Apply workaround on the second crtc if no crtc was active.

Changes since v1:
 - Use intel_crtc->atomic as a place to put hsw_workaround_pipe.
 - Make sure quirk only applies to haswell.
 - Use first loop to iterate over newly enabled crtc's only.
   This increases readability.
Changes since v2:
 - Move hsw_workaround_pipe back to crtc_state.
Changes since v3:
 - Return errors from haswell_mode_set_planes_workaround.
Changes since v4:
- Clean up commit message.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove use of crtc->config from i915_debugfs.c

crtc->config is updated to always contain to the active crtc_state
and only differs from crtc_state during crtc_disable. It will
eventually be removed, so start with some low hanging fruit.

For crtc->active the situation is the same; it will be removed
eventually. Instead use crtc->state->active.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use crtc->hwmode for vblanks, v2.

intel_crtc->config will be removed eventually, so use crtc->hwmode.
drm_atomic_helper_update_legacy_modeset_state updates hwmode,
but crtc->active will eventually be gone too. Set dotclock to zero
to indicate the crtc is inactive.

Changes since v1:
- With the hwmode update in drm*update_legacy_modeset_state removed,
  intel_modeset_update_state has to assign it instead.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: move swap state to the right place

This is a preparation for passing crtc state to the helpers.
When converting all users of crtc->config to use the old or
new state it's easier to find regressions when swap_state is
done first.

If crtc->config is swapped at the same place as swap_state
bugs will never be found.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make intel_display_suspend atomic, v2.

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.

Calling intel_set_mode will cause intel_display_set_init_power to be
called, make sure init_power gets set again afterwards.

Changes since v1:
- Fix to compile with v2 of the patch that adds intel_display_suspend.
- Add intel_display_set_init_power.
- Set return value to int to allow error checking.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Implement intel_crtc_control using atomic state, v4

Assume the callers lock everything with drm_modeset_lock_all.

This change had to be done after converting suspend/resume to
use atomic_state so the atomic state is preserved, otherwise
all transitional state is erased.

Now all callers of .crtc_enable and .crtc_disable go through
atomic modeset! :-D

Changes since v1:
- Only check for crtc_state->active in valleyview_modeset_global_pipes.
- Only check for crtc_state->active in modeset_update_crtc_power_domains.
Changes since v2:
- Rework on top of the changed patch order.
Changes since v3:
- Rename intel_crtc_toggle in description to *_control
- Change return value to int.
- Do not add plane state, should be done implicitly already.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Read hw state into an atomic state struct, v2.

To make this work we load the new hardware state into the
atomic_state, then swap it with the sw state.

This lets us change the force restore path in setup_hw_state()
to use a single call to intel_mode_set() to restore all the
previous state.

As a nice bonus this kills off encoder->new_encoder,
connector->new_enabled and crtc->new_enabled. They were used only
to restore the state after a modeset.

Changes since v1:
- Make sure all possible planes are added with their crtc set,
  so they will be turned off on first modeset.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move cdclk and pll setup to intel_modeset_compute_config(), v2.

It makes more sense there, since these are computation steps that can
fail.

Changes since v1:
- Rename __intel_set_mode_checks to intel_modeset_checks (Matt Roper)
- Move intel_modeset_checks to before check_planes, so it won't
  have to be moved later.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Swap planes on each crtc separately, v2.

Repeated calls to begin_crtc_commit can cause warnings like this:
[  169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
[  169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[  169.127840] 3 locks held by kms_flip/1947:
[  169.127843]  #0:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130
[  169.127860]  #1:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130
[  169.127870]  #2:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110
[  169.127879] irq event stamp: 665690
[  169.127882] hardirqs last  enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70
[  169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915]
[  169.127936] softirqs last  enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650
[  169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0
[  169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039
[  169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  169.127957]  ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001
[  169.127964]  0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046
[  169.127970]  ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88
[  169.127981] Call Trace:
[  169.127992]  [<ffffffff817f6907>] dump_stack+0x4f/0x7b
[  169.128001]  [<ffffffff810aebed>] ___might_sleep+0x16d/0x270
[  169.128008]  [<ffffffff810aed38>] __might_sleep+0x48/0x90
[  169.128017]  [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410
[  169.128073]  [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915]
[  169.128138]  [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915]
[  169.128198]  [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915]
[  169.128253]  [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915]
[  169.128279]  [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
[  169.128338]  [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915]
[  169.128378]  [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915]
[  169.128385]  [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10
[  169.128391]  [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120
[  169.128398]  [<ffffffff8119b547>] ? might_fault+0x57/0xb0
[  169.128403]  [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620
[  169.128409]  [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0
[  169.128415]  [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
[  169.128424]  [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530
[  169.128429]  [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10
[  169.128435]  [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100
[  169.128439]  [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0
[  169.128445]  [<ffffffff81800697>] system_call_fastpath+0x12/0x6f

Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc.

The problem here was that the drm_atomic_helper_commit_planes() helper
we were using was basically designed to do

    begin_crtc_commit(crtc #1)
    begin_crtc_commit(crtc #2)
    ...
    commit all planes
    finish_crtc_commit(crtc #1)
    finish_crtc_commit(crtc #2)

The problem here is that since our hardware relies on vblank evasion,
our CRTC 'begin' function waits until we're out of the danger zone in
which register writes might wind up straddling the vblank, then disables
interrupts; our 'finish' function re-enables interrupts after the
registers have been written.  The expectation is that the operations between
'begin' and 'end' must be performed without sleeping (since interrupts
are disabled) and should happen as quickly as possible.  By clumping all
of the 'begin' calls together, we introducing a couple problems:
 * Subsequent 'begin' invocations might sleep (which is illegal)
 * The first 'begin' ensured that we were far enough from the vblank that
   we could write our registers safely and ensure they all fell within
   the same frame.  Adding extra delay waiting for subsequent CRTC's
   wasn't accounted for and could put us back into the 'danger zone' for
   CRTC #1.

This commit solves the problem by using a new helper that allows an
order of operations like:

   for each crtc {
        begin_crtc_commit(crtc)  // sleep (maybe), then disable interrupts
        commit planes for this specific CRTC
        end_crtc_commit(crtc)    // reenable interrupts
   }

so that sleeps will only be performed while interrupts are enabled and
we can be sure that registers for a CRTC will be written immediately
once we know we're in the safe zone.

The crtc->config->base.crtc update may seem unrelated, but the helper
will use it to obtain the crtc for the state. Without the update it
will dereference NULL and crash.

Changes since v1:
- Use Matt Roper's commit message.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use drm_atomic_helper_swap_state in intel_atomic_commit.

And update crtc->config to point to the new state. There is no point
in swapping only part of the state when the rest of the state
should be untouched.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use global atomic state for staged pll, config, v3.

Now that we can subclass drm_atomic_state we can also use it to keep
track of all the pll settings. atomic_state is a better place to hold
all shared state than keeping pll->new_config everywhere.

Changes since v1:
- Assert connection_mutex is held.
Changes since v2:
- Fix swapped arguments to kzalloc for intel_atomic_state_alloc. (Jani Nikula)

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Zap call to drm_plane_helper_disable, v2.

The primary plane can still be configured when crtc is off,
furthermore this is also a noop now that affected planes are
added on modesets.

Changes since v1:
- Move commit so no frontbuffer_bits warnings are generated.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Support modeset across multiple pipes

Compute new pipe_configs for all crtcs in the atomic state. The commit
part of the mode set (__intel_set_mode()) is already enabled to support
multiple pipes, the only thing missing was calculating a new pipe_config
for every crtc.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: calculate primary visibility changes instead of calling from set_config

This should be much cleaner, with the same effects.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: do not wait for vblank when crtc is off

This can happen when turning off a sprite plane. Because the crtc state
is not yet always swapped correctly and transitional helpers are used
the crtc state cannot be relied on.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: update plane state during init

Atomic planes updates rely on having a accurate plane_mask.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make sure all planes and connectors are added on modeset.

Add missing calls to drm_atomic_add_affected_*. This is needed
to convert to atomic planes. When converting to atomic all planes
are needed on modeset. For good measure make sure all connectors
are added too.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use crtc_state->active instead of crtc_state->enable

crtc_state->enable means a crtc is configured, but it may be turned
off for dpms. Until the commit "use intel_crtc_control everywhere"
crtc_state->active was not updated on crtc off, but now
crtc_state->active should be used for tracking whether a crtc is
scanning out or not.

A few commits from now dpms will be handled by calling
intel_set_mode with a different value for crtc_state->active,
which causes a crtc to turn on or off.

At this point crtc->active should mirror crtc_state->active,
so some paranoia from the crtc_disable functions can be removed.

intel_set_mode_setup_plls still checks for ->enable, because all
resources that are needed have to be calculated, else
dpms changes may not succeed.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Set mode_changed for audio in intel_modeset_pipe_config()

A follow up patch will make intel_modeset_compute_config() deal with
multiple crtcs, so move crtc specific stuff into the lower level crtc
specific function.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make __intel_set_mode() take only atomic state as argument

With the use of drm_atomic_helper_update_legacy_modeset_state the
last user of modeset_crtc is removed from this function.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use drm_atomic_helper_update_legacy_modeset_state, v2.

Now that the helper is exported there's no need to duplicate
this code any more.

Changes since v1:
- move intel_modeset_update_staged_output_state call to the right place.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: use intel_crtc_control everywhere, v3.

Having a single path for everything makes it a lot easier to keep
crtc_state->active in sync with intel_crtc->active.

A crtc cannot be changed to active when not enabled, because it means
no mode is set and no connectors are connected.

This should also make intel_crtc->active match crtc_state->active.

Changes since v1:
- Reworded commit message, there's no intel_crtc_toggle.
Changes since v2:
- Change some callers of intel_crtc_control to intel_display_suspend.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: add intel_display_suspend, v2

This is a function used to disable all crtc's. This makes it clearer
to distinguish between when mode needs to be preserved and when
it can be trashed.

Changes since v1:
- Copy power changes from intel_crtc_control.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: get rid of intel_crtc_disable and related code, v3

Now that the dpll updates are (mostly) atomic, the .off() code is a noop,
and intel_crtc_disable does mostly the same as intel_modeset_update_state.

Move all logic for connectors_active and setting dpms to that function.

Changes since v1:
- Move drm_atomic_helper_swap_state up.
Changes since v2:
- Split out intel_put_shared_dpll removal.
Changes since v3:
- Rebase on top of latest drm-intel.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: get rid of put_shared_dpll

Now that the pll updates are staged the put_shared_dpll function
consists only of checks that are done in check_shared_dpll_state
after a modeset too.

The changes to pll->config are overwritten by
intel_shared_dpll_commit, so this entire function is a noop.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bxt: fix DDI PHY vswing scale value setting

According to bspec the DDI PHY vswing scale value is "don't care" in
case the scale enable bit [27] is clear. But this doesn't seem to be
correct. The scale value seems to also matter if the scale mode bit
[26] is set. So both bit 26 and 27 depend on the value. Setting the
scale value to 0 while either bit is set results in a failed modeset on
HDMI (sink reports no signal).

After reset the scale value is 0x98, but according to the spec we have
to program it to 0x9a. So for consistency program it always to 0x9a
regardless of the scale enable bit.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>