As we close a handle GEM object, we update the drm_file's idr with an
error^W NULL pointer to indicate the in-progress closure, and finally
removing it. If we read the idr directly, we may then see an invalid
object pointer, and in our debugfs per_file_stats() we therefore need
to protect against the entry being invalid.

[ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e
[ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41
57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73
[ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293
[ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002
[ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8
[ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0
[ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000
[ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001
[ 1016.651676] FS:  00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000
[ 1016.651680] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0
[ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1016.651693] Call Trace:
[ 1016.651693] Call Trace:
[ 1016.651703]  idr_for_each+0x8a/0xe8
[ 1016.651711]  i915_gem_object_info+0x2a3/0x3eb
[ 1016.651720]  seq_read+0x162/0x3ca
[ 1016.651727]  full_proxy_read+0x5b/0x8d
[ 1016.651733]  __vfs_read+0x45/0x1bb
[ 1016.651741]  vfs_read+0xc9/0x15e
[ 1016.651746]  ksys_read+0x7e/0xde
[ 1016.651752]  do_syscall_64+0x54/0x68
[ 1016.651758]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Fixes: a8c15954 ("drm/i915: Protect debugfs per_file_stats with RCU lock")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630152724.3734-1-chris@chris-wilson.co.uk

Currently there is no null check for a failed memory allocation
on the dsb object and without this a null pointer dereference
error can occur. Fix this by adding a null check.

Note: added a drm_err message in keeping with the error message style
in the function.

Addresses-Coverity: ("Dereference null return")
Fixes: afeda4f3 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616114221.73971-1-colin.king@canonical.com

There are a couple of spelling mistakes in kernel parameter help text,
namely "helpfull" and "paramters".  Fix them.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616082129.65517-1-colin.king@canonical.com

A single Ri mismatch doesn't automatically mean that the link integrity
is broken. Update and check of Ri and Ri' are done asynchronously. In
case an update happens just between the read of Ri' and the check against
Ri there will be a mismatch even if the link integrity is fine otherwise.
Signed-off-by: NOliver Barta <oliver.barta@aptiv.com>
Reviewed-by: NSean Paul <sean@poorly.run>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504123524.7731-1-oliver.barta@aptiv.com

The linetime watermark is a 9 bit value, which gives us
a maximum linetime of just below 64 usec. If the linetime
exceeds that value we currently just discard the high bits
and program the rest into the register, which angers the
state checker.

To avoid that let's just clamp the value to the max. I believe
it should be perfectly fine to program a smaller linetime wm
than strictly required, just means the hardware may fetch data
sooner than strictly needed. We are further reassured by the
fact that with DRRS the spec tells us to program the smaller
of the two linetimes corresponding to the two refresh rates.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200625200003.12436-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

Update code to reflect recent bspec changes

Bspec: 52890
Bspec: 53508
Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200624215723.2316-1-matthew.s.atwood@intel.com

This workaround now also applies to TGL and RKL, so extend the PCH test
to just capture everthing ICP and beyond.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200617180006.4130501-1-matthew.d.roper@intel.comReviewed-by: NMatt Atwood <matthew.s.atwood@intel.com>

The DP spec says:
"The transmitter shall support at least three levels of voltage
 swing (Levels 0, 1, and 2).

 If only three levels of voltage swing are supported (VOLTAGE
 SWING SET field (bits 1:0) are programmed to 10 (Level 2)),
 this bit shall be set to 1, and cleared in all other cases.

 If all four levels of voltage swing are supported (VOLTAGE
 SWING SET field (bits 1:0) are programmed to 11 (Level 3)),
 this bit shall be set to 1,and cleared in all other cases."

Let's follow that exactly instead of the current apporach
where we can set those also for vswing/preemph levels 0 or 1
(or 2 when the platform max is 3).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The spec requires enabling the MST Virtual Channel payload allocation
- in a separate step - after the transcoder is enabled, follow this.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200623082411.3889-1-imre.deak@intel.com

During encoder enabling we clear the flag before starting the ACT
sequence and wait for the flag, but the clearing is missing during
encoder disabling, add it there too. Since nothing cleared the flag
automatically we could've run subsequent disabling steps too early.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-5-imre.deak@intel.com

It's not clear if the DP_TP_STATUS flags other than the ACT sent flag
have some side-effect, so don't clear those; we don't depend on the
state of these flags anyway.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-4-imre.deak@intel.com

During transcoder enabling we'll configure the transcoder in MST mode
and enable the VC payload allocation, which will start the ACT sequence.
Before waiting for the ACT sequence completion, we need to clear the ACT
sent flag, but based on the above we can do this right before enabling
the transcoder.

For clarity, move the flag clearing closer to where we wait for it.

While at it also factor out some common code.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-3-imre.deak@intel.com

During the initial probing of an MST sink, MST core will determine the
sink's link bandwidth based on its own version of the sink link
rate/lane count caps it reads from the DPCD. At a later point (after
probing and 1 or more modesets) i915 may limit the link parameters wrt.
the original source/sink common caps above due to link training failures
during a modeset and the resulting link training fallback logic.

Based on the above a modeset following another modeset with a link
training error will compute the i915 HW specific and DP protocol timing
parameters (data/link M/N and MST TU values) taking into account only
the unlimited source/sink common caps, but not taking into account the
fallback limits. This will also let DRM core oversubscribe the actual
link bandwidth during the MST payload allocation.

Prevent the above problem by disabling the link training fallback on MST
links for now, until the MST probe time initialization and the MST
compute config logic can deal with changing link parameters.

The misconfigured timings lead at least to a
'Timed out waiting for DP idle patterns'
error.

v2: (Ville)
- Print link training error message on the MST path too.
- Clarify the problem in the commit log.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-2-imre.deak@intel.com

MST encoders must use the master MST transcoder's DP_TP_STATUS and
DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder
connected to a slave transcoder we reset these register addresses in
intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
addresses incorrectly; fix this.

One example where the above overwite happens is the encoder HW state
validation after enabling multiple streams; see
intel_dp_mst_enc_get_config(). After that during disabling any stream
we'll get a

'Timed out waiting for ACT sent when disabling'

error, due to reading from the incorrect DP_TP_STATUS register.

This change replaces
https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
which just papered over the problem.

v2:
- Correct the failure scenario in the commit log. (José)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-1-imre.deak@intel.com

Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.

The stragglers are:

* i915.force_probe and i915.modeset. Needed before dev_priv is
  available. This is fine because the parameters are read-only and never
  modified.

* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
  I915_STATE_WARN_ON would result in massive and ugly churn. This is
  handled by not exposing the parameter via debugfs, and leaving the
  parameter writable in sysfs. This may be fixed up in follow-up work.

* i915.inject_probe_failure. Only makes sense in terms of the module,
  not the device. This is handled by not exposing the parameter via
  debugfs.

v2: Fix uc i915 lookup code (Michał Winiarski)

Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com

We only emit the renderstate once now during module load, it is no
longer a concern that we are delaying context creation and so do not
need to so eagerly optimise. Since the last time we have looked at the
renderstate, we have a pin_map / flush_map facility that supports simple
single mappings, replacing the open-coded kmap_atomic() and
prepare_write. As it should be a single page, of which we only write a
small portion, we stick to a simple WB [kmap] and use clflush on !llc
platforms, rather than creating a temporary WC vmapping for the single
page.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200619234543.17499-2-chris@chris-wilson.co.uk

Since gvt calls pin_map for the shadow batch buffer, this makes the
action of prepare_write [+pin_pages] redundant. We can write into the
obj->mm.mapping directory and the flush_map routine knows when it has to
flush the cpu cache afterwards.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200619234543.17499-1-chris@chris-wilson.co.uk

Since we always enable the busy-stats, the culmulative runtime should be
accurate, and might be useful for diagnosing issues with the engine.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200619191053.9654-1-chris@chris-wilson.co.uk

Smatch warns that we may iterate over an empty array of gt->engines[].
One hopes that this is impossible, but nevertheless we can simply
appease smatch by initialising the timestamp to zero before we starting
probing the busy-time from the engines.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200619151938.21740-1-chris@chris-wilson.co.uk

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.

This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200617220331.GA19550@embeddedor

Return the monotonic timestamp (ktime_get()) at the time of sampling the
busy-time. This is used in preference to taking ktime_get() separately
before or after the read seqlock as there can be some large variance in
reported timestamps. For selftests trying to ascertain that we are
reporting accurate to within a few microseconds, even a small delay
leads to the test failing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-2-chris@chris-wilson.co.uk

A couple of very simple tests to ensure that the basic properties of
per-engine busyness accounting [0% and 100% busy] are faithful.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-1-chris@chris-wilson.co.uk

There is a spelling mistake in a pr_err message. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200617085207.167552-1-colin.king@canonical.com

Like live_unlite_ring, but instead of simply looking at the impact of
intel_ring_direction(), check that preemption more generally works with
different depths of queued requests in the ring.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616233733.18050-1-chris@chris-wilson.co.uk

Rather than mixing [012] and (A1, A2, B2) for the request indices, use
the enums throughout.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616185518.11948-2-chris@chris-wilson.co.uk

Not too long ago, we realised we had issues with a rolling back a
context so far for a preemption request we considered the resubmit not
to be a rollback but a forward roll. This means we would issue a lite
restore instead of forcing a full restore, continuing execution of the
old requests rather than causing a preemption. Add a selftest to
exercise such a far rollback, such that if we were to skip the full
restore, we would execute invalid instructions in the ring and hang.

Note that while I was able to confirm that this causes us to do a
lite-restore preemption rollback (with commit e36ba817 ("drm/i915/gt:
Incrementally check for rewinding") disabled), it did not trick the HW
into rolling past the old RING_TAIL. Myybe on other HW.

References: e36ba817 ("drm/i915/gt: Incrementally check for rewinding")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616185518.11948-1-chris@chris-wilson.co.uk

One i915_request_await_object is enough and we keep the one under the
object lock so it is final.

At the same time move async clflushing setup under the same locked
section and consolidate common code into a helper function.

v2:
 * Emit initial breadcrumbs after aways are set up. (Chris)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200615151449.32605-1-tvrtko.ursulin@linux.intel.com

Since these inline routines only return the desired pointer from the
i915_request(after checking the preconditions for acquiring said
pointer), they can be const.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616183139.4061-1-chris@chris-wilson.co.uk

Fix inconsistent IS_ERR and PTR_ERR in live_timeslice_nopreempt().

The proper pointer to be passed as argument to PTR_ERR() is ce.

This bug was detected with the help of Coccinelle.

Fixes: b72f02d7 ("drm/i915/gt: Prevent timeslicing into unpreemptable requests")
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200616145452.GA25291@embeddedor

For all ddi, encoder->type holds output type as ddi,
assigning it to individual o/p types is no more valid.

Fixes: 362bfb99 ("drm/i915/tgl: Add DKL PHY vswing table for HDMI")

v2: Rebase, no functional change.
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200612082237.11886-1-vandita.kulkarni@intel.com
(cherry picked from commit 94641eb6)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Atm, hotplug interrupts on TypeC ports are left enabled after detecting
an interrupt storm, fix this.
Reported-by: NKunal Joshi <kunal1.joshi@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/351
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com
(cherry picked from commit 587a87b9)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-6-chris@chris-wilson.co.uk
(cherry picked from commit 2bcefd0d)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-5-chris@chris-wilson.co.uk
(cherry picked from commit 806a45c0)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-4-chris@chris-wilson.co.uk
(cherry picked from commit c3b93a94)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-3-chris@chris-wilson.co.uk
(cherry picked from commit 7331c356)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-2-chris@chris-wilson.co.uk
(cherry picked from commit 19f1f627)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.

v2: Leave HSW_SCRATCH to set an explicit value, not or in our disable
bit.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200611093015.11370-1-chris@chris-wilson.co.uk
(cherry picked from commit f93ec5fb)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

According to BSpec the Data Island Packet should be disabled after
disabling the transcoder, but before the transcoder clock select is set
to none. On an ICL RVP, daisy-chained MST config not following this
leads to a hang with the following MCE when disabling the output:

[  870.948739] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: ba00000011000402
[  871.019212] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81aca652> {poll_idle+0x92/0xb0}
[  871.019212] mce: [Hardware Error]: TSC 135a261fe61
[  871.019212] mce: [Hardware Error]: PROCESSOR 0:706e5 TIME 1591739604 SOCKET 0 APIC 0 microcode 20
[  871.019212] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[  871.019212] mce: [Hardware Error]: Machine check: Processor context corrupt
[  871.019212] Kernel panic - not syncing: Fatal machine check
[  871.019212] Kernel Offset: disabled

Bspec: 4287

Fixes: fa37a213 ("drm/i915: Stop sending DP SDPs on ddi disable")
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200609220616.6015-1-imre.deak@intel.com
(cherry picked from commit c980216d)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

In commit 5ba32c7b ("drm/i915/execlists: Always force a context
reload when rewinding RING_TAIL"), we placed the check for rewinding a
context on actually submitting the next request in that context. This
was so that we only had to check once, and could do so with precision
avoiding as many forced restores as possible. For example, to ensure
that we can resubmit the same request a couple of times, we include a
small wa_tail such that on the next submission, the ring->tail will
appear to move forwards when resubmitting the same request. This is very
common as it will happen for every lite-restore to fill the second port
after a context switch.

However, intel_ring_direction() is limited in precision to movements of
upto half the ring size. The consequence being that if we tried to
unwind many requests, we could exceed half the ring and flip the sense
of the direction, so missing a force restore. As no request can be
greater than half the ring (i.e. 2048 bytes in the smallest case), we
can check for rollback incrementally. As we check against the tail that
would be submitted, we do not lose any sensitivity and allow lite
restores for the simple case. We still need to double check upon
submitting the context, to allow for multiple preemptions and
resubmissions.

Fixes: 5ba32c7b ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: NBruce Chang <yu.bruce.chang@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200609151723.12971-1-chris@chris-wilson.co.uk
(cherry picked from commit e36ba817)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Setting ln0 similar to ln1

Fixes: 3b51be4e ("drm/i915/tc: Update DP_MODE programming")
Cc: <stable@vger.kernel.org> # v5.5+
Signed-off-by: NKhaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200608204537.28468-1-khaled.almahallawy@intel.com
(cherry picked from commit 4f72a8ee)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>