Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts with the default view of hw state.

v2: Unmap our default state from the GTT after stealing it from the
context. This should stop us from accidentally overwriting it via the
GTT (and frees up some precious GTT space).

Testcase: igt/gem_ctx_isolation
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-7-chris@chris-wilson.co.uk

In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.

Historically, we omitted the .write=true from the call to set-gtt-domain
in i915_switch_context() in order to avoid a stall between every request
as we would want to wait for the previous context write from the gpu.
Since then, we limit the set-gtt-domain to only occur when we first bind
the vma, so once in use we will never stall, and we are sure to flush
the context following a load from swap.

Equally we never applied the lessons learnt from ringbuffer submission
to execlists; so time to apply the flush of the lrc after load as well.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-6-chris@chris-wilson.co.uk

intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-5-chris@chris-wilson.co.uk

Despite its name intel_init_clock_gating applies both display clock gating
workarounds; GT mmio workarounds and the occasional GT power context
workaround. Worse, sometimes it includes a context register workaround
which we need to apply before we record the default HW state for all
contexts.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-4-chris@chris-wilson.co.uk

GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-3-chris@chris-wilson.co.uk

In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For an extra-layer of finesse, we can check the last
unretired context on the engine; as well as the last retired context
when idle.

v2: verbose verbosity
v3: Always force the switch, even when the engine is idle, and update
the assert that this happens before suspend.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-2-chris@chris-wilson.co.uk

We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
engines and internally map onto the hw.

v2: Remove MAX from the uABI; keep it internal if we need it, but don't
let userspace make the mistake of using it themselves.
v3: s/OTHER/INVALID/
  The use of OTHER is ill-defined, so remove it from the uABI as any
  future new type of engine can define a class to suit it. But keep a
  reserved value for an invalid class, so that we can always
  unambiguously express when something doesn't belong to the
  classification.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v2
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-1-chris@chris-wilson.co.uk

lockdep spotted that the mock tests were using the i915->mm.obj_lock
without first initialiasing it:

>[ 1303.217043] [IGT] drv_selftest: starting subtest mock_objects
<4>[ 1303.240898] Setting dangerous option mock_selftests - tainting kernel
<6>[ 1303.253665] i915: Performing mock selftests with st_random_seed=0xd87ea6c6 st_timeout=1000
<4>[ 1303.254812] INFO: trying to register non-static key.
<4>[ 1303.254816] the code is fine but needs lockdep annotation.
<4>[ 1303.254818] turning off the locking correctness validator.
<4>[ 1303.254820] CPU: 4 PID: 13112 Comm: drv_selftest Tainted: G     U  W       4.14.0-rc8-CI-Patchwork_7058+ #1
<4>[ 1303.254823] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
<4>[ 1303.254825] Call Trace:
<4>[ 1303.254829]  dump_stack+0x68/0x9f
<4>[ 1303.254832]  register_lock_class+0x3fd/0x580
<4>[ 1303.254835]  ? ___slab_alloc.constprop.29+0x157/0x3d0
<4>[ 1303.254837]  ? ___slab_alloc.constprop.29+0x157/0x3d0
<4>[ 1303.254840]  ? sg_kmalloc+0x1e/0x50
<4>[ 1303.254842]  ? debug_smp_processor_id+0x17/0x20
<4>[ 1303.254845]  __lock_acquire+0xa4/0x1b00
<4>[ 1303.254884]  ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254887]  ? __this_cpu_preempt_check+0x13/0x20
<4>[ 1303.254889]  ? sg_kmalloc+0x1e/0x50
<4>[ 1303.254891]  lock_acquire+0xb0/0x200
<4>[ 1303.254893]  ? lock_acquire+0xb0/0x200
<4>[ 1303.254917]  ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254920]  _raw_spin_lock+0x32/0x50
<4>[ 1303.254944]  ? __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254967]  __i915_gem_object_set_pages+0x116/0x1f0 [i915]
<4>[ 1303.254991]  i915_gem_object_get_pages_phys+0x286/0x2b0 [i915]
<4>[ 1303.255015]  ____i915_gem_object_get_pages+0x20/0x60 [i915]
<4>[ 1303.255039]  i915_gem_object_attach_phys+0x137/0x1a0 [i915]
<4>[ 1303.255063]  igt_phys_object+0x45/0x120 [i915]
<4>[ 1303.255094]  __i915_subtests+0x40/0xd0 [i915]
<4>[ 1303.255099]  ? work_on_cpu_safe+0x60/0x60
<4>[ 1303.255131]  i915_gem_object_mock_selftests+0x34/0x50 [i915]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110151919.18451-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

