Previously GuC uses ring id as engine id because of same definition.
But this is not true since this commit:

commit de1add36
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Fri Jan 15 15:12:50 2016 +0000

    drm/i915: Decouple execbuf uAPI from internal implementation

Added GuC engine id into GuC interface to decouple it from ring id used
by driver.

v2: Keep ring name print out in debugfs; using for_each_ring() where
    possible to keep driver consistent. (Chris W.)
Signed-off-by: NAlex Dai <yu.dai@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453579094-29860-1-git-send-email-yu.dai@intel.com

Since:

commit 82352e90
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Fri Jan 15 17:12:45 2016 +0000

    drm/i915: Cache LRC state page in the context

and:

commit 0eb973d3
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Fri Jan 15 15:10:28 2016 +0000

    drm/i915: Cache ringbuffer GTT VMA

We can also remove the ring buffer start updates on every
context update since the address will not change for the
duration of the LRC pin.

For GuC we can remove the update altogether because it
only cares about the ring buffer start.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1453466567-33369-1-git-send-email-tvrtko.ursulin@linux.intel.com

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

Tvrtko was looking through the execbuffer-ioctl and noticed that the
uABI was tightly coupled to our internal engine identifiers. Close
inspection also revealed that we leak those internal engine identifiers
through the busy-ioctl, and those internal identifiers already do not
match the user identifiers. Fortuitiously, there is only one user of the
set of busy rings from the busy-ioctl, and they only wish to choose
between the RENDER and the BLT engines.

Let's fix the userspace ABI while we still can.

v2: Update the uAPI documentation to explain the identifiers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/gem_busy
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452876706-21620-1-git-send-email-chris@chris-wilson.co.uk

At the moment execbuf ring selection is fully coupled to
internal ring ids which is not a good thing on its own.

This dependency is also spread between two source files and
not spelled out at either side which makes it hidden and
fragile.

This patch decouples this dependency by introducing an explicit
translation table of execbuf uAPI to ring id close to the only
call site (i915_gem_do_execbuffer).

This way we are free to change driver internal implementation
details without breaking userspace. All state relating to the
uAPI is now contained in, or next to, i915_gem_do_execbuffer.

As a side benefit, this patch decreases the compiled size
of i915_gem_do_execbuffer.

v2: Extract ring selection into eb_select_ring. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452870770-13981-1-git-send-email-tvrtko.ursulin@linux.intel.com

Broadwell and later currently use the same unordered command sequence to
update the seqno in the HWS status page and then assert the user
interrupt. We should apply the w/a from legacy (where we do an mmio
read to delay the seqno read after the interrupt), but this is not
enough to enforce coherent seqno visibilty on Skylake. Rather than
search for the proper post-interrupt seqno barrier, use a strongly
ordered command sequence to write the seqno, then assert the user
interrupt from the ring.

v2: Move around the wa tail dwords to avoid adding duplicate code.

v3: Add references, comments on workarounds and bit5 check.

References: https://bugs.freedesktop.org/show_bug.cgi?id=93693
Testcase: igt/gem_ring_sync_loop #skl
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453297415-17793-1-git-send-email-mika.kuoppala@intel.com

The capability to detect unclaimed register access was
recently introduced for vlv/chv platforms. Apparently
there are plenty of unclaimed access on these platforms,
resulting in new dmesg warns. But as we are trying to form
a beachhead for CI/Bat, all new warns are adding to the
noise and thus not desirable at this point in time.

Make it so that if in these platforms the automatic arming
was responsible for mmio_debug enabling, ignore the warns.

If user/dev wants to fix these, he can still do so by
i915.mmio_debug=1234.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453285943-24614-1-git-send-email-mika.kuoppala@intel.com

We've had this since forever, and's randomly reporting issues and as
such causing piles&piles of CI noise. Mika is working on proper debug
infrastructure for this, and on fixing this properly.

Meanwhile make CI more useful for everyone else.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93121Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453233656-12955-1-git-send-email-daniel.vetter@ffwll.ch

There are a few bits of code which the transformations implemented by
the previous patch reveal to be suboptimal, once the notion of a per-
ring default context has gone away. So this tidies up the leftovers.

It could have been squashed into the previous patch, but that would have
made that patch less clearly a simple transformation. In particular, any
change which alters the code block structure or indentation has been
deferred into this separate patch, because such things tend to make
diffs more difficult to read.

v4:	Rebased
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453230175-19330-4-git-send-email-david.s.gordon@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we've eliminated a lot of uses of ring->default_context,
we can eliminate the pointer itself.

