There's no need for __raw_i915_read8() & co. to be macros, so make them
inline functions. To avoid typo mistakes generate the inline functions
using preprocessor templates.

We have a few users of the raw register acces functions outside
intel_uncore.c, so let's also move the functions into intel_drv.h.

While doing that switch I915_READ_FW() & co. to use the
__raw_i915_read() functions, and use the _FW macros everywhere
outside intel_uncore.c where we want to read registers without
grabbing forcewake and whatnot. The only exception is
i915_check_vgpu() which itself gets called from intel_uncore.c,
so using the __raw_i915_read stuff there seems appropriate.

v2: Squash in the intel_uncore.c->i915_drv.h move
    Convert I915_READ_FW() to use __raw_i915_read(), and use
    I915_READ_FW() outside of intel_uncore.c (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Since we're not synchronizing the ring request list during error state capture
the request list state might change between the time the corresponding error
request list was allocated and dimensioned to the time when the ring request
list is actually captured into the error state. If this happens then do an
early exit and be aware that the captured error state might not be fully
reliable.

* v2:
- Chris Wilson: Removed WARN_ON from size check since having the error state
  request list and the live driver request list diverge like this is a
  legitimate behaviour.

- Tomas Elf: Removed update of num_request field since this made no sense. Just
  exit and move on.

* v3:
- Chris Wilson: Removed error message at the point of early exit. The user is
  not interested in any state changes happening during the error state capture,
  only in the state that we're trying to capture at the point of the error.
Signed-off-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 51056723.

I somehow managed to combine a patch from Tomas Elf with a totally
unrelated commit message from Chris Wilson. Let's revert this and
reapply properly.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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

We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR disagreeing. No idea what's going on there, but
it's consistent on gen8+, no one seems to care about it and it's
making CI results flaky.

Shut it up.

No idea what's going on here, but we've had fun with PCH interrupts
before:

commit 44498aea
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Feb 22 17:05:28 2013 -0300

    drm/i915: also disable south interrupts when handling them

Note that there's a regression report in Bugzilla, and other
regression reports on the mailing lists keep croping up. But no ill
effects have ever been reported. But for paranoia still keep the
message at a debug level as a breadcrumb, just in case.

This message was introduced in

commit 38cc46d7
Author: Oscar Mateo <oscar.mateo@intel.com>
Date:   Mon Jun 16 16:10:59 2014 +0100

    drm/i915/bdw: Ack interrupts before handling them (GEN8)

v2: Improve commit message a bit.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896Acked-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.

* v2 (Chris Wilson):
Do execlist check and use simpler form of spinlock functions.
Signed-off-by: NTomas Elf <tomas.elf@intel.com>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary
and fixed objects within the same batch
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: "Daniel, Thomas" <thomas.daniel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Don't forget to actually check the cstate->active value when
    tallying up the number of active CRTC's.  (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59561/

We already ensure that pstate->visible = false when crtc->active = false
during runtime programming; make sure we follow the same logic when
reading out initial hardware state.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59564/

Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure.  We still program
the watermarks at the same time we did before, but the computation now
happens much earlier.

While this patch isn't too exciting by itself, it paves the way for
future patches.  The eventual goal (which will be realized in future
patches in this series) is to calculate multiple sets up watermark
values up front, and then program them at different times (pre- vs
post-vblank) on the platforms that need a two-step watermark update.

While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since
this function only applies to ILK-style watermarks and we have a
completely different function for SKL-style watermarks.

Note that the original code had a memcmp() in ilk_update_wm() to avoid
calling ilk_program_watermarks() if the watermarks hadn't changed.  This
memcmp vanishes here, which means we may do some unnecessary result
generation and merging in cases where watermarks didn't change, but the
lower-level function ilk_write_wm_values already makes sure that we
don't actually try to program the watermark registers again.

v2: Squash a few commits from the original series together; no longer
    leave pre-calculated wm's in a separate temporary structure since
    it's easier to follow the logic if we just cut over to using the
    pre-calculated values directly.

v3:
 - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint
   and use intel_atomic_get_crtc_state() to avoid need for extra
   casting.  (Ander)
 - Drop unused intel_check_crtc() function prototype.  (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60363/

A future patch will calculate these during the atomic 'check' phase
rather than at WM programming time, so let's store the watermark
values we're planning to use in the CRTC state; the values actually
active on the hardware remains in intel_crtc.

While we're at it, do some minor restructuring to keep ILK and SKL
values in a union.

v2: Don't move cxsr_allowed to state (Maarten)

v3: Only calculate watermarks in state.  Still keep active watermarks in
    intel_crtc itself.  (Ville)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/59556/

Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.

v2: Fix typo in commit message

v3 (by Matt): Heavily rebased for current codebase.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60366/

The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update.  However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call.  Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60372/

Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.

Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just ensure that ilk_update_wm() is called whenever a
sprite plane is updated in a way that would affect watermarks.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60367/

Requested by Chris, and since we're no longer rebasing the -next queue
I can't rectify history.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445415633-21897-1-git-send-email-daniel.vetter@ffwll.chAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The size / offset information of all firmware ingredients are
now caculated from header. Driver will validate the header and
rsa key size. If any component is out of boundary, driver will
reject the loading too.

v6: Clean up warnings from make docs

v5: Tidy up GuC titles in kernel/Doc

v4: Now using 'size_dw' for those defined in css_header

v3: 1) Move DOC to intel_guc_fwif.h right before css_header
definition. Add more comments.
    2) Change 'size' to 'len' or 'length' to avoid confusion.
    3) Add UOS_RSA_SCRATCH_MAX_COUNT according to BSpec. And