So it appears that commit 5427f207 ("drm/i915: Bump wait-times for
the final CS interrupt before parking") was a little over optimistic in
its belief that it had successfully waited for all residual activity on
the engines before parking. Numerous sightings in CI since then of

<7>[   52.542886] [IGT] core_auth: executing
<3>[   52.561013] [drm:intel_engines_park [i915]] *ERROR* vcs0 is not idle before parking
<7>[   52.561215] intel_engines_park vcs0
<7>[   52.561229] intel_engines_park 	current seqno 98, last 98, hangcheck 0 [-247449 ms], inflight 0
<7>[   52.561238] intel_engines_park 	Reset count: 0
<7>[   52.561266] intel_engines_park 	Requests:
<7>[   52.561363] intel_engines_park 	RING_START: 0x00000000 [0x00000000]
<7>[   52.561377] intel_engines_park 	RING_HEAD:  0x00000000 [0x00000000]
<7>[   52.561390] intel_engines_park 	RING_TAIL:  0x00000000 [0x00000000]
<7>[   52.561406] intel_engines_park 	RING_CTL:   0x00000000
<7>[   52.561422] intel_engines_park 	RING_MODE:  0x00000200 [idle]
<7>[   52.561442] intel_engines_park 	ACTHD:  0x00000000_00000000
<7>[   52.561459] intel_engines_park 	BBADDR: 0x00000000_00000000
<7>[   52.561474] intel_engines_park 	Execlist status: 0x00000301 00000000
<7>[   52.561489] intel_engines_park 	Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no
<7>[   52.561500] intel_engines_park 		ELSP[0] idle
<7>[   52.561510] intel_engines_park 		ELSP[1] idle
<7>[   52.561519] intel_engines_park 		HW active? 0x0
<7>[   52.561608] intel_engines_park Idle? yes
<7>[   52.561617] intel_engines_park

on Braswell, which indicates that the engine just needs that little bit
longer after flushing the tasklet to settle. So give it a few more
milliseconds before declaring an err and applying the emergency brake.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103479Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110112550.28909-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.

Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).

But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset

In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.

This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-3-hdegoede@redhat.com

In order to allow the mock breadcrumbs tests to run without device irqs
being enabled, move the intel_irqs_enabled() assert deeper to just
before we commit to enabling the HW irq.

v2: Add a FIXME explaining that placing the assertion so deep is not
ideal, but a compromise for mock breadcrumbs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107102003.1802-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Originally it was anticipated that timeouts would be a rare event, and
so merit a warning that the test was incomplete. However, for igt we
keep the timeout low, and hitting the timeout is intentional. It no
longer necessitates a warning, but to be expected.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110101110.12042-1-chris@chris-wilson.co.ukReviwed-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Whenever we want to unbind a vma, we must wait on all GPU activity to
complete first. (This is what gives us the ability to do fine grained
eviction and purging by only having to wait on the VMA that we need to
unbind to proceed; though if pushed we can make it a rule that we are
only allowed to unbind already idle VMA and move the burden of the work
and organising the sleep onto the caller.) Currently, we might only
sleep if the vma is still active on the GPU, but in principle
i915_vma_unbind() always implies a sleep, so mark it up with a
might_sleep().
Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103638Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109213450.13875-2-chris@chris-wilson.co.uk

vm_free_page() may call down into set_pages_array_wb() (which itself
sleeps, on x86 at least) but only if on !llc and the caches overflow.
Since this is unlikely, we only rarely trigger the error in practice,
and so to make CI detection of this sleeping bug possible we want to
mark the common vm_free_page() as a potential sleep.
Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103638Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109213450.13875-1-chris@chris-wilson.co.uk

Trying to enable printk debugging for GEM is fraught with the issue of
spam; interactions with HW are very frequent and often boring. However,
one instance where they are not so boring is just before a BUG; here
ftrace provides a facility to dump its ringbuffer on an oops. So for CI
let's enable trace_printk() to capture the last exchanges with HW as a
death rattle.

