Those regs are added in order to slove the following complains:

 [70811.201818] gvt: vgpu(1) Invalid FORCE_NONPRIV write 2341 at offset 24d8
 [70811.201825] gvt: vgpu(1) Invalid FORCE_NONPRIV write 2351 at offset 24dc
 [70811.201831] gvt: vgpu(1) Invalid FORCE_NONPRIV write 10000d82 at offset 24e0
 [70811.201837] gvt: vgpu(1) Invalid FORCE_NONPRIV write 10064844 at offset 24e4

So solve them by adding the required regs to the whitelist.
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200302083130.17831-1-tina.zhang@intel.com

Teach gvt to use intel_gt directly as it currently assumes direct HW
access.

[Zhenyu: rebase, fix compiling]

Cc: Ding Zhuocheng <zhuocheng.ding@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-3-zhenyuw@linux.intel.com

Stop trying to escape out of the gvt layer to find the engine that we
initially setup for use with gvt. Record the engines during initialisation
and use them henceforth.

add/remove: 1/4 grow/shrink: 22/28 up/down: 341/-1410 (-1069)

[Zhenyu: rebase, fix nonpriv register check fault, fix gvt engine
thread run failure.]

Cc: Ding Zhuocheng <zhuocheng.ding@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-2-zhenyuw@linux.intel.com

Remove extra chatty message for debugfs scan_nonprivbb which is used
to enable scan for non privileged batch on specific engine. Just write
target i915 engine mask instead.

Cc: Ding Zhuocheng <zhuocheng.ding@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-1-zhenyuw@linux.intel.com

Commit c3b5a843 ("drm/i915/gvt: Enable gfx virtualiztion for CFL")
added the support on CFL. The vgpu emulation hotplug support on CFL was
supposed to be included in that patch. Without the vgpu emulation
hotplug support, the dma-buf based display gives us a blur face.

So fix this issue by adding the vgpu emulation hotplug support on CFL.

Fixes: c3b5a843 ("drm/i915/gvt: Enable gfx virtualiztion for CFL")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200227010041.32248-1-tina.zhang@intel.com

When vgpu ptr is unavailable, the drm_WARN* can hang the whole system
due to the drm pointer is NULL. This patch fixes this issue by using
WARN directly which won't care about the drm pointer.

Fixes: 12d58619 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available")
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200225053527.8336-1-tina.zhang@intel.com

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-9-pankaj.laxminarayan.bharadiya@intel.com

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-8-pankaj.laxminarayan.bharadiya@intel.com

Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.

The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.

v2:
- rebased onto gvt-staging (no conflicts)
Signed-off-by: NJulian Stecklina <julian.stecklina@cyberus-technology.de>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200217163858.26496-1-julian.stecklina@cyberus-technology.de

Backmerge to pull in
https://patchwork.freedesktop.org/patch/353621/?series=73544&rev=1Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

If one of the synced crtcs needs a full modeset, we need
to make sure all the synced crtcs are forced a full
modeset.

v3:
* Remove ~BIT(cpu_trans) which is a nop (Ville)
* use get_new_crtc_state and remove error check (Ville)

v2:
* Add tiles based on cpu_trans check (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-3-manasi.d.navare@intel.com

This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.

v3:
* Make crtc_state const, remove crtc state NULL init (Ville)
v2:
* Correct indentation
* Rename to intel_ddi_port_sync_transcoders (Ville)
* remove unwanted debug (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-2-manasi.d.navare@intel.com

Add an optional secondary encoder state compute hook. This gets
called after the normak .compute_config() has been called for
all the encoders in the state. Thus in the new hook we can rely
on all derived state populated by .compute_config() to be already
set up. Should be useful for MST and port sync master/slave
transcoder selection.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-1-manasi.d.navare@intel.com

For dgfx, we do not need to reconfigure the IA/ring frequencies of the
main processors as they are distinct devices.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NAndi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219130119.1457693-1-chris@chris-wilson.co.uk

Currently, we check that a new context has a clear set of general
purpose registers. Add a little bit of hostility by preempting our new
context and re-poisoning the GPR to ensure that there is no context
leakage from preemption.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219123418.1447428-1-chris@chris-wilson.co.uk

Check that the CTX_TIMESTAMP is monotonic across context save/restore
and upon preemption.

References: https://gitlab.freedesktop.org/drm/intel/issues/1233Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219112004.1412791-1-chris@chris-wilson.co.uk

Read the rawclk_freq during runtime info probing, prior to its first use
in computing the CS timestamp frequency. Then store it in the runtime
info, and include it in the debug printouts.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/834Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk

On dgfx, we only use l3cc and not mocs, but we share the table
containing both register definitions with Tigerlake. This confuses our
selftest that verifies that both sets of registers do contain the values
in our tables after various events (idling, reset, activity etc).

When constructing the table of register definitions, also include the
flags for which registers are valid so that information is computed
centrally and available to all callers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Brian Welty <brian.welty@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-10-chris@chris-wilson.co.uk

Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-2-jani.nikula@intel.com

Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall. Move
irq_unintall() closer to the layer it belongs.

The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-1-jani.nikula@intel.com

spinlock_t is one case where the typedef is to be preferred over struct
spinlock.

Fixes: 42fb60de ("drm/i915/gem: Don't leak non-persistent requests on changing engines")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217184219.15325-1-jani.nikula@intel.com

As we have the total runtime known to us, show it when dumping the
engine state for debug.
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/20200218162150.1300405-2-chris@chris-wilson.co.uk

Always flush the tasklet if we have pending submissions in
wait_for_submit(), so that even if we see the HW has started before we
process its ack, when we return the execlists state is well defined.

Fixes: 06289949 ("drm/i915/selftests: Check for any sign of request starting in wait_for_submit()")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218211215.1336341-1-chris@chris-wilson.co.uk

Just missed setting err along an interruptible error path for the
intel_engine_pulse().
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/20200218162150.1300405-4-chris@chris-wilson.co.uk

We only want to wait until the request has been submitted at least once;
that is it is either in flight, or has been.

References: fcf7df7a ("drm/i915/selftests: Check for the error interrupt before we wait!")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218141305.1258394-1-chris@chris-wilson.co.uk

It's not clear whether this workaround is final yet, but the BSpec
indicates that userspace needs to set bit 9 of this register on demand:

   "To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer
   Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA"

Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2501Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
[mattrope: Tweaked comment while applying]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212191728.25227-1-rafael.antognolli@intel.com

The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().

Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().

No functional changes.

Generated using the following semantic patch:

@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)

@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214140910.23194-2-jani.nikula@intel.com

The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().

Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().

No functional changes.

Generated using the following semantic patch:

@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)

