Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Intended for upstream testing so that we can still exercise the LMEM
plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon
device. This works by allocating an intel_memory_region for a reserved
portion of system memory, which we treat like LMEM. For the LMEMBAR we
steal the aperture and 1:1 it map to the stolen region.

To enable simply set the i915 modparam fake_lmem_start= on the kernel
cmdline with the start of reserved region(see memmap=). The size of the
region we can use is determined by the size of the mappable aperture, so
the size of reserved region should be >= mappable_end. For now we only
enable for the selftests. Depends on CONFIG_DRM_I915_UNSTABLE being
enabled.

eg. memmap=2G$16G i915.fake_lmem_start=0x400000000

v2: make fake_lmem_start an i915 modparam
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/20191030173320.8850-1-matthew.auld@intel.com

Non-TC ports always have tc_mode == TC_PORT_TBT_ALT so it was
switching aux to TBT mode for all combo-phy ports, happily this did
not caused any issue but is better follow BSpec.
Also this is reserved bit before ICL.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Fixes: e9b7e142 ("drm/i915: Sanitize the terminology used for TypeC port modes")
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029011014.286885-1-jose.souza@intel.com

Recent GuC doesn't require the shared area. We still have one user in
i915 (engine reset via guc) because we haven't updated the command to
match the current guc submission flow [1]. Since the flow in guc is
about to change again, just disable the command for now and add a note
that we'll implement it as part of the new flow.

[1] https://patchwork.freedesktop.org/patch/295038/Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Fernando Pacheco <fernando.pacheco@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Brost <matthew.brost@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031013040.25803-2-daniele.ceraolospurio@intel.com