For example,
[   79.234110] ------------[ cut here ]------------
[   79.234137] kernel BUG at drivers/gpu/drm/i915/intel_lrc.c:907!
[   79.234145] invalid opcode: 0000 [#1] SMP
[   79.234153] Dumping ftrace buffer:
[   79.234158] ---------------------------------
...
[   79.314044] gem_conc-1059    1..s1 79203443us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.2, seqno=145
[   79.314089] gem_conc-1059    1..s. 79220800us : intel_lrc_irq_handler: bcs0 csb[1/1]: status=0x00000018:0x00000005
[   79.314133] gem_conc-1059    1..s. 79220803us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.1, seqno=145
[   79.314177] gem_conc-1062    2..s1 79230458us : intel_lrc_irq_handler: bcs0 in[0]:  ctx=8.1, seqno=146
[   79.314220] gem_conc-1062    2..s1 79230515us : intel_lrc_irq_handler: bcs0 in[0]:  ctx=8.2, seqno=147
[   79.314265] gem_conc-1059    1..s1 79230951us : intel_lrc_irq_handler: bcs0 csb[2/3]: status=0x00000012:0x00000008
[   79.314309] gem_conc-1059    1..s1 79230954us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.2, seqno=147
[   79.314353] gem_conc-1059    1..s1 79230954us : intel_lrc_irq_handler: bcs0 csb[3/3]: status=0x00008002:0x00000008
[   79.314396] gem_conc-1059    1..s1 79230955us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.1, seqno=147
[   79.314402] ---------------------------------

v2: Tweak the formatting to be more consistent between in/out.
v3: do {} while (0) stub macro protection
Suggested-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109143019.16568-1-chris@chris-wilson.co.uk

Eliminate a ton of pointless 'dev' variables in the DP code, and pass
around 'dev_priv' instead of 'dev'.

v2: Rebase
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152758.32257-1-ville.syrjala@linux.intel.com

No need to pass 'dev' or 'dev_priv' when the function already takes
'intel_dp'. Also let's prefer passing 'dev_priv' instead of 'dev'
when we have to pass one or the other.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-10-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Remove intel_digital_port->port and replace its users with
intel_encoder->port. intel_encoder->port is a superset of
intel_digital_port->port, and it works correctly even for
MST encoders.

v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)

Performed with cocci:
@@
@@
struct intel_digital_port {
       ...
-       enum port port;
       ...
}

@@
struct intel_digital_port *D;
expression E;
@@
- D->port = E;

@@
struct intel_digital_port *D;
@@
- D->port
+ D->base.port

@
expression E;
@@
(
- dp_to_dig_port(E)->port
+ dp_to_dig_port(E)->base.port
|
- enc_to_dig_port(E)->port
+ to_intel_encoder(E)->port
)

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E

@@
struct intel_digital_port *D;
identifier I, M;
@@
  I = &D->base
<...
(
- D->base.M
+ I->M
|
- &D->base
+ I
)
...>

@@
identifier D;
expression E;
identifier M;
@@
 D = enc_to_dig_port(&E->base)
<...
(
- D->base.M
+ E->M
|
- &D->base
+ E
)
...>

@@
identifier D, DP;
expression E;
identifier M;
@@
 DP = enc_to_intel_dp(&E->base)
<...
(
- dp_to_dig_port(DP)->base.M
+ E->M
|
- &dp_to_dig_port(DP)->base
+ E
)
...>

@@
expression E;
identifier M;
@@
(
- enc_to_dig_port(&E->base)->base.M
+ E->M
|
- enc_to_dig_port(&E->base)->base
+ E
|
- enc_to_mst(&E->base)->primary->base.port
+ E->port
)

@@
expression E;
identifier D;
@@
- struct intel_digital_port *D = E;
... when != D

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com

Replace dig_port->port with encoder->port in the BXT DPLL selection.
We can do this because both the master encoder and the fake MST encoders
have the same encoder->port value, whereas using dig_port->port only
worked for the master encoder since the fake encoders were't derived
from intel_digital_port. This eliminates the DP MST special case.

Do this by hand because spatch is having problems with the control
flow due to the dig_port assignment happening in two different
branches.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-8-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Replace crtc->config usage with the passed down crtc state.

Also take the opportunity for some s/pipe_config/crtc_state/ while at it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-7-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Rather than digging through encoder->crtc and crtc->config in the
DPIO PHY functions, pass down the correct crtc state from the caller.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-6-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-5-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-4-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-3-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Extract the current crtc from the crtc state rather than via
the legacy encoder->crtc pointer whenever possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031205123.13123-2-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

When we close the VMA, we unbind it from the ppgtt and tear down the
page directory pointing at it. That may trigger us to return WC pages
back to the system, requiring conversion back to WB which itself may
sleep. That makes i915_vma_close() unsuitable for use inside the RCU
read lock, which we need to hold to iterate the radixtree.

The fix is quite simple, we can close all the VMA as we close the ppgtt,
we only need to do that instead of closing them during destruction of
the LUT.