@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214140910.23194-1-jani.nikula@intel.com

The ringbuffer's vma is expected to be in the GGTT and that is now being
checked, so make sure the mocked ring declares it so.
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/20200215205927.4170144-1-chris@chris-wilson.co.uk

Without selftests enabled, I915_SELFTEST_ONLY becomes a dummy,
generating a bare '0'. This causes the compiler to complain about a
useless line, and while we could use I915_SELFTEST_DECLARE instead, it
is a bit messier. Move the selftest-only code to a helper and make that
conditional on having selftests enabled.
Reported-by: Nkbuild test robot <lkp@intel.com>
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/20200217095835.599827-1-chris@chris-wilson.co.uk

Prefer intel_uncore_* over I915_READ, I915_WRITE, and POSTING_READ.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212144058.5686-2-jani.nikula@intel.com

i915_drv.c is a fairly big file, and having very specific vlv/chv
suspend/resume code in it is a distraction. Split it out to a new
vlv_suspend.[ch] file.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212144058.5686-1-jani.nikula@intel.com

We've moved from bugzilla to gitlab.

Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212160434.6437-2-jani.nikula@intel.com

We've moved from bugzilla to gitlab.

Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212160434.6437-1-jani.nikula@intel.com

Since we use a HW readback or estimation of the CS timestamp frequency,
sometimes it may result in 0. Avoid the division-by-zero in computing
its reciprocal, the timestamp period.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216161746.500258-1-chris@chris-wilson.co.uk

GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
which will be useful for us in cases when we are not able to track context
busyness ourselves (like with GuC). Keep a copy of this in struct
intel_context from where it can be easily read even if the context is not
pinned.

v2:
 (Chris)
 * Do not store pphwsp address in intel_context.
 * Log CS wrap-around.
 * Simplify calculation by relying on integer wraparound.
v3:
 * Include total/avg in traces and error state for debugging
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.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/20200216133620.394962-1-chris@chris-wilson.co.uk

Currently when we load the driver we set distrust_bios_wm=true, which
will cause active_pipe_changes to get flagged even when we're not
toggling any pipes on/off. The reason being that we want to fully
redistribute the dbuf among the active pipes and ignore whatever
state the firmware left behind.

Unfortunately when the code flags active_pipe_changes it doesn't
set state->modeset to true, which means the hardware dbuf state
won't actually get updated. Hence the hardware and software
states go out of sync, which can result in planes trying to use a
disabled dbuf slice. Suprisingly that only seems to corrupt the
display rather than making the whole display engine keel over.

Let's fix this for now by flagging state->modeset whenever
distrust_bios_wm is set.

Eventually we'll likely want to rip out all of this mess and
introduce proper statye tracking for dbuf. But that requires
more work. Toss in a FIXME to that effect.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: ff2cd863 ("drm/i915: Correctly map DBUF slices to pipes")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200213140412.32697-4-stanislav.lisovskiy@intel.com

We lack full state readout of DSC config, which may lead to DSC enable
using a config that's all zeros, failing spectacularly. Force full
modeset and thus compute config at probe to get a sane state, until we
implement DSC state readout. Any fastset that did appear to work with
DSC at probe, worked by coincidence. [1] is an example of a change that
triggered the issue on TGL DSI DSC.

[1] http://patchwork.freedesktop.org/patch/msgid/20200212150102.7600-1-ville.syrjala@linux.intel.com

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: fbacb15e ("drm/i915/dsc: add basic hardware state readout support")
Acked-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200213140412.32697-3-stanislav.lisovskiy@intel.com

TGL BIOS seems to enable both DBuf slices ocasionally, depending
how many displays are connected, while i915 according to BSpec
was powering on S1 DBuf slice, until a modeset was done.

This was causing a brief flash during the boot as we were
disabling slice, previously used by BIOS with that.

To prevent this, now we are ensuring tht we are enabling
_at least_ one slice, but if there are more, let's not
power them off.

Fixes: ff2cd863 ("drm/i915: Correctly map DBUF slices to pipes")
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200213140412.32697-2-stanislav.lisovskiy@intel.com

Commit 1c9d2eb2 ("drm/i915: move intel_dp_set_m_n() to encoder for
DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
to intel_ddi_pre_enable_dp() but it missed add it to
intel_mst_pre_enable_dp() causing MST slaves to not work.

v2: Not setting intel_ddi_set_dp_msa() twice for MST master

Fixes: 1c9d2eb2 ("drm/i915: move intel_dp_set_m_n() to encoder for DDI platforms")
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211185008.30806-1-jose.souza@intel.com