All the engines share the same default intel_context, so we can just
keep a single reference to it in the dev_priv structure rather than one
in each of the engine[] elements. This make refcounting more sensible
too, as we now have a refcount of one for the one pointer, rather than
a refcount of one but multiple pointers.

From an idea by Chris Wilson.

v2:	transform an extra instance of ring->default_context introduced by
    42f1cae8 drm/i915: Restore inhibiting the load of the default context
    That patch's commentary includes:
	v2: Mark the global default context as uninitialized on GPU reset so
	    that the context-local workarounds are reloaded upon re-enabling
    The code implementing that now also benefits from the replacement of
    the multiple (per-ring) pointers to the default context with a single
    pointer to the unique kernel context.

v4:	Rebased, remove underused local (Nick Hoath)
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1453230175-19330-3-git-send-email-david.s.gordon@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. At
present, we associate them with the per-engine default context. A future
patch will abolish those per-engine context pointers; but we can already
eliminate a lot of the references to them, just by making the allocator
allow NULL as a shorthand for "an appropriate context for this ring",
which will mean that the callers don't need to know anything about how
the "appropriate context" is found (e.g. per-ring vs per-device, etc).

So this patch renames the existing i915_gem_request_alloc(), and makes
it local (static inline), and replaces it with a wrapper that provides
a default if the context is NULL, and also has a nicer calling
convention (doesn't require a pointer to an output parameter). Then we
change all callers to use the new convention:
OLD:
	err = i915_gem_request_alloc(ring, user_ctx, &req);
	if (err) ...
NEW:
	req = i915_gem_request_alloc(ring, user_ctx);
	if (IS_ERR(req)) ...
OLD:
	err = i915_gem_request_alloc(ring, ring->default_context, &req);
	if (err) ...
NEW:
	req = i915_gem_request_alloc(ring, NULL);
	if (IS_ERR(req)) ...

v4:	Rebased
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NNick Hoath <nicholas.hoath@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453230175-19330-2-git-send-email-david.s.gordon@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In this atomic age, we can't trust the plane->fb pointer anymore.
It might get update too late. Instead we are supposed to use the
plane_state->fb pointer instead. Let's do that in
intel_plane_obj_offset() and avoid problems from dereferencing the
potentially stale plane->fb pointer.

Paulo found this with 'kms_frontbuffer_tracking --show-hidden --run-subtest nop-1p-rte'
but it can be reproduced with just plain old kms_setplane.

I was too lazy to bisect this, so not sure exactly when it broke. The
most obvious candidate
commit ce7f1728 ("drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly")
was actually still fine, so it must have broken some time after that.

Here's the resulting fireworks:
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915]
PGD 8a5f6067 PUD 8a5f5067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole mousedev hid_generic psmouse usbhid atkbd libps2 coretemp hwmon efi_pstore intel_rapl iosf_mbi x86_pkg_temp_thermal efivars pcspkr e1000e sdhci_pci ptp pps_core sdhci i2c_i801 mmc_core i2c_hid hid i8042 serio evdev sch_fq_codel ip_tables x_tables ipv6 autofs4
CPU: 1 PID: 260 Comm: kms_plane Not tainted 4.4.0-skl+ #171
Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B00.1511030553 11/03/2015
task: ffff88008bde2d80 ti: ffff88008a6ec000 task.ti: ffff88008a6ec000
RIP: 0010:[<ffffffffa02d2d9a>]  [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915]
RSP: 0018:ffff88008a6efa10  EFLAGS: 00010086
RAX: 0000000000000001 RBX: ffff8801674f4240 RCX: 0000000000000014
RDX: ffff88008a7440c0 RSI: 0000000000000000 RDI: ffff88008a6efa40
RBP: ffff88008a6efa30 R08: ffff88008bde3598 R09: 0000000000000001
R10: ffff88008b782000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88008a7440c0 R14: 0000000000000000 R15: ffff88008a7449c0
FS:  00007fa0c07a28c0(0000) GS:ffff88016ec40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000008a6ff000 CR4: 00000000003406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff8801674f4240 0000000000000000 ffff88008a7440c0 0000000000000000
 ffff88008a6efaa0 ffffffffa02daf25 ffffffff814ec80e 0000000000070298
 ffff8800850d0000 ffff88008a6efaa0 ffffffffa02c49c2 0000000000000002