v2: Order between closing the LUT and the ppgtt is important; we use the
vma inside the LUT as a means of retrieving the object, and so we must
clear the LUT before freeing the VMA when closing the ppgtt.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103638
Fixes: 547da76b ("drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)")
Fixes: d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109085540.32264-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

We can program GUC_SHIM_CONTROL register with all expected
bits without use of extra macro defined in fwif.h

v2: rebased without pre-prod code
v3: fixed typo
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-4-michal.wajdeczko@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We don't keep the workarounds for pre-production hardware
(see intel_detect_preproduction_hw) thus we can drop some
extra steps during firmware upload needed only for unsupported
platforms.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-3-michal.wajdeczko@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We silently assumed that DMA transfer will be completed
within assumed timeout and thus we were waiting only at
last step for GuC to become ready. Add intermediate wait
to catch unexpected delays in DMA transfer.
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-2-michal.wajdeczko@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Transfer of GuC firmware requires few steps that currently
are implemented in two large functions. Split this code into
smaller functions to make these steps small and clear.
Also be prepared for potential DMA xfer step failure.

v2: rename function steps (Sagar)
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103151816.62048-1-michal.wajdeczko@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The workaround for this is described as:

"if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if
RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1"

Further documentation in the internal bug referenced by the bspec
suggest that any of the above suggestions should suffice to fix the
issue. We are going with disabling RCC clock gating.

Unfortunately, what we are doing doesn't match the name of the
workaround, but at least it matches its description.

This change improves CNL stability by avoiding some of the hangs seen in
the platform.

v2: Only disable RCC clock gating.
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171103183027.5051-1-rafael.antognolli@intel.com

Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit b7048ea1 ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.

What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.

This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...

v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
    be done before all planes might get disabled.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: NMark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea1 ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.comTested-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

The shared fence array is not autopruning and may continue to grow as an
object is shared between new timelines. Take the opportunity when we
think the object is idle (we have to confirm that any external fence is
also signaled) to decouple all the fences.

We apply a similar trick after waiting on an object, see commit
e54ca977 ("drm/i915: Remove completed fences after a wait")

v2: No longer need to handle the batch pool as a special case.
v3: Need to trylock from within i915_vma_retire as this may be called
form the shrinker - and we may later try to allocate underneath the
reservation lock, so a deadlock is possible.

References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: d07f0e59 ("drm/i915: Move GEM activity tracking into a common struct reservation_object")
Fixes: 80b204bc ("drm/i915: Enable multiple timelines")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The handling of contexts are peculiar. Instead of tieing their vma to
activity, we pin the context. This means that we cannot simply unbind
the context object itself at will (which would normally cause us to wait
for the vma to be idle), but must manually idle the GPU and retire
requests first.

A consequence of this peculiarity is when doing a last desperate attempt
to recover memory. If the memory is tied up inside active context
objects, we will fail to recover any memory simply by trying to unbind
the objects without first doing a wait-for-idle.

A side-effect of removing the call to shrinker_lock_uninterruptible()
from i915_gem_shrinker_oom() was that we removed an unlocked
wait-for-idle, and so lost the "natural" shrinkage of context objects.
By replacing that with a locked wait from inside i915_gem_shrink(), we
not only replace it with the ability to recover all context objects, but
do so for all i915_gem_shrink_all() callers.

v2: Switching requires request allocation, which is not permitted from
inside the shrinker as it only uses ordinary allocations.

References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
Fixes: f2123818 ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Upon parking, if we discover an active engine we dump its state. Follow
that state with an indication of whether the engine was idle.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103479Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107152211.19930-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

During intel_atomic_check(), we do not take the intel_runtime_pm_get()
wakeref and so should do the atomic modeset precalculations without
referring to the HW. However, on Ironlake we see