Recent GuC binaries (including all the ones we're currently using)
don't require this shared area anymore, having moved the relevant
entries into the stage pool instead. i915 itself doesn't write
anything into it either, so we can safely drop it.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Brost <matthew.brost@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031013040.25803-1-daniele.ceraolospurio@intel.com

In order to keep the assert_bind_count() valid, we need to hold the vma
page reference until after we drop the bind count. However, we must also
keep the drm_mm_remove_node() as the last action of i915_vma_unbind() so
that it serialises with the unlocked check inside i915_vma_destroy(). So
we need to split up i915_vma_remove() so that we order the detach, drop
pages and remove as required during unbind.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112067Signed-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/20191030192159.18404-1-chris@chris-wilson.co.uk

If the idle_pulse fails to flush the i915_active, dump the tree to see
if that has any clues.
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/20191031101116.19894-1-chris@chris-wilson.co.uk

When checking the heartbeat pulse, we expect it to have been sent by the
time we have slept. We can verify this by checking the engine serial
number to see if that matches the predicted pulse serial. It will always
be true if, and only if, the pulse was sent by itself (as designed by
the test).
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/20191031094259.23028-1-chris@chris-wilson.co.uk

To avoid accidentally breaking things in the future add a
comment explaining why we misconfigure the pipe_mask.

Also toss in a TODO for investigating a single encoder
approach as opposed to the encoder-per-pipe approach.

v2: Drop a bogus TODO comment
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-6-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Just set pipe_mask=~0 for the non-special cases where any pipe
will do. intel_encoder_possible_crtcs() will anyway drop out
anything that doesn't exist.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-5-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

There are no longer any pipe<->DSI port limitations on icl+.
Populate the pipe_mask accordingly.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-4-ville.syrjala@linux.intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

Rename the encoder->crtc_mask to encoder->pipe_mask to better
reflect what it actually contains.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-3-ville.syrjala@linux.intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

We don't need to special case PCH vs. gen4 when setting up the LVDS
crtc_mask. Just claim pipes A|B|C work and
intel_encoder_possible_crtcs() will drop out any crtc that doesn't
exist.

v2: Put the special case first to match what most other encoders do
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-2-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

GuC 35.2.0 and HuC 7.0.3 are the first production releases for TGL.
GuC 35.2 for Gen12 is interface-compatible with 33.0 on older Gens,
because the differences are related to additional blocks/commands in
the interface to support new Gen12 features. These parts of the
interface will be added when the relevant features are enabled.

v2: fix typos (Michal)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026003507.21769-1-daniele.ceraolospurio@intel.com

The core no longer uses drm_crtc_state::mode with atomic drivers,
so let's stop frobbing it in the driver. For the user mode readout
we'll just use an on stack mode.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029145526.10308-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We always pass mode==NULL to intel_get_load_detect_pipe(). Remove
the pointless function argument.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029132323.18113-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

For the HPD interrupt functionality the HW depends on power wells in the
display core domain to be on. Accordingly when enabling these power
wells the HPD polling logic will force an HPD detection cycle to account
for hotplug events that may have happened when such a power well was
off.

Thus a detect cycle started by polling could start a new detect cycle if
a power well in the display core domain gets enabled during detect and
stays enabled after detect completes. That in turn can lead to a
detection cycle runaway.

To prevent re-triggering a poll-detect cycle make sure we drop all power
references we acquired during detect synchronously by the end of detect.
This will let the poll-detect logic continue with polling (matching the
off state of the corresponding power wells) instead of scheduling a new
detection cycle.

Fixes: 6cfe7ec0 ("drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112125Reported-and-tested-by: NVal Kulkov <val.kulkov@gmail.com>
Reported-and-tested-by: Nwangqr <wqr.prg@gmail.com>
Cc: Val Kulkov <val.kulkov@gmail.com>
Cc: wangqr <wqr.prg@gmail.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/20191028181517.22602-1-imre.deak@intel.com

During startup, we may find ourselves in an interesting position where
we haven't fully enabled RPS before the display starts trying to use it.
This may lead to an imbalance in our "interactive" counter:

<3>[    4.813326] intel_rps_mark_interactive:652 GEM_BUG_ON(!rps->power.interactive)
<4>[    4.813396] ------------[ cut here ]------------
<2>[    4.813398] kernel BUG at drivers/gpu/drm/i915/gt/intel_rps.c:652!
<4>[    4.813430] invalid opcode: 0000 [#1] PREEMPT SMP PTI
<4>[    4.813438] CPU: 1 PID: 18 Comm: kworker/1:0H Not tainted 5.4.0-rc5-CI-CI_DRM_7209+ #1
<4>[    4.813447] Hardware name:  /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4>[    4.813525] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
<4>[    4.813589] RIP: 0010:intel_rps_mark_interactive+0xb3/0xc0 [i915]
<4>[    4.813597] Code: bc 3f de e0 48 8b 35 84 2e 24 00 49 c7 c0 f3 d4 4e a0 b9 8c 02 00 00 48 c7 c2 80 9c 48 a0 48 c7 c7 3e 73 34 a0 e8 8d 3b e5 e0 <0f> 0b 90 66 2e 0f 1f 84 00 00 00 00 00 80 bf c0 00 00 00 00 74 32
<4>[    4.813616] RSP: 0018:ffffc900000efe00 EFLAGS: 00010286
<4>[    4.813623] RAX: 000000000000000e RBX: ffff8882583cc7f0 RCX: 0000000000000000
<4>[    4.813631] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888275969c00
<4>[    4.813639] RBP: 0000000000000000 R08: 0000000000000008 R09: ffff888275ace000
<4>[    4.813646] R10: ffffc900000efe00 R11: ffff888275969c00 R12: ffff8882583cc8d8
<4>[    4.813654] R13: ffff888276abce00 R14: 0000000000000000 R15: ffff88825e878860
<4>[    4.813662] FS:  0000000000000000(0000) GS:ffff888276a80000(0000) knlGS:0000000000000000
<4>[    4.813672] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[    4.813678] CR2: 00007f051d5ca0a8 CR3: 0000000262f48001 CR4: 00000000003606e0
<4>[    4.813686] Call Trace:
<4>[    4.813755]  intel_cleanup_plane_fb+0x4e/0x60 [i915]
<4>[    4.813764]  drm_atomic_helper_cleanup_planes+0x4d/0x70
<4>[    4.813833]  intel_atomic_cleanup_work+0x15/0x80 [i915]
<4>[    4.813842]  process_one_work+0x26a/0x620
<4>[    4.813850]  worker_thread+0x37/0x380
<4>[    4.813857]  ? process_one_work+0x620/0x620
<4>[    4.813864]  kthread+0x119/0x130
<4>[    4.813870]  ? kthread_park+0x80/0x80
<4>[    4.813878]  ret_from_fork+0x3a/0x50
<4>[    4.813887] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btusb btrtl btbcm btintel snd_hda_intel snd_intel_nhlt snd_hda_codec bluetooth snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm e1000e ecdh_generic ecc ptp pps_core mei_me mei prime_numbers
<4>[    4.813934] ---[ end trace c13289af88174ffc ]---

The solution employed is to not worry about RPS state and keep the tally
of the interactive counter separate. When we do enable RPS, we will then
take the display activity into account.

Fixes: 3e7abf81 ("drm/i915: Extract GT render power state management")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Acked-by: NAndi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191030103827.2413-1-chris@chris-wilson.co.uk

This has been asked from us already. Prepare for the next
time.
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.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/20191029163841.5224-2-mika.kuoppala@linux.intel.com

On debugging media workload hangs, sfc instdone
might prove useful in future. Be prepared.
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.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/20191029163841.5224-1-mika.kuoppala@linux.intel.com

This is the minimum change to support 1 (and only 1) DP-MST monitor
connected on Tiger Lake. This change was isolated from previous patch
from José. In order to support more streams we will need to create a
master-slave relation on the transcoders and that is not currently
working yet.

v2: remove unused macro and use REG_FIELD_PREP() (Ville)
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029035049.5907-1-lucas.demarchi@intel.com

Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.

The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.

Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.

The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.

We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.

Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NJason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk

We're seeing some failures where an aux transaction still shows as
'busy' well after the timeout limit that the hardware is supposed to
enforce.  Improve the error message so that we can see exactly which aux
channel this error happened on and what the status bits were during this
case that isn't supposed to happen.

v2:
 - Make timeout a const variable so that the timeout & message will
   match if we decide to change it in the future.  (Lucas)
 - Don't bother testing intel_dp->aux.name for NULL.  (Lucas)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029173102.9451-1-matthew.d.roper@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

DSC could be fused off, so not all GEN10+ platforms will support it.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-5-jose.souza@intel.com

Check if DMC is fused off and handle it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-4-jose.souza@intel.com

Check if FBC is fused off and handle it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-3-jose.souza@intel.com

HDCP could be fused off, so not all GEN9+ platforms will support it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-2-jose.souza@intel.com

The next patches are going to touch this registers so here already
fixing it for older registers and make it consistent with most of
the other registers in this file.

Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-1-jose.souza@intel.com

Gen12 only support a single report format :
I915_OA_FORMAT_A32u40_A4u32_B8_C8
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 00a7f0d7 ("drm/i915/tgl: Add perf support on TGL")
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/20191029142826.20014-1-lionel.g.landwerlin@intel.com

Our TGL CI platforms are running into cases where aux transactions have
failed to complete or declare a timeout well after the timeout limit
that the hardware is supposed to enforce.  From the logs it appears that
these failures arise when aux transactions happen after we've entered
DC6:

  <7> [622.523650] [drm:skl_enable_dc6 [i915]] Enabling DC6
  <7> [622.523685] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
  ...
  <3> [622.535753] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.547745] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.559746] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.571744] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.583743] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout!
  <3> [622.583780] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp_aux_ch not done status 0xad400bff
  <7> [622.863725] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110