Call Trace:
 [<ffffffffa02daf25>] intel_plane_obj_offset+0x2d/0xa9 [i915]
 [<ffffffff814ec80e>] ? _raw_spin_unlock_irqrestore+0x4b/0x60
 [<ffffffffa02c49c2>] ? gen9_write32+0x2e8/0x3b8 [i915]
 [<ffffffffa02eecfc>] skl_update_plane+0x203/0x4c5 [i915]
 [<ffffffffa02ca1ab>] intel_plane_atomic_update+0x53/0x6a [i915]
 [<ffffffffa02494a4>] drm_atomic_helper_commit_planes_on_crtc+0x142/0x1d5 [drm_kms_helper]
 [<ffffffffa02de44b>] intel_atomic_commit+0x1262/0x1350 [i915]
 [<ffffffffa024a0ee>] ? __drm_atomic_helper_crtc_duplicate_state+0x2f/0x41 [drm_kms_helper]
 [<ffffffffa01ef089>] ? drm_atomic_check_only+0x3e3/0x552 [drm]
 [<ffffffffa01ef245>] drm_atomic_commit+0x4d/0x52 [drm]
 [<ffffffffa024996b>] drm_atomic_helper_update_plane+0xcb/0x118 [drm_kms_helper]
 [<ffffffffa01e42e8>] __setplane_internal+0x1c8/0x224 [drm]
 [<ffffffffa01e477f>] drm_mode_setplane+0x14e/0x172 [drm]
 [<ffffffffa01d8117>] drm_ioctl+0x265/0x3ad [drm]
 [<ffffffffa01e4631>] ? drm_mode_cursor_common+0x158/0x158 [drm]
 [<ffffffff810d00ab>] ? current_kernel_time64+0x5e/0x98
 [<ffffffff810a76ea>] ? trace_hardirqs_on_caller+0x17a/0x196
 [<ffffffff8119880f>] do_vfs_ioctl+0x42b/0x4ea
 [<ffffffff811a2b72>] ? __fget_light+0x4d/0x71
 [<ffffffff81198911>] SyS_ioctl+0x43/0x61
 [<ffffffff814ed057>] entry_SYSCALL_64_fastpath+0x12/0x6f

Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_plane
Reported-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453220597-28973-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Having this on stack triggers the -Wframe-larger-than=1024 and
is not nice to put such big things on the kernel stack anyway.

This required a little bit of refactoring to handle the new
failure path from vlv_force_pll_on.

v2: Corrected some whitespace.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453217117-26125-1-git-send-email-tvrtko.ursulin@linux.intel.com

This reverts commit 396e33ae.

This commit was triggering some FIFO underrun warnings on ILK-IVB
platforms (but surprisingly not on HSW/BDW that share more or less the
same codepaths).  These underruns were caught by the continuous
integration (CI) system and could be reproduced consistently when
running the basic acceptance tests (BAT) on the affected platforms.

Note that this revert will cause a visible regression for some
end-users; the "flicker when mouse moves between monitors in X" issue
that was reported before this patch was merged will now return.  However
regressions that are visible to CI have higher priority since they
prevent proper testing of future patches on those platforms.  Hopefully
we'll be able to figure out the cause of the underruns quickly and
remerge an improved version of this patch to fix the regression.

Cc: Daniel Vetter <daniel@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93640Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453232584-8543-1-git-send-email-matthew.d.roper@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Without the DOC:, kernel-doc confuses the documentation block for
something else.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453101588-18008-3-git-send-email-jani.nikula@intel.com