driver validate size of RSA key now.
    4) Add fw component size/offset info to intel_guc_fw.

v2: Add indent into DOC to make fixed-width format rather than
change the tmpl.

v1: 1) guc_css_header is defined as __packed now
    2) Add and correct GuC related topics in kernel/Doc
Signed-off-by: NAlex Dai <yu.dai@intel.com>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Revision checks are almost always accompanied by a platform check. (The
exceptions are platform specific code.) Add helpers to check for a
platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In
most places this simplifies and clarifies the code. It will be obvious
that revid macros are used for the correct platform.

This should make it easier to find all the revision checks for
workarounds for each platform, and make it easier to remove them once we
drop support for early hardware revisions.

This should also make it easier to differentiate between Skylake and
Kabylake revision checks when Kabylake support is added.

v2: rebase
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-3-git-send-email-jani.nikula@intel.com

Prefer inclusive ranges for revision checks rather than "below B0". Per
specs A2 is not used, so revid <= A1 matches revid < B0.
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-2-git-send-email-jani.nikula@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Totally unnecessary.
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-1-git-send-email-jani.nikula@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

intel_crtc_disable_noatomic is called from hw readout during init, resume and possibly reset.
During init it's too early to have a page flip queued, before suspending all page flips
should be finished and during hw reset all page flips should be removed.

It's a bug when there are pending flips here, complain with WARN_ON instead of handling it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/562507A3.3080901@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.

v2: Do not access potentialy old plane state at flip time,
    but store the rotation value at the time of queing the flip.
    (Ville)

v3: No need to pass rotation to intel_queue_mmio_flip since it
    is available in the crtc. (Ville)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cdclk < crtc_clock is not allowed and suggests a different problem
elsewhere in the code.

It is more robust and safe to assume no scaling is possible in
this case with no other downsides since it will also WARN_ON_ONCE
so that this definitely gets noticed.

Call it an assert to help new platform bring-up in simulation.

v2: Better commit msg and use WARN_ON_ONCE to signify the unexpectedness.

v3: Move zero crtc_clock check under the warn. (Ville)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Especially in cases where pre-os does not enable display, cdclk might
not be in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.

v2: Check if BIOS programmed correctly rather than always calling init
    - Do validation of programmed cdctl and what it is expected
    - Only do slk_init_cdclk if validation failed else reuse BIOS
      programmed value

v3: Move the validation logic in a separate sanitize function (Ville)

v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead
    of hardcoded value (Ville)

Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.kumar@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Break out common code from gen8_gt_irq_handler and put it in to
an always inlined function. gcc optimises out the shift at compile
time. (Thomas Daniel/Daniel Vetter/Chris Wilson)

Issue: VIZ-4277
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1445333036-22164-3-git-send-email-nicholas.hoath@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Renamed tmp variable to the more descriptive iir. (Daniel Vetter/
Thomas Daniel)

Issue: VIZ-4277
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445333036-22164-2-git-send-email-nicholas.hoath@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just pull the info out of the state structures rather than staging
it in an additional set of structures.  To make this more
straightforward, we change the signature of several internal WM
functions to take the crtc state as a parameter.

v2:
 - Don't forget to skip cursor planes on a loop in the DDB allocation
   function to match original behavior.  (Ander)
 - Change a use of intel_crtc->active to cstate->active.  They should
   be identical, but it's better to be consistent.  (Ander)
 - Rework more function signatures to pass states rather than crtc for
   consistency. (Ander)

v3:
  - Add missing "+ 1" to skl_wm_plane_id()'s 'overlay' case. (Maarten)
  - Packed formats should pass '0' to drm_format_plane_cpp(), not 1.
    (Maarten)
  - Drop unwanted WARN_ON() for disabled planes when calculating data
    rate for SKL.  (Maarten)

v4:
 - Don't include cursor plane in total relative data rate calculation;
   we've already handled the cursor allocation earlier.
 - Fix 'bytes_per_pixel' calculation braindamage.  Somehow I hardcoded
   the NV12 format as a parameter rather than the actual
   fb->pixel_format, and even then still managed to get the format plane
   wrong.  (Ville)
 - Use plane->state->fb rather than plane->fb in
   skl_allocate_pipe_ddb(); the plane->fb pointer isn't updated until
   after we've done our watermark recalculation, so it has stale
   values.  (Bob Paauwe)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by(v3): Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Paauwe, Bob J <bob.j.paauwe@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
