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

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

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

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

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

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

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

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

intel_display_setup_hw_state now only reads out the atomic state.

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

After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Yeah this isn't really fixes but it's a nice cleanup to
clarify the code but not really worth the hassle of backmerging. So
just add to -fixes, we're still early in -rc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This broken code was introduced in

commit aa7471d2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Apr 1 11:15:21 2015 +0300

    drm/i915: add i915 specific connector debugfs file for DPCD

v2: Drop hunk that accidentally crept in.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: François Valenduc <francoisvalenduc@gmail.com>
Reported-by: NFrançois Valenduc <francoisvalenduc@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1572.421010] IP: [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0
[ 1572.428892] Oops: 0000 [#1] SMP
[ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm
[ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted 4.0.0_kcloud_3f0360_20150429+ #588
[ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915]
[ 1572.450876] task: ffff880002f428f0 ti: ffff880035724000 task.ti: ffff880035724000
[ 1572.455557] RIP: 0010:[<ffffffffa00b2514>]  [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.460423] RSP: 0018:ffff880035727ce8  EFLAGS: 00010286
[ 1572.465262] RAX: ffff880073f1643c RBX: ffff880002da9058 RCX: ffff880073e5db40
[ 1572.470179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880035727ce8
[ 1572.475107] RBP: ffff88007bb11a00 R08: 0000000000000000 R09: 0000000000000000
[ 1572.480034] R10: 0000000000362200 R11: 0000000000000008 R12: 0000000000000000
[ 1572.484952] R13: ffff880035727d78 R14: ffff880002dc1c98 R15: ffff880002dc1dc8
[ 1572.489886] FS:  0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000
[ 1572.494883] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1572.499859] CR2: 0000000000000000 CR3: 000000017572a000 CR4: 00000000001006e0
[ 1572.504842] Stack:
[ 1572.509834]  ffff88017b0090c0 ffff880073f16438 ffff880002da9058 ffff880073f1643c
[ 1572.514904]  0000000000000246 ffff880100000000 ffff88007bb11a00 ffff880002ddeb10
[ 1572.519985]  ffff8801759f79c0 ffffffffa0092ff0 0000000000000000 ffff88007bb11a00
[ 1572.525049] Call Trace:
[ 1572.530093]  [<ffffffffa0092ff0>] ? i915_gem_context_free+0xa8/0xc1 [i915]
[ 1572.535227]  [<ffffffffa009b969>] ? i915_gem_request_free+0x4e/0x50 [i915]
[ 1572.540347]  [<ffffffffa00b5533>] ? intel_execlists_retire_requests+0x14c/0x159 [i915]
[ 1572.545500]  [<ffffffffa009d9ea>] ? i915_gem_retire_requests+0x9d/0xeb [i915]
[ 1572.550664]  [<ffffffffa009dd8c>] ? i915_gem_retire_work_handler+0x4c/0x61 [i915]
[ 1572.555825]  [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d
[ 1572.560951]  [<ffffffff8104d278>] ? worker_thread+0x24d/0x339
[ 1572.566033]  [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa
[ 1572.571140]  [<ffffffff81050b25>] ? kthread+0xce/0xd6
[ 1572.576191]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[ 1572.581228]  [<ffffffff8179b3c8>] ? ret_from_fork+0x58/0x90
[ 1572.586259]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55
[ 1572.596981] RIP  [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.602464]  RSP <ffff880035727ce8>
[ 1572.607911] CR2: 0000000000000000

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The poor in_dbg_master() check was the only one without a reason
string. Give it a reason string so it won't feel excluded.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is all internal i915.ko work, let's start using intel_crtc for
everything.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

If I get a NACK here I'll propose the opposite: convert all the
functions that currently take dev_priv to take dev.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

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

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

v2: Drop UMS parts.

v3: Update commit message to reflect that the reg save/restore code is
gone (Ville).
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

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

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

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

v2:
  - Rebase after the stolen_remove_node() dev_priv patch move.
  - I realized that after we fixed a few things related to the FBC CFB
    size checks, we're not reallocating the CFB anymore with FBC
    enabled, so we can just move all the locking to i915_gem_stolen.c
    and stop worrying about freezing all the stolen alocations while
    freeing/rellocating the CFB. This allows us to fix the "Too
    coarse" observation from Chris.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

v2:
  - Rebase after the remove_node() changes on the previous patch.
Requested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

v2:
  - Add dev_priv as remove_node() argument since we'll need it later
    (Chris).
Requested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

(from getparam patch)

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

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

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

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

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

This patch adds support for 0.85V VccIO on Skylake Y,
separate buffer translation tables for Skylake U,
and support for I_boost for the entries that needs this.

Changes in v2:
* Refactored the code a bit to move all DDI signal level setup to
  intel_ddi.c

Issue: VIZ-5677
Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com>
[danvet: Apply style polish checkpatch suggested.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Turns out the VLV/CHV system agent doesn't understand memory
latencies, so trying to rely on the PND deadline mechanism is not
going to fly especially when DDR DVFS is enabled. Currently we try to
avoid the problems by lying to the system agent about the deadlines
and setting the FIFO watermarks to 8 cachelines. This however leads to
bad memory self refresh residency.

So in order to satosfy everyone we'll just give up on the deadline
scheme and program the watermarks old school based on the worst case
memory latency.

I've modelled this a bit on the ILK+ approach where we compute multiple
sets of watermarks for each pipe (PM2,PM5,DDR DVFS) and when merge thet
appropriate one later with the watermarks from other pipes. There isn't
too much to merge actually since each pipe has a totally independent
FIFO (well apart from the mess with the partially shared DSPARB
registers), but still decopuling the pipes from each other seems like a
good idea.

Eventually we'll want to perform the watermark update in two phases
around the plane update to avoid underruns due to the single buffered
watermark registers. But that's still in limbo for ILK+ too, so I've not
gone that far yet for VLV/CHV either.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Read out the current watermark settings from the hardware at driver init
time. This will allow us to compare the newly calculated values against
the currrent ones and potentially avoid needless WM updates.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new DRRS code it kinda sticks out, and we never managed to
get this to work well enough without causing issues. Time to wave
goodbye.

I've decided to keep the logic for programming the reduced clocks
intact, but everything else is gone. If anyone ever wants to resurrect
this we need to redo it all anyway on top of the frontbuffer tracking.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is not
necessarily the same as when the request was submitted to the driver. This is
especially true when the GPU scheduler arrives and decouples driver submission
from hardware submission. Note also that it is only in the case where the add
request comes from an execbuff call that there is a client to associate. Any
other add request call is kernel only so does not need to do it.

This patch moves the client association into a separate function. This is then
called from the execbuffer code path itself at a sensible time. It also removes
the now redundant 'file' pointer from the add request parameter list.

An extra cleanup of the client association is also added to the request clean up
code for the eventuality where the request is killed after association but
before being submitted (e.g. due to out of memory error somewhere). Once the
submission has happened, the request is on the request list and the regular
request list removal will clear the association. Note that this still needs to
happen at this point in time because the request might be kept floating around
much longer (due to someone holding a reference count) and the client should not
be worrying about this request after it has been retired.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Converted i915_gem_l3_remap() to take a request structure instead of a ring.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.

The sequence is now to create a request, queue the work to the ring, assign the
known request to the flip queue work item then actually submit the work and post
the request.

Note that every single flip function used to finish with
'__intel_ring_advance(ring);'. However, immediately after they return there is
now an add request call which will do the advance anyway. Thus the many
duplicate advance calls have been removed.

v2: Updated commit message with comment about advance removal.

v3: The request can now be allocated by the _sync() code earlier on. Thus the
page flip path does not necessarily need to allocate a new request, it may be
able to re-use one.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.

v2: Much more complex patch to share a single request between the sync and the
page flip. The _sync() function now supports lazy allocation of the request
structure. That is, if one is passed in then that will be used. If one is not,
then a request will be allocated and passed back out. Note that the _sync() code
does not necessarily require a request. Thus one will only be created until
certain situations. The reason the lazy allocation must be done within the
_sync() code itself is because the decision to need one or not is not really
something that code above can second guess (except in the case where one is
definitely not required because no ring is passed in).

The call chains above _sync() now support passing a request through which most
callers passing in NULL and assuming that no request will be required (because
they also pass in NULL for the ring and therefore can't be generating any ring
code).

The exeception is intel_crtc_page_flip() which now supports having a request
returned from _sync(). If one is, then that request is shared by the page flip
(if the page flip is of a type to need a request). If _sync() does not generate
a request but the page flip does need one, then the page flip path will create
its own request.

v3: Updated comment description to be clearer about 'to_req' parameter (Tomas
Elf review request). Rebased onto newer tree that significantly changed the
synchronisation code.

v4: Updated comments from review feedback (Tomas Elf)

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.

Also removed the warning that the request's context must match the last context
switch's context. As the context switch now gets the context object from the
request structure, there is no longer any scope for the two to become out of
step.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
allocated request structure in to each step rather than passing a ring
structure. This patch updates both i915_ppgtt_init_ring() and
i915_gem_context_enable() to take request pointers.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and this does its own private
_i915_add_request() call.

This patch adds explicit request creation and submission to the top level loop
and removes the add_request() from deep within the sub-functions.

v2: Updated for removal of batch_obj from add_request call in previous patch.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.

This patch moves the ring looping out of that function in to the top level
caller i915_gem_init_hw(). This means the a single pass can be made over all
rings doing the PPGTT, L3 remap and context initialisation of each ring
altogether.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard batch buffer submission process.

This patch adds a flag to _add_request() to specify whether the flush is
required or not.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the error
case. This means that the execbuff code is no longer dependent upon the OLR
keeping track of the request so as to not leak it when things do go wrong. Note
that in the success case, the i915_add_request() at the end of the submission
function will tidy up the request and clear the OLR.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring->outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it knowing
exactly which request it actually owns.

v2: Updated for new i915_gem_request_alloc() scheme.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Reviewed-by: NTomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>