On TGL AUX B & C are in PG1 (managed by the DMC firmware) rather
than PG3 as they were on ICL, so allowing DC6 means the DMC firmware
might shut off the power wells behind our backs when we're trying to use
them.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025230623.27829-6-matthew.d.roper@intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

We reference DP AUX registers via the DP_AUX_CH_CTL() and
DP_AUX_CH_DATA() macros that calculate all the register offsets for us
automatically; there's no need to explicitly define every offset in
i915_reg.h if they're never going to be used by the driver code.

v2: Apparently GVT was directly using these raw definitions in a couple
    places.  Switch GVT code over to using our preferred macros.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>  #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191026051226.30807-1-matthew.d.roper@intel.com

Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to userspace semaphores. However, not all workloads necessarily benefit
from timeslicing and in the extreme some sysadmin may want to disable or
reduce the timeslicing granularity.

The timeslicing mechanism can be compiled out^W^W disabled (but should
DCE!) with

	./scripts/config --set-val DRM_I915_TIMESLICE_DURATION 0
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029091632.26281-1-chris@chris-wilson.co.uk

Commit f2db53f1 ("drm/i915: Replace "_load" with "_probe"
consequently") deliberately left the name of the module parameter
unchanged as that would require a corresponding change on IGT size.
Now as the IGT side change has been submitted, complete the switch to
the "probe" nomenclature.
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20191029102036.6326-3-janusz.krzysztofik@linux.intel.com

Commit 50d84418 ("drm/i915: Add i915 to i915_inject_probe_failure")
introduced new functions unfortunately named incompatibly with rules
established by commit f2db53f1 ("drm/i915: Replace "_load" with
"_probe" consequently").  Fix it for consistency.
Suggested-by: NMichał Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20191029102036.6326-2-janusz.krzysztofik@linux.intel.com

The change from the uapi coordinates to the internal coordinates
broke the cursor on i845/i865 due to src and dst getting swapped.
Fix it.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 3a612765 ("drm/i915: Remove cursor use of properties for coordinates")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

The design of the OA unit has been split into several units. We now
have a global unit (OAG) and a render specific unit (OAR). This leads
to some changes on how we program things. Some details :

OAR:
  - has its own set of counter registers, they are per-context
    saved/restored
  - counters are not written to the circular OA buffer
  - a snapshot of the counters can be acquired with
    MI_RECORD_PERF_COUNT, or a single counter can be read with
    MI_STORE_REGISTER_MEM.

OAG:
  - has global counters that increment across context switches
  - counters are written into the circular OA buffer (if requested)

v2: Fix checkpatch warnings on code style (Lucas)
v3: (Umesh)
  - Update register from which tail, status and head are read
  - Update logic to sample context reports
  - Update whitelist mux and b counter regs
v4: Fix a bug when updating context image for new contexts (Umesh)
v5: Squash patch enabling save/restore of counters into context image

    We want this so we can preempt performance queries and keep the
    system responsive even when long running queries are ongoing. We
    avoid doing it for all contexts.

    - use LRI to modify context control (Chris)
    - use MASKED_FIELD to program just the masked bits (Chris)
    - disable save/restore of counters on cleanup (Chris)
v6: Do not use implicit parameters (Chris)

BSpec: 28727, 30021
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NChris Wilson <chris.p.wilson@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025193746.47155-2-umesh.nerlige.ramappa@intel.com

Add helper macros for range and equality comparisons and use them to
check with whitelisted registers in oa configurations.
Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025193746.47155-1-umesh.nerlige.ramappa@intel.com

We may be missing support for the mappable aperture on some platforms.
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20191029095856.25431-7-matthew.auld@intel.com

Since we have no way access it from the CPU. For such cases just
fallback to internal objects.
Signed-off-by: NMatthew Auld <matthew.auld@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/20191029095856.25431-6-matthew.auld@intel.com

HWS placement restrictions can't just rely on HAS_LLC flag.
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-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/20191029095856.25431-5-matthew.auld@intel.com