References: http://lists.freedesktop.org/archives/intel-gfx/2015-September/077060.html
References: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077721.html
Smoke-tested-by(v4): Paulo Zanoni <paulo.r.zanoni@intel.com> (SKL)
Link: http://patchwork.freedesktop.org/patch/61968/

Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444987464-8657-1-git-send-email-david.henningsson@canonical.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the beginning we have conflated the size of the global GTT with
that of the per-process context sizes. In recent times (gen8+), those
are no longer the same where the global GTT is limited to 2/4GiB but the
per-process GTT may be anything up to 256TiB. Userspace knows nothing of
this discrepancy and outside of one or two hacks, uses the getaperture
ioctl to determine the maximum size it can use. Let's leave that as
reporting the global GTT and use the context reporting method to
describe the per-process value (which naturally fallsback to reporting
the aliasing or global on older platforms, so userspace can always use
this method where available).

Testcase: igt/gem_userptr_blits/minor-normal-sync
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90065Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we have llc coherency, we can write directly into the ringbuffer
using ordinary cached writes rather than forcing WC access.

v2: An important consequence is that we can forgo the mappable request
for WB ringbuffers, allowing for many more simultaneous contexts.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Update the sanitize_enable_ppgtt for 48 bit PPGTT mode.

Note, aliasing PPGTT remains 32b only.

v2: s/full_64b/full_48b/. (Akash)
v3: Add sanitize_enable_ppgtt changes until here. (Akash)
v4: Update param description (Chris)

Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The atomic helpers set planes_changed on a crtc_state if there is
any plane_state bound to that crtc. If there's none and there is
no pipe update required the crtc has nothing to update, so vblank
evasion can be skipped.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The crtc->active guards are no longer needed now that all state
updates are outside the commit.

Changes since v1:
- Only check crtc->state->active before calling commit_planes_on_crtc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the next commit commit_plane will no longer check if the crtc is active.
To prevent issues with legacy page flips the check should be performed inside
update_primary_planes.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should allow not running plane commit when the crtc is off.
While the atomic helpers update those, crtc->x/y is only updated
during modesets, and primary plane is updated after this function
returns.

Unfortunately non-atomic watermarks and fbc still depend on this
state inside i915, so it has to be kept in sync.

Changes since v1:
- Add comment that the legacy state is updated for fbc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we agreed on not preserving framebuffers pinning is finally
allowed to fail because of signals. Use this to make pinning
and acquire the mutex in an interruptible way too.

Unpinning is still uninterruptible, because it happens as a cleanup
of old state, or undoing pins after one of the pins failed.

The intel_pin_and_fence_fb_obj in page_flip will also wait interruptibly,
and can be aborted now.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

atomic->disabled_planes is a hack that had to exist because
prepare_fb was only called when a new fb was set. This messed
up fb tracking in some circumstances like aborts from
interruptible waits. As a result interruptible waiting in
prepare_plane_fb was forbidden, but other errors could still
cause frontbuffer tracking to be messed up.

Now that prepare_fb is always called, this hack is no longer
required and prepare_fb may fail without consequences.

Changes since v1:
- Clean up a few fb tracking warnings by changing plane->fb to
  plane->state->fb.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.

Addtional note from Imre:

Currently we keep DC6 enabled during modesets and DPAUX transfers, which
is not allowed according to the specification. This can lead at least to
PLL locking failures, DPAUX timeouts and prevent deeper package power
states (PC9/10). Fix this for now by enabling DC6 only when we know the
above events (modeset, DPAUX) can't happen.

This a temporary solution as some issues are still unsolved as described
in [1] and [2], we'll address those as a follow-up.

[1]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html
[2]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html

v1: Initial version.

v2: Based on review comment from Daniel,
- created a seperate patch for csr uninitialization set call.

v3: Rebased on top of latest code.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We still had one lingering RMW in ivb_sprite_disable(), all the other
RMWs were killed off from the sprite code some time ago. Kill the
straggler too.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was accidentally lost in

commit 75d04a37
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Tue Apr 28 17:56:17 2015 +0300

    drm/i915/gtt: Allocate va range only if vma is not bound

While at it implement an improved version suggested by Chris which
avoids the double-bind irrespective of what type of bind is done
first.

Note that this exact bug was already addressed in

commit d0e30adc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jul 29 20:02:48 2015 +0100

    drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt

but the problem is still that originally in

commit 0875546c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Apr 20 09:04:05 2015 -0700

    drm/i915: Fix up the vma aliasing ppgtt binding

if forgotten to take into account there case where we have a
GLOBAL_BIND before a LOCAL_BIND. This patch here fixes that.

v2: Pimp commit message and revert the partial fix.

v3: Split into two functions to specialize on aliasing_ppgtt y/n.

v4: WARN_ON for paranoia in the init sequence, since the ggtt probe
and aliasing ppgtt setup are far apart.

v5: Style nits.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://mid.gmane.org/1444911781-32607-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since SKL has universal planes, we should configure the sprite planes
and the primary plane the same.  For the primary plane we do enable
the pipe gamma on the plane so do the same for the non-primary planes.

Without this, the pipe CRC values will be different for something
displayed on the primary plane and something displayed on a sprite
plane when the ARGB8888 format is used.
Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>