<7>[   23.487557] [drm:intel_atomic_check [i915]] [CONNECTOR:47:VGA-1] checking for sink bpp constrains
<7>[   23.487615] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to default limit of 24
<4>[   23.487621] RPM wakelock ref not held during HW access
<4>[   23.487652] ------------[ cut here ]------------
<4>[   23.487697] WARNING: CPU: 0 PID: 1343 at drivers/gpu/drm/i915/intel_drv.h:1813 gen5_read32+0x183/0x200 [i915]
<4>[   23.487701] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me ptp mei pps_core prime_numbers
<4>[   23.487784] CPU: 0 PID: 1343 Comm: debugfs_test Tainted: G        W       4.14.0-rc7-CI-Trybot_1378+ #1
<4>[   23.487788] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
<4>[   23.487793] task: ffff8801f90aa6c0 task.stack: ffffc900013ec000
<4>[   23.487838] RIP: 0010:gen5_read32+0x183/0x200 [i915]
<4>[   23.487842] RSP: 0018:ffffc900013efb58 EFLAGS: 00010292
<4>[   23.487849] RAX: 000000000000002a RBX: ffff880205c00000 RCX: 0000000000000006
<4>[   23.487854] RDX: 000000000000140a RSI: ffffffff81d0eb14 RDI: ffffffff81cc26f6
<4>[   23.487857] RBP: ffffc900013efb80 R08: ffff8801f90aaff8 R09: 0000000000000000
<4>[   23.487861] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
<4>[   23.487865] R13: 0000000000046000 R14: ffff88020ffaba78 R15: ffff88020b109bf8
<4>[   23.487870] FS:  00007f53b5e40a40(0000) GS:ffff88021bc00000(0000) knlGS:0000000000000000
<4>[   23.487874] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   23.487878] CR2: 000055e41900c0e8 CR3: 00000001fa0d6005 CR4: 00000000000206f0
<4>[   23.487882] Call Trace:
<4>[   23.487931]  intel_atomic_check+0x745/0x1290 [i915]
<4>[   23.487948]  drm_atomic_check_only+0x459/0x560
<4>[   23.487956]  ? drm_atomic_set_crtc_for_connector+0xc9/0x100
<4>[   23.488025]  drm_atomic_commit+0x18/0x50
<4>[   23.488035]  restore_fbdev_mode_atomic+0x190/0x1f0
<4>[   23.488059]  restore_fbdev_mode+0x32/0x120
<4>[   23.488072]  drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0xa0
<4>[   23.488139]  intel_fbdev_restore_mode+0x34/0x90 [i915]
<4>[   23.488194]  i915_driver_lastclose+0xe/0x10 [i915]
<4>[   23.488208]  drm_lastclose+0x39/0xf0
<4>[   23.488219]  drm_release+0x30c/0x3c0
<4>[   23.488236]  __fput+0xb9/0x200
<4>[   23.488252]  ____fput+0xe/0x10
<4>[   23.488264]  task_work_run+0x89/0xc0
<4>[   23.488278]  exit_to_usermode_loop+0x83/0x90
<4>[   23.488290]  syscall_return_slowpath+0xd0/0x110
<4>[   23.488304]  entry_SYSCALL_64_fastpath+0xaf/0xb1
<4>[   23.488312] RIP: 0033:0x7f53b4317560
<4>[   23.488320] RSP: 002b:00007ffca7e70748 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
<4>[   23.488333] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00007f53b4317560
<4>[   23.488340] RDX: 0000000000000005 RSI: 00007ffca7e70640 RDI: 0000000000000004
<4>[   23.488347] RBP: 000055e417783900 R08: 000055e418f9e290 R09: 0000000000000000
<4>[   23.488356] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
<4>[   23.488363] R13: 00007f53b4302c40 R14: 0000000000000000 R15: 0000000000000000
<4>[   23.488384] Code: b5 f2 f2 e0 0f ff e9 c5 fe ff ff 80 3d 0e 4b 10 00 00 0f 85 c6 fe ff ff 48 c7 c7 30 73 29 a0 c6 05 fa 4a 10 00 01 e8 8e f2 f2 e0 <0f> ff e9 ac fe ff ff e8 51 9d f3 e0 85 c0 0f 85 01 ff ff ff 48
<4>[   23.488780] ---[ end trace 6bc72ce7f1596190 ]---
<7>[   23.488844] [drm:intel_atomic_check [i915]] checking fdi config on pipe A, lanes 1
<7>[   23.488911] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24, dithering: 0

due to intel_fdi_link_freq() poking at FDI_PLL_BIOS_0. Avoid this by
recording the fdi pll frequency during device initiailisation.

v2: Also extract the static FDI PLL frequencies for Sandybridge and
Ivybridge.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107214713.18704-1-chris@chris-wilson.co.ukReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since the partial tiling tests are poking into the GGTT to watch the
fence registers in operation, it itself needs the device rpm wakeref in
order for the GGTT to remain accessible.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107115653.10716-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>

The vma routines are responsible for acquiring the device rpm wakeref
before they poke the HW. However, some of the selftests bypass the
higher level vma routines in order to poke directly at the lowlevel GGTT
functions; these are then responsible for managing rpm themselves.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107114051.10583-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>