Apparently accidental or misplaced /** kernel-doc comments, confusing
the tool. Turn them to normal comments.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453101588-18008-2-git-send-email-jani.nikula@intel.com

The comments were never proper kernel-doc, but with SDVO it's not worth
the trouble to make them kernel-doc. Just turn them into normal
comments.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453101588-18008-1-git-send-email-jani.nikula@intel.com

In GuC submission mode, driver has to provide a list of registers to be
save/restored during gpu reset, make the max no. of registers value consistent
with that of the value defined in FW. If they are not in sync then register
save/restore during gpu reset won't work as expected.

Cc: Alex Dai <yu.dai@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453132776-22229-1-git-send-email-arun.siluvery@linux.intel.comReviewed-by: NAlex Dai <yu.dai@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is an expected error given the lack of the firmware so emit it at
KERN_NOTICE and not KERN_ERROR. Also include the firmware URL in the
user facing message so that the user can investigate and fix the issue
on their own, and also explain the consequence in plain language.

The complete failure message, including the first line from the firmware
loader, becomes

i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2
i915 0000:00:02.0: Failed to load DMC firmware [https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling runtime power management.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452706695-13518-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use hlist_for_each_entry() instead of hlist_for_each() to simplify
the code.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Link: http://patchwork.freedesktop.org/patch/msgid/b80568b2990ebcc145229a132f045e852ac51ad6.1453126187.git.geliangtang@163.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler().
The former is a mask, the latter just the bit number.

Fortunately the only thing skl_update_scaler() does with the rotation
is check if it's 90/270 degrees or not, and so in this case it would
still do the right thing.

Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444917718-28495-1-git-send-email-ville.syrjala@linux.intel.com
Fixes: 6156a456 ("drm/i915: skylake primary plane scaling using shared scalers")
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>

On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logic.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 061e4b8d ("drm/i915: clean up atomic plane check functions, v2.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.

The struct_mutex needs to be held before tearing down GuC.

v1: Move i915_guc_submission_disable out of i915_guc_submission_fini and
    take struct_mutex lock before release GuC client. (Dave Gordon)
v2: Add the locking for failure case in guc_fw_fetch. (Dave Gordon)
    Add i915_guc_submission_fini for failure case in intel_guc_ucode_load.
Signed-off-by: NAlex Dai <yu.dai@intel.com>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452711710-4505-1-git-send-email-yu.dai@intel.com

LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.

v2: Also cache the mapping. (Chris Wilson)
v3: Unmap on the error path.
v4: No need to cache the page. (Chris Wilson)
v5: No need to dirty the page on unpin. (Chris Wilson)
v6: kmap() cannot fail and use kmap_to_page to simplify unpin.
    (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1452877965-32042-1-git-send-email-tvrtko.ursulin@linux.intel.com

Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.

v2: Renamed gtt_start to gtt_offset. (Daniel Vetter)
v3: Cache the VMA instead of address. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1452870629-13830-2-git-send-email-tvrtko.ursulin@linux.intel.com

LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
places where the struct_mutex cannot be grabbed (irq handlers).

To avoid that this patch caches some interesting bits and values
in the engine and context structures.

Some usages are also removed where they are not needed like a
few asserts which are either impossible or have been checked
already during engine initialization.

Side benefit is also that interrupt handlers and command
submission stop evaluating invariant conditionals, like what
Gen we are running on, on every interrupt and every command
submitted.

This patch deals with logical ring context id and descriptors
while subsequent patches will deal with the remaining issues.

v2:
 * Cache the VMA instead of the address. (Chris Wilson)
 * Incorporate Dave Gordon's good comments and function name.

v3:
 * Extract ctx descriptor template to a function and group
   functions dealing with ctx descriptor & co together near
   top of the file. (Dave Gordon)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452870629-13830-1-git-send-email-tvrtko.ursulin@linux.intel.com

No need to call ktime_get_raw_ns twice per unlimited wait and can
also elimate a local variable.

v2: Added comment about silencing the compiler warning. (Daniel Vetter)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452870672-13901-1-git-send-email-tvrtko.ursulin@linux.intel.com

Pull in Dave's drm-next pull request to have a clean base for 4.6.
Also, we need the various atomic state extensions Maarten recently
created.

Conflicts are just adjacent changes that all resolve to nothing in git
diff.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Merge tag 'drm-intel-next-fixes-2016-01-14' of git://anongit.freedesktop.org/drm-intel into drm-next

misc i915 fixes all over the place.

* tag 'drm-intel-next-fixes-2016-01-14' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page
  drm/i915: Widen return value for reservation_object_wait_timeout_rcu to long.
  drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
  drm/i915: shut up gen8+ SDE irq dmesg noise, again
  drm/i915: Restore inhibiting the load of the default context
  drm/i915: Tune down rpm wakelock debug checks
  drm/i915: Avoid writing relocs with addresses in non-canonical form
  drm/i915: Move Braswell stop_machine GGTT insertion workaround

Since your main drm-next pull isn't out of the door yet I figured I might
as well flush out drm-misc instead of delaying for 4.6. It's really just
random stuff all over, biggest thing probably connector_mask tracking from
Maarten.

* tag 'topic/drm-misc-2016-01-17' of git://anongit.freedesktop.org/drm-intel: (24 commits)
  drm/fb_cma_helper: Remove implicit call to disable_unused_functions
  drm/sysfs: use kobj_to_dev()
  drm/i915: Init power domains early in driver load
  drm: Do not set connector->encoder in drivers
  apple-gmux: Add initial documentation
  drm: move MODULE_PARM_DESC to other file
  drm/edid: index CEA/HDMI mode tables using the VIC
  drm/atomic: Remove drm_atomic_connectors_for_crtc.
  drm/i915: Update connector_mask during readout, v2.
  drm: Remove opencoded drm_gem_object_release_handle()
  drm: Do not set outparam on error during GEM handle allocation
  drm/docs: more leftovers from the big vtable documentation pile
  drm/atomic-helper: Reject legacy flips on a disabled pipe
  drm/atomic: add connector mask to drm_crtc_state.
  drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state, v2.
  drm/atomic: Add __drm_atomic_helper_connector_reset, v2.
  drm/i915: Set connector_state->connector using the helper.
  drm: Use a normal idr allocation for the obj->name
  drm: Only bump object-reference count when adding first handle
  drm: Balance error path for GEM handle allocation
  ...

rotate_pages() doesn't modify the passed in dma addresses, so make
them const.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452777736-4909-4-git-send-email-ville.syrjala@linux.intel.com

Just for clarity set the type for i915_ggtt_view_normal explicitly.

While at it fix the indentation fail for i915_ggtt_view_rotated.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452777736-4909-3-git-send-email-ville.syrjala@linux.intel.com

Don't increment obj->framebuffer_references until we know we actually
managed to create the framebuffer.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452777736-4909-2-git-send-email-ville.syrjala@linux.intel.com

The drm_fbdev_cma_init function always calls the
drm_helper_disable_unused_functions. Since it's part of the usual probe
process, all the drivers using that helper will end up having their encoder
and CRTC disable functions called at probe if their device has not been
reported as enabled.

This could be fixed by reading out from the registers the current state of
the device if it is enabled, but even that will not handle the case where
the device is actually disabled.

Moreover, the drivers using the atomic modesetting expect that their enable
and disable callback to be called when the device is already enabled or
disabled (respectively).

We can however fix this issue by moving the call to
drm_helper_disable_unused_functions out of drm_fbdev_cma_init and make the
drivers needing it (all the drivers calling drm_fbdev_cma_init and not
using the atomic modesetting) explicitly call it.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452785109-6172-14-git-send-email-maxime.ripard@free-electrons.comAcked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.

The clamping has been HDMI specific since its introduction in

commit 996a2239
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Apr 19 11:24:34 2013 +0200

    drm/i915: Disable high-bpc on pre-1.4 EDID screens

Cc: stable@vger.kernel.org
Reported-and-tested-by: NDihan Wickremasuriya <nayomal@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com

Two errors in a single line. The size was read from the wrong offset,
and the end index didn't take the five bytes for sequence byte and size
of sequence into account. Fix it all, and break up the calculations a
bit to make it clearer.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-and-tested-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 2a33d934 ("drm/i915/bios: add support for MIPI sequence block v3")
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452784327-27258-1-git-send-email-jani.nikula@intel.com

We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
that writes performed via the HDC are visible in memory.  Fixes an
intermittent failure in a Piglit test that writes to a BO from a
shader using GL atomic counters (implemented as HDC untyped atomics)
and then expects the memory to read back the same value after mapping
it on the CPU.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298Tested-by: NMark Janes <mark.a.janes@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452740379-3194-1-git-send-email-currojerez@riseup.netSigned-off-by: NJani Nikula <jani.nikula@intel.com>

ilk_program_watermarks() is supposed to merge the active watermarks from
all pipes. Thus we need to use the active config too instead of some
precomputed stuff.

Fixes: aa363136 ("drm/i915: Calculate watermark configuration during atomic check (v2)")
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452776015-22076-2-git-send-email-ville.syrjala@linux.intel.com

ilk_compute_pipe_wm() assumes as zeroed pipe_wm structure when it
starts. We used to pass such a zeroed struct in, but this got broken
when the pipe_wm structure got embedded in the crtc state.

To fix it without too much fuzz, we need to resort to a memset().

Fixes: 4e0963c7 ("drm/i915: Calculate pipe watermarks into CRTC state (v3)")
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452776015-22076-1-git-send-email-ville.syrjala@linux.intel.com

Add a common function to return "on" or "off" string based on the
argument, and drop the local versions of it.

This is the onoff version of

commit 42a8ca4c
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Aug 27 16:23:30 2015 +0300

    drm/i915: add yesno utility function
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452768814-29787-1-git-send-email-jani.nikula@intel.com