review.tizen.org Git - platform/kernel/linux-starfive.git/log

drm/i915/bios: pass devdata to parse_ddi_port

Allow accessing the parent structure later on. Drop const for allowing
future modification as well.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3318b09aaccbbe141e233ca510d581b421259a2a.1575974743.git.jani.nikula@intel.com

drm/i915/tgl: Program BW_BUDDY registers during display init

Gen12 can improve bandwidth efficiency by pairing up memory requests
with similar addresses.  We need to program the BW_BUDDY1 and BW_BUDDY2
registers according to the memory configuration during display
initialization to take advantage of this capability.

The magic numbers we program here feel like something that could
definitely change on future platforms, so let's use a table-based
programming scheme to make this easy to extend in the future.

v2:
- Add separate table for Wa_1409767108.  (Stan)
- Reorder structure reduce size by a word.  Page mask can still be up
   to 28 bits (even though current values are small) so we should keep
   it as a u32, but just using a u8 for DRAM type instead of the actual
   enum type saves space.  (Lucas, Ville)
- Rename function to tgl_bw_buddy_init() to be more precise about what
   it does.  (Lucas)

Bspec: 49189
Bspec: 49218
Bspec: 52890
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205224848.76712-1-matthew.d.roper@intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915/selftests: fix uninitialized variable sum when summing up values

Currently the variable sum is not uninitialized and hence will cause an
incorrect result in the summation values. Fix this by initializing
sum to the first item in the summation.

Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 3c7a44bbbfa7 ("drm/i915/selftests: Perform some basic cycle counting of MI ops")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210143205.338308-1-colin.king@canonical.com

drm/i915/gt: Detect if we miss WaIdleLiteRestore

In order to avoid confusing the HW, we must never submit an empty ring
during lite-restore, that is we should always advance the RING_TAIL
before submitting to stay ahead of the RING_HEAD.

Normally this is prevented by keeping a couple of spare NOPs in the
request->wa_tail so that on resubmission we can advance the tail. This
relies on the request only being resubmitted once, which is the normal
condition as it is seen once for ELSP[1] and then later in ELSP[0]. On
preemption, the requests are unwound and the tail reset back to the
normal end point (as we know the request is incomplete and therefore its
RING_HEAD is even earlier).

However, if this w/a should fail we would try and resubmit the request
with the RING_TAIL already set to the location of this request's wa_tail
potentially causing a GPU hang. We can spot when we do try and
incorrectly resubmit without advancing the RING_TAIL and spare any
embarrassment by forcing the context restore.

In the case of preempt-to-busy, we leave the requests running on the HW
while we unwind. As the ring is still live, we cannot rewind our
rq->tail without forcing a reload so leave it set to rq->wa_tail and
only force a reload if we resubmit after a lite-restore. (Normally, the
forced reload will be a part of the preemption event.)

Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/673
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@kernel.vger.org
Link: https://patchwork.freedesktop.org/patch/msgid/20191209023215.3519970-1-chris@chris-wilson.co.uk

drm/i915/guc: kill the GuC client

We now only use 1 client without any plan to add more. The client is
also only holding information about the WQ and the process desc, so we
can just move those in the intel_guc structure and always use stage_id
0.

v2: fix comment (John)
v3: fix the comment for real, fix kerneldoc

Signed-off-by: Daniele 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>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-4-daniele.ceraolospurio@intel.com

drm/i915/guc: kill doorbell code and selftests

Instead of relying on the workqueue, the upcoming reworked GuC
submission flow will offer the host driver indipendent control over
the execution status of each context submitted to GuC. As part of this,
the doorbell usage model has been reworked, with each doorbell being
paired to a single lrc and a doorbell ring representing new work
available for that specific context. This mechanism, however, limits
the number of contexts that can be registered with GuC to the number of
doorbells, which is an undesired limitation. To avoid this limitation,
we requested the GuC team to also provide a H2G that will allow the host
to notify the GuC of work available for a specified lrc, so we can use
that mechanism instead of relying on the doorbells. We can therefore drop
the doorbell code we currently have, also given the fact that in the
unlikely case we'd want to switch back to using doorbells we'd have to
heavily rework it.
The workqueue will still have a use in the new interface to pass special
commands, so that code has been retained for now.

With the doorbells gone and the GuC client becoming even simpler, the
existing GuC selftests don't give us any meaningful coverage so we can
remove them as well. Some selftests might come with the new code, but
they will look different from what we have now so if doesn't seem worth
it to keep the file around in the meantime.

v2: fix comments and commit message (John)

Signed-off-by: Daniele 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>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-3-daniele.ceraolospurio@intel.com

drm/i915/guc: add a helper to allocate and map guc vma

We already have a couple of use-cases in the code and another one will
come in one of the later patches in the series.

v2: use the new function for the CT object as well

Signed-off-by: Daniele 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>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-2-daniele.ceraolospurio@intel.com

drm/i915/guc: Drop leftover preemption code

Remove unused enums and ctx_save_restore_disabled() function, leftover
from the legacy preemption removal.

Signed-off-by: Daniele 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>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-1-daniele.ceraolospurio@intel.com

drm/i915/hdcp: Nuke intel_hdcp_transcoder_config()

intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.

Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 39e2df090c3c ("drm/i915/hdcp: update current transcoder into intel_hdcp")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915/fbc: Reallocate cfb if we need more of it

The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.

The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.

Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-15-ville.syrjala@linux.intel.com
Tested-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Enable fbc by default on glk+ once again

Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.

Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-14-ville.syrjala@linux.intel.com
Tested-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Wait for vblank after FBC disable on glk+

On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.

We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.

v2: Don't do the vblank wait if we never activated FBC in hw

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128150338.12490-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Start using flip nuke

The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.

We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-12-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Nuke fbc.enabled

fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-11-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/

Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-10-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Make fence_id optional for i965gm

i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.

In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-9-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Store fence_id directly in fbc cache/params

Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-8-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Track plane visibility

Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-7-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Precompute gen9 cfb stride w/a

Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.

The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.

v2: Don't explode when crtc_state->enable_fbc lies to us

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-6-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB

We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.

Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-5-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Relocate intel_crtc_active()

Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-4-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.

v2: Nuke no_fbc_on_multiple_pipes() too

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-3-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/fbc: Disable fbc by default on all glk+

We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.

Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915/perf: Configure OAR for specific context

Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.

v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power state is already
applied by the caller.

v3: (Lionel)
- Move register initialization into the array
- Assume a valid oa_config in enable_metric_set

Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-2-umesh.nerlige.ramappa@intel.com

drm/i915/perf: Allow non-privileged access when OA buffer is not sampled

SAMPLE_OA_REPORT enables sampling of OA reports from the OA buffer.
Since reports from OA buffer had system wide visibility, collecting
samples from the OA buffer was a privileged operation on previous
platforms. Prior to TGL, it was also necessary to sample the OA buffer
to normalize reports from MI REPORT PERF COUNT.

TGL has a dedicated OAR unit to sample perf reports for a specific
render context. This removes the necessity to sample OA buffer.

- If not sampling the OA buffer, allow non-privileged access. An earlier
patch allows the non-privilege access:
https://patchwork.freedesktop.org/patch/337716/?series=68582&rev=1
- Clear up the path for non-privileged access in this patch

Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206194339.31356-1-umesh.nerlige.ramappa@intel.com

drm/i915: Change i915_vma_unbind() to report -EAGAIN on activity

If someone else acquires the i915_vma before we complete our wait and
unbind it, we currently error out with -EBUSY. Use -EAGAIN instead so
that if necessary the caller is prepared to try again.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/683
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191208161252.3015727-2-chris@chris-wilson.co.uk

drm/i915/gem: Avoid rcu_barrier() from shrinker paths

As i915_gem_object_unbind() waits on an rcu_barrier() to flush vm
releases (and destruction of their bound vma), we have to be careful not
to invoke that barrier from beneath the shrinker:

<4> [430.222671] WARNING: possible circular locking dependency detected
<4> [430.222673] 5.4.0-rc8-CI-CI_DRM_7508+ #1 Tainted: G     U
<4> [430.222675] ------------------------------------------------------
<4> [430.222677] gem_pwrite/2317 is trying to acquire lock:
<4> [430.222678] ffffffff82248218 (rcu_state.barrier_mutex){+.+.}, at: rcu_barrier+0x23/0x190
<4> [430.222685]
but task is already holding lock:
<4> [430.222687] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [430.222691]
which lock already depends on the new lock.

<4> [430.222693]
the existing dependency chain (in reverse order) is:
<4> [430.222695]
-> #2 (fs_reclaim){+.+.}:
<4> [430.222698]        fs_reclaim_acquire.part.117+0x24/0x30
<4> [430.222702]        kmem_cache_alloc_trace+0x2a/0x2c0
<4> [430.222705]        intel_cpuc_prepare+0x37/0x1a0
<4> [430.222709]        cpuhp_invoke_callback+0x9b/0x9d0
<4> [430.222712]        _cpu_up+0xa2/0x140
<4> [430.222714]        do_cpu_up+0x61/0xa0
<4> [430.222718]        smp_init+0x57/0x96
<4> [430.222722]        kernel_init_freeable+0xac/0x1c7
<4> [430.222725]        kernel_init+0x5/0x100
<4> [430.222728]        ret_from_fork+0x24/0x50
<4> [430.222729]
-> #1 (cpu_hotplug_lock.rw_sem){++++}:
<4> [430.222733]        cpus_read_lock+0x34/0xd0
<4> [430.222734]        rcu_barrier+0xaa/0x190
<4> [430.222736]        kernel_init+0x21/0x100
<4> [430.222737]        ret_from_fork+0x24/0x50
<4> [430.222739]
-> #0 (rcu_state.barrier_mutex){+.+.}:
<4> [430.222742]        __lock_acquire+0x1328/0x15d0
<4> [430.222743]        lock_acquire+0xa7/0x1c0
<4> [430.222746]        __mutex_lock+0x9a/0x9d0
<4> [430.222747]        rcu_barrier+0x23/0x190
<4> [430.222850]        i915_gem_object_unbind+0x264/0x3d0 [i915]
<4> [430.222882]        i915_gem_shrink+0x297/0x5f0 [i915]
<4> [430.222912]        i915_gem_shrink_all+0x38/0x60 [i915]
<4> [430.222934]        i915_drop_caches_set+0x1f0/0x240 [i915]
<4> [430.222938]        simple_attr_write+0xb0/0xd0
<4> [430.222941]        full_proxy_write+0x51/0x80
<4> [430.222943]        vfs_write+0xb9/0x1d0
<4> [430.222944]        ksys_write+0x9f/0xe0
<4> [430.222946]        do_syscall_64+0x4f/0x210
<4> [430.222948]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [430.222950]
other info that might help us debug this:

<4> [430.222952] Chain exists of:
  rcu_state.barrier_mutex --> cpu_hotplug_lock.rw_sem --> fs_reclaim

<4> [430.222955]  Possible unsafe locking scenario:

<4> [430.222957]        CPU0                    CPU1
<4> [430.222958]        ----                    ----
<4> [430.222960]   lock(fs_reclaim);
<4> [430.222961]                                lock(cpu_hotplug_lock.rw_sem);
<4> [430.222963]                                lock(fs_reclaim);
<4> [430.222964]   lock(rcu_state.barrier_mutex);
<4> [430.222966]
*** DEADLOCK ***

<4> [430.222968] 3 locks held by gem_pwrite/2317:
<4> [430.222969]  #0: ffff88849e2d9408 (sb_writers#14){.+.+}, at: vfs_write+0x1a4/0x1d0
<4> [430.222973]  #1: ffff888496976db0 (&attr->mutex){+.+.}, at: simple_attr_write+0x36/0xd0
<4> [430.222976]  #2: ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [430.222980]
stack backtrace:
<4> [430.222982] CPU: 1 PID: 2317 Comm: gem_pwrite Tainted: G     U            5.4.0-rc8-CI-CI_DRM_7508+ #1
<4> [430.222985] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2321.A08.1909162051 09/16/2019
<4> [430.222989] Call Trace:
<4> [430.222992]  dump_stack+0x71/0x9b
<4> [430.222995]  check_noncircular+0x19b/0x1c0
<4> [430.222998]  ? __lock_acquire+0x1328/0x15d0
<4> [430.222999]  __lock_acquire+0x1328/0x15d0
<4> [430.223001]  ? mark_held_locks+0x49/0x70
<4> [430.223003]  lock_acquire+0xa7/0x1c0
<4> [430.223005]  ? rcu_barrier+0x23/0x190
<4> [430.223008]  __mutex_lock+0x9a/0x9d0
<4> [430.223009]  ? rcu_barrier+0x23/0x190
<4> [430.223011]  ? rcu_barrier+0x23/0x190
<4> [430.223013]  ? find_held_lock+0x2d/0x90
<4> [430.223045]  ? i915_gem_object_unbind+0x24a/0x3d0 [i915]
<4> [430.223048]  ? rcu_barrier+0x23/0x190
<4> [430.223049]  rcu_barrier+0x23/0x190
<4> [430.223081]  i915_gem_object_unbind+0x264/0x3d0 [i915]
<4> [430.223119]  i915_gem_shrink+0x297/0x5f0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/issues/743
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191208161252.3015727-1-chris@chris-wilson.co.uk

drm/i915: Flesh out device_info pretty printer

Include all the number fields for describing the GT, as well as the
current boolean flags, primarily for inclusion in error states.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191207182937.2583002-1-chris@chris-wilson.co.uk

drm/i915/gem: Comment on inability to check args.pad for MMAP_OFFSET

Since we didn't check and insist that args.pad must be zero for MMAP_GTT
historically, we cannot insert a check now as old userspace may be
feeding in garbage. As such the lack of check is enshrined into the ABI,
so add a comment to remind us we cannot add the check later.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191207222644.2830129-1-chris@chris-wilson.co.uk

drm/i915/gt: Turn vm off then on again for gen7 mm switch

"Have you tried switching it off and on again?"

Set the size of the mm to 0 to disable all PD cachelines, before
enabling the whole mm again. Let's see if that tricks the TLB into
reloading.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191208143648.2986669-1-chris@chris-wilson.co.uk

drm/i915/gtt: Account for preallocation in asserts

Our asserts allow for the PDEs to be allocated concurrently, but we did
not account for the aliasing-ppgtt to be preallocated on top.

Testcase: igt/gem_ppgtt #bsw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191207221453.2802627-1-chris@chris-wilson.co.uk

drm/i915: Avoid calling i915_gem_object_unbind holding object lock

In the extreme case, we may wish to wait on an rcu-barrier to reap stale
vm to purge the last of the object bindings. However, we are not allowed
to use rcu_barrier() beneath the dma_resv (i.e. object) lock and do not
take lightly the prospect of unlocking a mutex deep in the bowels of the
routine. i915_gem_object_unbind() itself does not need the object lock,
and it turns out the callers do not need to the unbind as part of a
locked sequence around set-cache-level, so rearrange the code to avoid
taking the object lock in the callers.

<4> [186.816311] ======================================================
<4> [186.816313] WARNING: possible circular locking dependency detected
<4> [186.816316] 5.4.0-rc8-CI-CI_DRM_7486+ #1 Tainted: G     U
<4> [186.816318] ------------------------------------------------------
<4> [186.816320] perf_pmu/1321 is trying to acquire lock:
<4> [186.816322] ffff88849487c4d8 (&mm->mmap_sem#2){++++}, at: __might_fault+0x39/0x90
<4> [186.816331]
but task is already holding lock:
<4> [186.816333] ffffe8ffffa05008 (&cpuctx_mutex){+.+.}, at: perf_event_ctx_lock_nested+0xa9/0x1b0
<4> [186.816339]
which lock already depends on the new lock.

<4> [186.816341]
the existing dependency chain (in reverse order) is:
<4> [186.816343]
-> #6 (&cpuctx_mutex){+.+.}:
<4> [186.816349]        __mutex_lock+0x9a/0x9d0
<4> [186.816352]        perf_event_init_cpu+0xa4/0x140
<4> [186.816357]        perf_event_init+0x19d/0x1cd
<4> [186.816362]        start_kernel+0x372/0x4f4
<4> [186.816365]        secondary_startup_64+0xa4/0xb0
<4> [186.816381]
-> #5 (pmus_lock){+.+.}:
<4> [186.816385]        __mutex_lock+0x9a/0x9d0
<4> [186.816387]        perf_event_init_cpu+0x6b/0x140
<4> [186.816404]        cpuhp_invoke_callback+0x9b/0x9d0
<4> [186.816406]        _cpu_up+0xa2/0x140
<4> [186.816409]        do_cpu_up+0x61/0xa0
<4> [186.816411]        smp_init+0x57/0x96
<4> [186.816413]        kernel_init_freeable+0xac/0x1c7
<4> [186.816416]        kernel_init+0x5/0x100
<4> [186.816419]        ret_from_fork+0x24/0x50
<4> [186.816421]
-> #4 (cpu_hotplug_lock.rw_sem){++++}:
<4> [186.816424]        cpus_read_lock+0x34/0xd0
<4> [186.816427]        rcu_barrier+0xaa/0x190
<4> [186.816429]        kernel_init+0x21/0x100
<4> [186.816431]        ret_from_fork+0x24/0x50
<4> [186.816433]
-> #3 (rcu_state.barrier_mutex){+.+.}:
<4> [186.816436]        __mutex_lock+0x9a/0x9d0
<4> [186.816438]        rcu_barrier+0x23/0x190
<4> [186.816502]        i915_gem_object_unbind+0x3a6/0x400 [i915]
<4> [186.816537]        i915_gem_object_set_cache_level+0x32/0x90 [i915]
<4> [186.816571]        i915_gem_object_pin_to_display_plane+0x5d/0x160 [i915]
<4> [186.816612]        intel_pin_and_fence_fb_obj+0x9e/0x200 [i915]
<4> [186.816679]        intel_plane_pin_fb+0x3f/0xd0 [i915]
<4> [186.816717]        intel_prepare_plane_fb+0x130/0x520 [i915]
<4> [186.816722]        drm_atomic_helper_prepare_planes+0x85/0x110
<4> [186.816761]        intel_atomic_commit+0xc6/0x350 [i915]
<4> [186.816764]        drm_atomic_helper_update_plane+0xed/0x110
<4> [186.816768]        setplane_internal+0x97/0x190
<4> [186.816770]        drm_mode_setplane+0xcd/0x190
<4> [186.816773]        drm_ioctl_kernel+0xa7/0xf0
<4> [186.816775]        drm_ioctl+0x2e1/0x390
<4> [186.816778]        do_vfs_ioctl+0xa0/0x6f0
<4> [186.816780]        ksys_ioctl+0x35/0x60
<4> [186.816782]        __x64_sys_ioctl+0x11/0x20
<4> [186.816785]        do_syscall_64+0x4f/0x210
<4> [186.816787]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [186.816789]
-> #2 (reservation_ww_class_mutex){+.+.}:
<4> [186.816793]        __ww_mutex_lock.constprop.15+0xc3/0x1090
<4> [186.816795]        ww_mutex_lock+0x39/0x70
<4> [186.816798]        dma_resv_lockdep+0x10e/0x1f7
<4> [186.816800]        do_one_initcall+0x58/0x2ff
<4> [186.816802]        kernel_init_freeable+0x137/0x1c7
<4> [186.816804]        kernel_init+0x5/0x100
<4> [186.816806]        ret_from_fork+0x24/0x50
<4> [186.816808]
-> #1 (reservation_ww_class_acquire){+.+.}:
<4> [186.816811]        dma_resv_lockdep+0xec/0x1f7
<4> [186.816813]        do_one_initcall+0x58/0x2ff
<4> [186.816815]        kernel_init_freeable+0x137/0x1c7
<4> [186.816817]        kernel_init+0x5/0x100
<4> [186.816819]        ret_from_fork+0x24/0x50
<4> [186.816820]
-> #0 (&mm->mmap_sem#2){++++}:
<4> [186.816824]        __lock_acquire+0x1328/0x15d0
<4> [186.816826]        lock_acquire+0xa7/0x1c0
<4> [186.816828]        __might_fault+0x63/0x90
<4> [186.816831]        _copy_to_user+0x1e/0x80
<4> [186.816834]        perf_read+0x200/0x2b0
<4> [186.816836]        vfs_read+0x96/0x160
<4> [186.816838]        ksys_read+0x9f/0xe0
<4> [186.816839]        do_syscall_64+0x4f/0x210
<4> [186.816841]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [186.816843]
other info that might help us debug this:

<4> [186.816846] Chain exists of:
  &mm->mmap_sem#2 --> pmus_lock --> &cpuctx_mutex

<4> [186.816849]  Possible unsafe locking scenario:

<4> [186.816851]        CPU0                    CPU1
<4> [186.816853]        ----                    ----
<4> [186.816854]   lock(&cpuctx_mutex);
<4> [186.816856]                                lock(pmus_lock);
<4> [186.816858]                                lock(&cpuctx_mutex);
<4> [186.816860]   lock(&mm->mmap_sem#2);
<4> [186.816861]
*** DEADLOCK ***

Closes: https://gitlab.freedesktop.org/drm/intel/issues/728
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-5-chris@chris-wilson.co.uk

drm/i915/guc: Update uncore access path in flush_ggtt_writes

The preferred way to access the uncore is through the GT structure.
Update the GuC function, flush_ggtt_writes, to use this path.

Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191207010033.24667-1-John.C.Harrison@Intel.com

drm/i915/gem: Pin gen6_ppgtt prior to constructing the request

All pinning must be done prior to i915_request_create, to avoid
timeline->mutex inversions.

Here we slightly abuse the context_barrier_task stages to utilise the
'skip' decision as an opportunity to acquire the pin on the new ppgtt.
Consider it s/skip/prepare/. At the moment, we only have on user of
context_barrier_task, so it might be worth breaking it down for the
specific task of set-vm and refactor it later if we find a second
purpose.

<4> [402.377487] WARNING: possible circular locking dependency detected
<4> [402.377493] 5.4.0-rc8-CI-CI_DRM_7491+ #1 Tainted: G     U
<4> [402.377497] ------------------------------------------------------
<4> [402.377502] gem_exec_parall/2506 is trying to acquire lock:
<4> [402.377507] ffff888403cdac70 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [402.377593]
but task is already holding lock:
<4> [402.377597] ffff88835efad550 (&ppgtt->pin_mutex){+.+.}, at: gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377660]
which lock already depends on the new lock.

<4> [402.377664]
the existing dependency chain (in reverse order) is:
<4> [402.377668]
-> #1 (&ppgtt->pin_mutex){+.+.}:
<4> [402.377674]        __mutex_lock+0x9a/0x9d0
<4> [402.377713]        gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377756]        emit_ppgtt_update+0x1dc/0x370 [i915]
<4> [402.377801]        context_barrier_task+0x176/0x310 [i915]
<4> [402.377844]        ctx_setparam+0x400/0xb10 [i915]
<4> [402.377886]        i915_gem_context_setparam_ioctl+0xc8/0x160 [i915]
<4> [402.377891]        drm_ioctl_kernel+0xa7/0xf0
<4> [402.377895]        drm_ioctl+0x2e1/0x390
<4> [402.377899]        do_vfs_ioctl+0xa0/0x6f0
<4> [402.377903]        ksys_ioctl+0x35/0x60
<4> [402.377906]        __x64_sys_ioctl+0x11/0x20
<4> [402.377910]        do_syscall_64+0x4f/0x210
<4> [402.377914]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.377917]
-> #0 (&kernel#2){+.+.}:
<4> [402.377923]        __lock_acquire+0x1328/0x15d0
<4> [402.377926]        lock_acquire+0xa7/0x1c0
<4> [402.377930]        __mutex_lock+0x9a/0x9d0
<4> [402.377977]        i915_request_create+0x16/0x1c0 [i915]
<4> [402.378013]        intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [402.378062]        i915_ggtt_pin+0x7d/0x130 [i915]
<4> [402.378108]        gen6_ppgtt_pin+0x9c/0x110 [i915]
<4> [402.378148]        ring_context_pin+0x2e/0xc0 [i915]
<4> [402.378183]        __intel_context_do_pin+0x6b/0x190 [i915]
<4> [402.378226]        i915_gem_do_execbuffer+0x180c/0x26b0 [i915]
<4> [402.378268]        i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [402.378272]        drm_ioctl_kernel+0xa7/0xf0
<4> [402.378275]        drm_ioctl+0x2e1/0x390
<4> [402.378279]        do_vfs_ioctl+0xa0/0x6f0
<4> [402.378282]        ksys_ioctl+0x35/0x60
<4> [402.378286]        __x64_sys_ioctl+0x11/0x20
<4> [402.378289]        do_syscall_64+0x4f/0x210
<4> [402.378292]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.378295]
other info that might help us debug this:

<4> [402.378299]  Possible unsafe locking scenario:

<4> [402.378302]        CPU0                    CPU1
<4> [402.378305]        ----                    ----
<4> [402.378307]   lock(&ppgtt->pin_mutex);
<4> [402.378310]                                lock(&kernel#2);
<4> [402.378314]                                lock(&ppgtt->pin_mutex);
<4> [402.378317]   lock(&kernel#2);
<4> [402.378320]

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-4-chris@chris-wilson.co.uk

drm/i915/gt: Replace I915_WRITE with its uncore counterpart

Get rid of the last remaining I915_WRITEs and replace them with
intel_uncore_write().

Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206212417.20178-1-andi@etezian.org

drm/i915/display: Refactor intel_commit_modeset_disables()

Commit 9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
reverted the order that pipes gets disabled because of TGL
master/slave relationship between transcoders in MST mode.

But as stated in a comment in skl_commit_modeset_enables() the
enabling order is not always crescent, possibly causing previously
selected slave transcoder being enabled before master so another
approach will be needed to select a transcoder to master in MST mode.
It will be similar to the approach taken in port sync.

But instead of implement something like
intel_trans_port_sync_modeset_disables() to MST lets simply it and
iterate over all pipes 2 times, the first one disabling any slave and
then disabling everything else.
The MST bits will be added in another patch.

v2:
Not using crtc->active as it is deprecated

v3:
Removing is_trans_port_sync_mode() check, just check for
is_trans_port_sync_master() is enough

v4:
Adding and using is_trans_port_sync_slave(), otherwise non-port sync
pipes will be disabled in the first loop, what is not wrong but is
not what patch description promises

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-3-jose.souza@intel.com

drm/i915/display/tgl: Fix the order of the step to turn transcoder clock off

For TGL the step to turn off the transcoder clock was moved to after
the complete shutdown of DDI. Only the MST slave transcoders should
disable the clock before that.

v2:
- Adding last_mst_stream to intel_mst_post_disable_dp, make code more
easy to read and is similar to first_mst_stream in
intel_mst_pre_enable_dp()(Ville's idea)
- Calling intel_ddi_disable_pipe_clock() for GEN12+ right
intel_disable_ddi_buf() as stated in BSpec(Ville)

BSpec: 49190
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-2-jose.souza@intel.com

drm/i915/display: Do not check for the ddb allocations of turned off pipes

It should not care about DDB allocations of pipes going through
a fullmodeset, as at this point those pipes are disabled.
The comment in the code also points to that but that was not what
was being executed.

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

drm/i915: Add new EHL/JSL PCI ids

Adding the recently added EHL/JSL PCI ids.

BSpec: 29153
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203211308.109703-1-jose.souza@intel.com

drm/i915: Propagate errors on awaiting already signaled dma-fences

If we see an already signaled dma-fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-3-chris@chris-wilson.co.uk

drm/i915: Propagate errors on awaiting already signaled fences

If we see an already signaled fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-2-chris@chris-wilson.co.uk

drm/i915: Check for error before calling cmpxchg()

Only do the locked compare of the existing fence->error if we actually
need to set an error. As we tend to call i915_sw_fence_set_error_once()
unconditionally, it saves on typing to put the common has-error check
into the inline.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-1-chris@chris-wilson.co.uk

drm/i915/pmu: Report frequency as zero while GPU is sleeping

We used to report the minimum possible frequency as both requested and
active while GPU was in sleep state. This was a consequence of sampling
the value from the "current frequency" field in our software tracking.

This was strictly speaking wrong, but given that until recently the
current frequency in sleeping state used to be equal to minimum, it did
not stand out sufficiently to be noticed as such.

After some recent changes have made the current frequency be reported
as last active before GPU went to sleep, meaning both requested and active
frequencies could end up being reported at their maximum values for the
duration of the GPU idle state, it became much more obvious that this does
not make sense.

To fix this we will now sample the frequency counters only when the GPU is
awake. As a consequence reported frequencies could be reported as below
the GPU reported minimum but that should be much less confusing that the
current situation.

v2:
* Split out early exit conditions for readability. (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/675
Link: https://patchwork.freedesktop.org/patch/msgid/20191129105436.20100-1-tvrtko.ursulin@linux.intel.com

drm/i915/gem: Flush the pwrite through the chipset before signaling

Before we signal the fence to indicate completion, ensure the pwrite
through the indirect GGTT is coherent (as best as we know) in memory.
Any listeners to the fence may start immediately and sample from the
backing store prior to the writes being posted, thus seeing stale data.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-1-chris@chris-wilson.co.uk

drm/i915/gt: Acquire a GT wakeref for the breadcrumb interrupt

Take a wakeref on the intel_gt specifically for the enabled breadcrumb
interrupt so that we can safely process the mmio. If the intel_gt is
already asleep by the time we try and setup the breadcrumb interrupt, by
a process of elimination we know the request must have been completed
and we can skip its enablement!

<4> [1518.350005] Unclaimed write to register 0x220a8
<4> [1518.350323] WARNING: CPU: 2 PID: 3685 at drivers/gpu/drm/i915/intel_uncore.c:1163 __unclaimed_reg_debug+0x40/0x50 [i915]
<4> [1518.350393] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core btusb cdc_ether btrtl usbnet btbcm btintel r8152 snd_pcm mii bluetooth ecdh_generic ecc i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers [last unloaded: vgem]
<4> [1518.350646] CPU: 2 PID: 3685 Comm: gem_exec_parse_ Tainted: G     U            5.4.0-rc8-CI-CI_DRM_7490+ #1
<4> [1518.350708] Hardware name: Google Caroline/Caroline, BIOS MrChromebox 08/27/2018
<4> [1518.350946] RIP: 0010:__unclaimed_reg_debug+0x40/0x50 [i915]
<4> [1518.350992] Code: 74 05 5b 5d 41 5c c3 45 84 e4 48 c7 c0 95 8d 47 a0 48 c7 c6 8b 8d 47 a0 48 0f 44 f0 89 ea 48 c7 c7 9e 8d 47 a0 e8 40 45 e3 e0 <0f> 0b 83 2d 27 4f 2a 00 01 5b 5d 41 5c c3 66 90 41 55 41 54 55 53
<4> [1518.351100] RSP: 0018:ffffc900007f39c8 EFLAGS: 00010086
<4> [1518.351140] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
<4> [1518.351202] RDX: 0000000080000006 RSI: 0000000000000000 RDI: 00000000ffffffff
<4> [1518.351249] RBP: 00000000000220a8 R08: 0000000000000000 R09: 0000000000000000
<4> [1518.351296] R10: ffffc900007f3990 R11: ffffc900007f3868 R12: 0000000000000000
<4> [1518.351342] R13: 00000000fefeffff R14: 0000000000000092 R15: ffff888155fea000
<4> [1518.351391] FS:  00007fc255abfe40(0000) GS:ffff88817ab00000(0000) knlGS:0000000000000000
<4> [1518.351445] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [1518.351485] CR2: 00007fc2554882d0 CR3: 0000000168ca2005 CR4: 00000000003606e0
<4> [1518.351529] Call Trace:
<4> [1518.351746]  fwtable_write32+0x114/0x1d0 [i915]
<4> [1518.351795]  ? sync_file_alloc+0x80/0x80
<4> [1518.352039]  gen8_logical_ring_enable_irq+0x30/0x50 [i915]
<4> [1518.352295]  irq_enable.part.10+0x23/0x40 [i915]
<4> [1518.352523]  i915_request_enable_breadcrumb+0xb5/0x330 [i915]
<4> [1518.352575]  ? sync_file_alloc+0x80/0x80
<4> [1518.352612]  __dma_fence_enable_signaling+0x60/0x160
<4> [1518.352653]  ? sync_file_alloc+0x80/0x80
<4> [1518.352685]  dma_fence_add_callback+0x44/0xd0
<4> [1518.352726]  sync_file_poll+0x95/0xc0
<4> [1518.352767]  do_sys_poll+0x24d/0x570

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205215842.862750-1-chris@chris-wilson.co.uk

drm/i915: Claim vma while under closed_lock in i915_vma_parked()

Remove the vma we wish to destroy from the gt->closed_list to avoid
having two i915_vma_parked() try and free it.

Fixes: aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events")
References: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205214159.829727-1-chris@chris-wilson.co.uk

drm/i915/gt: Trim gen6 ppgtt updates to PD cachelines

It appears now that we have the ring TLB invalidation in place, we need
only update the page directory cachelines that we have altered. A great
reduction from rewriting the whole 2MiB ppgtt on every update.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205234059.1010030-1-chris@chris-wilson.co.uk

drm/i915: Serialise i915_active_acquire() with __active_retire()

As __active_retire() does it's final atomic_dec() under the
ref->tree_lock spinlock, in order to prevent ourselves from reusing the
ref->cache and ref->tree as they are being destroyed, we need to
serialise with the retirement during i915_active_acquire().

[  +0.000005] kernel BUG at drivers/gpu/drm/i915/i915_active.c:157!
[  +0.000011] invalid opcode: 0000 [#1] SMP
[  +0.000004] CPU: 7 PID: 188 Comm: kworker/u16:4 Not tainted 5.4.0-rc8-03070-gac5e57322614 #89
[  +0.000002] Hardware name: Razer Razer Blade Stealth 13 Late 2019/LY320, BIOS 1.02 09/10/2019
[  +0.000082] Workqueue: events_unbound active_work [i915]
[  +0.000059] RIP: 0010:__active_retire+0x115/0x120 [i915]
[  +0.000003] Code: 75 28 48 8b 3d 8c 6e 1a 00 48 89 ee e8 e4 5f a5 c0 48 8b 44 24 10 65 48 33 04 25 28 00 00 00 75 0f 48 83 c4 18 5b 5d 41 5c c3 <0f> 0b 0f 0b 0f 0b e8 a0 90 87 c0 0f 1f 44 00 00 48 8b 3d 54 6e 1a
[  +0.000002] RSP: 0018:ffffb833003f7e48 EFLAGS: 00010286
[  +0.000003] RAX: ffff8d6e8d726d00 RBX: ffff8d6f9db4e840 RCX: 0000000000000000
[  +0.000001] RDX: ffffffff82605930 RSI: ffff8d6f9adc4908 RDI: ffff8d6e96cefe28
[  +0.000002] RBP: ffff8d6e96cefe00 R08: 0000000000000000 R09: ffff8d6f9ffe9a50
[  +0.000002] R10: 0000000000000048 R11: 0000000000000018 R12: ffff8d6f9adc4930
[  +0.000001] R13: ffff8d6f9e04fb00 R14: 0000000000000000 R15: ffff8d6f9adc4988
[  +0.000002] FS:  0000000000000000(0000) GS:ffff8d6f9ffc0000(0000) knlGS:0000000000000000
[  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000002] CR2: 000055eb5a34cf10 CR3: 000000018d609002 CR4: 0000000000760ee0
[  +0.000002] PKRU: 55555554
[  +0.000001] Call Trace:
[  +0.000010]  process_one_work+0x1aa/0x350
[  +0.000004]  worker_thread+0x4d/0x3a0
[  +0.000004]  kthread+0xfb/0x130
[  +0.000004]  ? process_one_work+0x350/0x350
[  +0.000003]  ? kthread_park+0x90/0x90
[  +0.000005]  ret_from_fork+0x1f/0x40

Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: c9ad602feabe ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205183332.801237-1-chris@chris-wilson.co.uk

drm/i915/gt: Replace I915_READ with intel_uncore_read

Get rid of the last remaining I915_READ in gt/ and make gt-land
the first I915_READ-free happy island.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205164422.727968-1-chris@chris-wilson.co.uk

drm/i915/gt: Save irqstate around virtual_context_destroy

As virtual_context_destroy() may be called from a request signal, it may
be called from inside an irq-off section, and so we need to do a full
save/restore of the irq state rather than blindly re-enable irqs upon
unlocking.

<4> [110.024262] WARNING: inconsistent lock state
<4> [110.024277] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G     U
<4> [110.024292] --------------------------------
<4> [110.024305] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
<4> [110.024323] kworker/0:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
<4> [110.024338] ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.024592] {IN-HARDIRQ-W} state was registered at:
<4> [110.024612]   lock_acquire+0xa7/0x1c0
<4> [110.024627]   _raw_spin_lock_irqsave+0x33/0x50
<4> [110.024788]   intel_engine_breadcrumbs_irq+0x38c/0x600 [i915]
<4> [110.024808]   irq_work_run_list+0x49/0x70
<4> [110.024824]   irq_work_run+0x26/0x50
<4> [110.024839]   smp_irq_work_interrupt+0x44/0x1e0
<4> [110.024855]   irq_work_interrupt+0xf/0x20
<4> [110.024871]   __do_softirq+0xb7/0x47f
<4> [110.024885]   irq_exit+0xba/0xc0
<4> [110.024898]   do_IRQ+0x83/0x160
<4> [110.024910]   ret_from_intr+0x0/0x1d
<4> [110.024922] irq event stamp: 172864
<4> [110.024938] hardirqs last  enabled at (172863): [<ffffffff819ea214>] _raw_spin_unlock_irq+0x24/0x50
<4> [110.024963] hardirqs last disabled at (172864): [<ffffffff819e9fba>] _raw_spin_lock_irq+0xa/0x40
<4> [110.024988] softirqs last  enabled at (172812): [<ffffffff81c00385>] __do_softirq+0x385/0x47f
<4> [110.025012] softirqs last disabled at (172797): [<ffffffff810b829a>] irq_exit+0xba/0xc0
<4> [110.025031]
other info that might help us debug this:
<4> [110.025049]  Possible unsafe locking scenario:

<4> [110.025065]        CPU0
<4> [110.025075]        ----
<4> [110.025084]   lock(&(&rq->lock)->rlock);
<4> [110.025099]   <Interrupt>
<4> [110.025109]     lock(&(&rq->lock)->rlock);
<4> [110.025124]
*** DEADLOCK ***

<4> [110.025144] 4 locks held by kworker/0:0/5:
<4> [110.025156]  #0: ffff88827588f528 ((wq_completion)events){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025187]  #1: ffffc9000006fe78 ((work_completion)(&engine->retire_work)){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025219]  #2: ffff88825605e270 (&kernel#2){+.+.}, at: engine_retire+0x57/0xe0 [i915]
<4> [110.025405]  #3: ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.025634]
stack backtrace:
<4> [110.025653] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G     U            5.4.0-rc8-CI-CI_DRM_7489+ #1
<4> [110.025675] Hardware name:  /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [110.025856] Workqueue: events engine_retire [i915]
<4> [110.025872] Call Trace:
<4> [110.025891]  dump_stack+0x71/0x9b
<4> [110.025907]  mark_lock+0x49a/0x500
<4> [110.025926]  ? print_shortest_lock_dependencies+0x200/0x200
<4> [110.025946]  mark_held_locks+0x49/0x70
<4> [110.025962]  ? _raw_spin_unlock_irq+0x24/0x50
<4> [110.025978]  lockdep_hardirqs_on+0xa2/0x1c0
<4> [110.025995]  _raw_spin_unlock_irq+0x24/0x50
<4> [110.026171]  virtual_context_destroy+0xc5/0x2e0 [i915]
<4> [110.026376]  __active_retire+0xb4/0x290 [i915]
<4> [110.026396]  dma_fence_signal_locked+0x9e/0x1b0
<4> [110.026613]  i915_request_retire+0x451/0x930 [i915]
<4> [110.026766]  retire_requests+0x4d/0x60 [i915]
<4> [110.026919]  engine_retire+0x63/0xe0 [i915]

Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205145934.663183-1-chris@chris-wilson.co.uk

drm/i915/gem: Reinitialise the local list before repeating

As we may start the loop again, we require our local list of i915_vma
we've processed to be reinitialised.

Fixes: aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/731
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205132912.606868-1-chris@chris-wilson.co.uk

drm/i915/gt: Bump the PP_DIR invalidation for Baytrail

Invalidate the ring TLB and increase the delay required for Baytrail.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-3-chris@chris-wilson.co.uk

drm/i915: Try hard to bind the context

It is not acceptable for context pinning to fail with -ENOSPC as we
should always be able to make space in the GGTT. The only reason we may
fail is that other "temporary" context pins are reserving their space
and we need to wait for an available slot.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/676
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-2-chris@chris-wilson.co.uk

drm/i915: Ignore most failures during evict-vm

Removing all vma from the VM is best effort -- we only remove all those
ready to be removed, so forgive and VMA that becomes pinned. While
forgiving those that become pinned, also take a second look for any that
became unpinned as we waited.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-1-chris@chris-wilson.co.uk

drm/i915: Remove vestigal i915_gem_context locals from cmdparser

The use GEM context itself was removed in commit cd30a5031704
("drm/i915/gem: Excise the per-batch whitelist from the context"), but
the locals were left in place as an oversight. Remove the parameters and
clean up.

References: cd30a5031704 ("drm/i915/gem: Excise the per-batch whitelist from the context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204232616.94397-1-chris@chris-wilson.co.uk

drm/i915/gem: Hook user-extensions upto MMAP_OFFSET_IOCTL

Call i915_user_extensions() to validate the arg->extensions pointer, and
so return consistent error numbers for the future.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204162803.3841140-1-chris@chris-wilson.co.uk

drm/i915/gem: Hold the obj->vma.lock while walking the vma.list

Remember to take the lock before walking the obj->vma.list so that the
nodes do not change beneath us! E.g.,

i915_gem_object_bump_inactive_ggtt:387 GEM_BUG_ON(vma->vm != &i915->ggtt.vm)

Closes: https://gitlab.freedesktop.org/drm/intel/issues/691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204164527.3872783-1-chris@chris-wilson.co.uk

drm/i915/gem: Try to flush pending unbind events

If we cannot handle a vma within the unbind loop, try to flush the
pending events (i915_vma_parked, i915_vm_release) and try again. This
avoids a round trip to userspace that is not guaranteed to make forward
progress, as the events we wait upon require being idle.

References: cb6c3d45f948 ("drm/i915/gem: Avoid parking the vma as we unbind")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204123556.3740002-1-chris@chris-wilson.co.uk

drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET

This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).

mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional fault handlers that depends on
the object's backing pages.

Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
and use the zero extending behaviour of drm to differentiate between
them, when we inspect the flags.

To support multiple mmap types on an object we need to support multiple
mmap_offsets for an object (each offset in the global device address
space corresponding to a unique instance of the object for a file + mmap
type). As we drop the simplified drm core idea of a single mmap_offset,
we need to provide replacement hooks for the dumb mmap interface as
well.

Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1675
Testcase: igt/gem_mmap_offset
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204120032.3682839-1-chris@chris-wilson.co.uk

drm/i915/perf: drop pointless static qualifier in i915_perf_add_config_ioctl()

There is no need to have the 'T *v' variable static
since new value always be assigned before use it.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204010154.152396-1-maowenan@huawei.com

drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2

Assuming intel_crtc_arm_fifo_underrun() only gets called when
there's no pending plane updates we can utilize it on gen2 by
checking the active_planes bitmask so that we only re-enable
underrun reporting if some planes are active.
i915_fifo_underrun_reset_write() seems to have the necessary
hw_done/flip_done waits in place.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-8-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Nuke intel_pre_disable_primary_noatomic()

Let's just inline intel_pre_disable_primary_noatomic() into
intel_plane_disable_noatomic(). The CxSR disable we can do
regardless of which plane we're disabling, and while at it we can
make the gen2 underrun w/a accurate by consulting the active_planes
bitmask.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-7-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Clean up the gen2 "no planes -> underrun" workaround

We have the active_planes bitmask now so use it to properly
determine when some planes are visible for the gen2 underrun
workaround.

This let's us almost eliminate intel_post_enable_primary().
The manual underrun checks we can simply move into
intel_atomic_commit_tail() since they loop over all the pipes
already. No point in repeating the checks multiple times when
there are multiple pipes in the commit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-6-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Clean up intel_{pre,post}_plane_update()

Change the calling convention to just pass the state+crtc and
switch to intel_ types throughout.

We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/
so that we'll be able to eliminate old_primary_state later. This
is fine since we always have either both old and new state or neither.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: s/pipe_config/new_crtc_state/ intel_{pre,post}_plane_update()

Replace the old world 'pipe_config' variable name with the new thing.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Pass dev_priv to ilk_disable_lp_wm()

Get rid of another 'dev' usage by passing dev_priv instead.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Clean up arguments to nv12/scaler w/a funcs

Don't pass the redundant dev_priv to needs_nv12_wa() and
needs_scalerclk_wa().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915/gt: Set the PD again for Haswell

And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.

<7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking
<7> [509.919895] heartbeat Awake? 8
<7> [509.919903] heartbeat Barriers?: no
<7> [509.919912] heartbeat Heartbeat: 3008 ms ago
<7> [509.919930] heartbeat Reset count: 0 (global 0)
<7> [509.919937] heartbeat Requests:
<7> [509.921008] heartbeat active  a7eb:56e1*  @ 5847ms:
<7> [509.921157] heartbeat ring->start:  0x00001000
<7> [509.921164] heartbeat ring->head:   0x00001610
<7> [509.921170] heartbeat ring->tail:   0x000023d8
<7> [509.921176] heartbeat ring->emit:   0x000023d8
<7> [509.921182] heartbeat ring->space:  0x00002570
<7> [509.921189] heartbeat ring->hwsp:   0x7fffe100
<7> [509.921197] heartbeat [head 1628, postfix 1738, tail 1750, batch 0xffffffff_ffffffff]:
<7> [509.921289] heartbeat [0000] 7a000002 00100002 00000000 00000000 7a000002 01154c1e 7ffff080 00000000
<7> [509.921299] heartbeat [0020] 11000001 00002220 ffffffff 12400001 00002220 7ffff000 00000000 11000001
<7> [509.921308] heartbeat [0040] 00002228 6e900000 7a000002 00100002 00000000 00000000 7a000002 01154c1e
<7> [509.921317] heartbeat [0060] 7ffff080 00000000 12400001 00002228 7ffff000 00000000 7a000002 00100002
<7> [509.921326] heartbeat [0080] 00000000 00000000 7a000002 01154c1e 7ffff080 00000000 7a000002 001010a1
<7> [509.921335] heartbeat [00a0] 7ffff080 00000000 04000000 11000005 00022050 00010001 00012050 00010001
<7> [509.921345] heartbeat [00c0] 0001a050 00010001 00000000 0c000000 459a110c 00000000 11000005 00022050
<7> [509.921354] heartbeat [00e0] 00010000 00012050 00010000 0001a050 00010000 12400001 0001a050 7ffff000
<7> [509.921363] heartbeat [0100] 00000000 04000001 18802100 00000000 7a000002 011050a1 7fffe100 000056e1
<7> [509.921370] heartbeat [0120] 01000000 00000000
<7> [509.921538] heartbeat MMIO base:  0x00002000
<7> [509.921682] heartbeat CCID: 0x3fa0110d
<7> [509.922342] heartbeat RING_START: 0x00001000
<7> [509.922353] heartbeat RING_HEAD:  0x00001628
<7> [509.922366] heartbeat RING_TAIL:  0x000023d8
<7> [509.922381] heartbeat RING_CTL:   0x00003001
<7> [509.922396] heartbeat RING_MODE:  0x00004000
<7> [509.922408] heartbeat RING_IMR: ffffffde
<7> [509.922421] heartbeat ACTHD:  0x00000000_30e01628
<7> [509.922434] heartbeat BBADDR: 0x00000000_00004004
<7> [509.922446] heartbeat DMA_FADDR: 0x00000000_00002800
<7> [509.922458] heartbeat IPEIR: 0x00000000
<7> [509.922470] heartbeat IPEHR: 0x780c0000
<7> [509.922642] heartbeat PP_DIR_BASE: 0x6e700000
<7> [509.922652] heartbeat PP_DIR_BASE_READ: 0x00000000
<7> [509.922662] heartbeat PP_DIR_DCLV: 0xffffffff
<7> [509.922678] heartbeat E  a7eb:56e1*  @ 5849ms:
<7> [509.922689] heartbeat E  a7eb:56e2-  @ 5849ms:
<7> [509.922698] heartbeat E  a7eb:56e3  @ 5848ms:
<7> [509.922707] heartbeat E  a7eb:56e4  @ 5848ms:
<7> [509.922715] heartbeat E  a7eb:56e5  @ 5847ms:
<7> [509.922724] heartbeat E  a7eb:56e6  @ 5846ms:
<7> [509.922735] heartbeat E  a7eb:56e7  @ 5846ms:
<7> [509.922744] heartbeat ...skipping 4 executing requests...
<7> [509.922754] heartbeat E  a7eb:56ec  @ 3010ms:
<7> [509.922796] heartbeat HWSP:
<7> [509.922807] heartbeat [0000] 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922817] heartbeat [0020] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922826] heartbeat *
<7> [509.922836] heartbeat [0100] 000056e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922845] heartbeat [0120] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922851] heartbeat *
<7> [509.922870] heartbeat Idle? no
<7> [509.922878] heartbeat Signals:
<7> [509.923000] heartbeat [a7eb:56e2] @ 5850ms

Here, we have a failed context restore after the PD switch, but note
that the PP_DIR_BASE register does not match the LRI in the ring.

Bump it to 8^W 4 loops, and with that Baytrail starts passing the sanity
checks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203211631.3167430-1-chris@chris-wilson.co.uk

drm/i915/gem: Avoid parking the vma as we unbind

In order to avoid keeping a reference on the i915_vma (which is long
overdue!) we have to coordinate all the possible lifetimes and only use
the vma while we know it is alive. In this episode, we are reminded that
while idle, the closed vma are destroyed. So if the GT idles while we are
working with the vma, the vma itself becomes invalid.

First class i915_vma here we come, but in the meantime keep piling on
the straw.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203155032.3137263-1-chris@chris-wilson.co.uk

drm/i915/display/mst: Move DPMS_OFF call to post_disable

Moving just to simplify handling as there is no change in behavior.

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

drm/i915/dp: Power down sink before disable pipe/transcoder clock

Disabling pipe/transcoder clock before power down sink could cause
sink lost signal, causing it to trigger a hotplug to notify source
that link signal was lost.

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

drm/i915/display: Check the old state to find port sync slave

If the CRTC is going from enabled to disabled and it is a port sync
slave, it needs to check to the old state to be disabled before the
port sync master.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-1-jose.souza@intel.com

drm/i915/irq: Refactor gen11 display interrupt handling

Let's move handling and reset for gen11 display IRQs to their own
functions, similar to how we deal with GT interrupts. This will make
the top-level functions a bit easier to read and potentially make things
easier to deal with in the future if new platforms wind up needing
different display handling logic.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202171608.3361125-1-matthew.d.roper@intel.com
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>

drm/i915/gt: Track the context validity explicitly

Rather than assume if and only if the engine->default_state is not set
that the context is invalid, instead track when we know the context has
valid state -- either because we have copied the default_state or we
have completed a context switch to save the HW state.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203124155.3019926-1-chris@chris-wilson.co.uk

drm/i915/execlists: Skip nested spinlock for validating pending

Only along the submission path can we guarantee that the locked request
is indeed from a foreign engine, and so the nesting of engine/rq is
permissible. On the submission tasklet (process_csb()), we may find
ourselves competing with the normal nesting of rq/engine, invalidating
our nesting. As we only use the spinlock for debug purposes, skip the
debug if we cannot acquire the spinlock for safe validation - catching
99% of the bugs is better than causing a hard lockup.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: c95d31c3df1b ("drm/i915/execlists: Lock the request while validating it during promotion")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-2-chris@chris-wilson.co.uk

drm/i915/execlists: Add a couple more validity checks to assert_pending()

Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-1-chris@chris-wilson.co.uk

drm/i915: Lift i915_vma_pin() out of intel_renderstate_emit()

Once inside a request, inside the timeline->mutex, pinning is verboten.

<4> [896.032829] ======================================================
<4> [896.032831] WARNING: possible circular locking dependency detected
<4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1 Tainted: G     U
<4> [896.032838] ------------------------------------------------------
<4> [896.032841] gem_exec_parall/3720 is trying to acquire lock:
<4> [896.032844] ffff888401863270 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [896.032915]
but task is already holding lock:
<4> [896.032917] ffff8883ec1c93c0 (&vm->mutex){+.+.}, at: i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.032952]
which lock already depends on the new lock.

<4> [896.032954]
the existing dependency chain (in reverse order) is:
<4> [896.032956]
-> #1 (&vm->mutex){+.+.}:
<4> [896.032961]        __mutex_lock+0x9a/0x9d0
<4> [896.032995]        i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.033033]        intel_renderstate_emit+0xb9/0x9e0 [i915]
<4> [896.033081]        i915_gem_init+0x5a9/0xa50 [i915]
<4> [896.033112]        i915_driver_probe+0xb00/0x15f0 [i915]
<4> [896.033144]        i915_pci_probe+0x43/0x1c0 [i915]
<4> [896.033149]        pci_device_probe+0x9e/0x120
<4> [896.033154]        really_probe+0xea/0x420
<4> [896.033158]        driver_probe_device+0x10b/0x120
<4> [896.033161]        device_driver_attach+0x4a/0x50
<4> [896.033164]        __driver_attach+0x97/0x130
<4> [896.033168]        bus_for_each_dev+0x74/0xc0
<4> [896.033171]        bus_add_driver+0x142/0x220
<4> [896.033174]        driver_register+0x56/0xf0
<4> [896.033178]        do_one_initcall+0x58/0x2ff
<4> [896.033183]        do_init_module+0x56/0x1f8
<4> [896.033187]        load_module+0x243e/0x29f0
<4> [896.033190]        __do_sys_finit_module+0xe9/0x110
<4> [896.033194]        do_syscall_64+0x4f/0x210
<4> [896.033197]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [896.033200]
-> #0 (&kernel#2){+.+.}:
<4> [896.033206]        __lock_acquire+0x1328/0x15d0
<4> [896.033209]        lock_acquire+0xa7/0x1c0
<4> [896.033213]        __mutex_lock+0x9a/0x9d0
<4> [896.033255]        i915_request_create+0x16/0x1c0 [i915]
<4> [896.033287]        intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [896.033327]        ggtt_flush+0x37/0x60 [i915]
<4> [896.033366]        i915_gem_evict_something+0x46b/0x5a0 [i915]
<4> [896.033407]        i915_gem_gtt_insert+0x21d/0x6a0 [i915]
<4> [896.033449]        i915_vma_pin+0xb36/0x11c0 [i915]
<4> [896.033488]        gen6_ppgtt_pin+0xd5/0x170 [i915]
<4> [896.033523]        ring_context_pin+0x2e/0xc0 [i915]
<4> [896.033554]        __intel_context_do_pin+0x6b/0x190 [i915]
<4> [896.033591]        i915_gem_do_execbuffer+0x1814/0x26c0 [i915]
<4> [896.033627]        i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [896.033632]        drm_ioctl_kernel+0xa7/0xf0
<4> [896.033635]        drm_ioctl+0x2e1/0x390
<4> [896.033638]        do_vfs_ioctl+0xa0/0x6f0
<4> [896.033641]        ksys_ioctl+0x35/0x60
<4> [896.033644]        __x64_sys_ioctl+0x11/0x20
<4> [896.033647]        do_syscall_64+0x4f/0x210
<4> [896.033650]        entry_SYSCALL_64_after_hwframe+0x49/0xbe

Lift the object allocation and pin prior to the request construction.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202204316.2665847-1-chris@chris-wilson.co.uk

drm/i915/gem: Take runtime-pm wakeref prior to unbinding

Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
happy. We cannot handle kmalloc from inside the vm->mutex, as they are
used by the shrinker, and so we must ensure the global runtime-pm is
awake prior to unbinding to avoid the potential inversion.

<4> [57.121748] ======================================================
<4> [57.121750] WARNING: possible circular locking dependency detected
<4> [57.121753] 5.4.0-rc8-CI-CI_DRM_7466+ #1 Tainted: G     U
<4> [57.121754] ------------------------------------------------------
<4> [57.121756] i915_pm_rpm/1105 is trying to acquire lock:
<4> [57.121758] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [57.121766]
but task is already holding lock:
<4> [57.121768] ffff888475a593c0 (&vm->mutex){+.+.}, at: i915_vma_unbind+0x21/0x50 [i915]
<4> [57.121868]
which lock already depends on the new lock.

<4> [57.121869]
the existing dependency chain (in reverse order) is:
<4> [57.121871]
-> #1 (&vm->mutex){+.+.}:
<4> [57.121951]        i915_gem_shrinker_taints_mutex+0xa2/0xd0 [i915]
<4> [57.122028]        i915_address_space_init+0xa9/0x170 [i915]
<4> [57.122104]        i915_ggtt_init_hw+0x47/0x130 [i915]
<4> [57.122150]        i915_driver_probe+0xbb4/0x15f0 [i915]
<4> [57.122197]        i915_pci_probe+0x43/0x1c0 [i915]
<4> [57.122202]        pci_device_probe+0x9e/0x120
<4> [57.122206]        really_probe+0xea/0x420
<4> [57.122209]        driver_probe_device+0x10b/0x120
<4> [57.122212]        device_driver_attach+0x4a/0x50
<4> [57.122214]        __driver_attach+0x97/0x130
<4> [57.122217]        bus_for_each_dev+0x74/0xc0
<4> [57.122220]        bus_add_driver+0x142/0x220
<4> [57.122222]        driver_register+0x56/0xf0
<4> [57.122226]        do_one_initcall+0x58/0x2ff
<4> [57.122230]        do_init_module+0x56/0x1f8
<4> [57.122233]        load_module+0x243e/0x29f0
<4> [57.122236]        __do_sys_finit_module+0xe9/0x110
<4> [57.122239]        do_syscall_64+0x4f/0x210
<4> [57.122242]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [57.122244]
-> #0 (fs_reclaim){+.+.}:
<4> [57.122249]        __lock_acquire+0x1328/0x15d0
<4> [57.122251]        lock_acquire+0xa7/0x1c0
<4> [57.122254]        fs_reclaim_acquire.part.117+0x24/0x30
<4> [57.122257]        __kmalloc+0x48/0x320
<4> [57.122261]        acpi_ns_internalize_name+0x44/0x9b
<4> [57.122264]        acpi_ns_get_node_unlocked+0x6b/0xd3
<4> [57.122267]        acpi_ns_get_node+0x3b/0x50
<4> [57.122271]        acpi_get_handle+0x8a/0xb4
<4> [57.122274]        acpi_has_method+0x1c/0x40
<4> [57.122278]        acpi_pci_set_power_state+0x40/0xe0
<4> [57.122281]        pci_platform_power_transition+0x3e/0x90
<4> [57.122284]        pci_set_power_state+0x83/0xf0
<4> [57.122287]        pci_restore_standard_config+0x22/0x40
<4> [57.122289]        pci_pm_runtime_resume+0x23/0xc0
<4> [57.122293]        __rpm_callback+0xb1/0x110
<4> [57.122296]        rpm_callback+0x1a/0x70
<4> [57.122299]        rpm_resume+0x50e/0x790
<4> [57.122302]        __pm_runtime_resume+0x42/0x80
<4> [57.122357]        __intel_runtime_pm_get+0x15/0x60 [i915]
<4> [57.122435]        ggtt_unbind_vma+0x24/0x60 [i915]
<4> [57.122514]        __i915_vma_unbind.part.39+0xb5/0x500 [i915]
<4> [57.122593]        i915_vma_unbind+0x2d/0x50 [i915]
<4> [57.122668]        i915_gem_object_unbind+0x11c/0x260 [i915]
<4> [57.122740]        i915_gem_object_set_cache_level+0x32/0x90 [i915]
<4> [57.122810]        i915_gem_set_caching_ioctl+0x1f7/0x2f0 [i915]
<4> [57.122815]        drm_ioctl_kernel+0xa7/0xf0
<4> [57.122818]        drm_ioctl+0x2e1/0x390
<4> [57.122822]        do_vfs_ioctl+0xa0/0x6f0
<4> [57.122825]        ksys_ioctl+0x35/0x60
<4> [57.122828]        __x64_sys_ioctl+0x11/0x20
<4> [57.122830]        do_syscall_64+0x4f/0x210
<4> [57.122833]        entry_SYSCALL_64_after_hwframe+0x49/0xbe

Closes: https://gitlab.freedesktop.org/drm/intel/issues/711
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203101347.2836057-1-chris@chris-wilson.co.uk

drm/i915: Serialise i915_active_wait() with its retirement

As the i915_active.retire() may be running on another CPU as we detect
that the i915_active is idle, we may not wait for the retirement itself.
Wait for the remote callback by waiting for the retirement worker.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112424
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202140133.2444217-2-chris@chris-wilson.co.uk

drm/i915: Specialise i915_active.work lock classes

Similar to for i915_active.mutex, we require each class of i915_active
to have distinct lockdep chains as some, but by no means all,
i915_active are used within the shrinker and so have much more severe
usage constraints. By using a lockclass local to i915_active_init() all
i915_active workers have the same lock class, and we may generate false
positives when waiting for the i915_active. If we push the lockclass
into the caller, each class of i915_active will have distinct lockdep
chains.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202140133.2444217-1-chris@chris-wilson.co.uk

drm/i915/gem: Unbind all current vma on changing cache-level

Avoid dangerous race handling of destroyed vma by unbinding all vma
instead. Unfortunately, this stops us from trying to be clever and only
doing the minimal change required, so on first use of scanout we may
encounter an annoying stall as it transitions to a new cache level.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202174310.2630302-1-chris@chris-wilson.co.uk

drm/i915/gt: Simplify rc6 w/a application

Quite simply we only need to check for prior corruption on enabling rc6
on module load and resume, so by hooking into the common entry points.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202110836.2342685-2-chris@chris-wilson.co.uk

drm/i915/gt: Use soft-rc6 for w/a protection

Now that we have soft-rc6 in place, we can use that instead of the
forcewake to disable rc6 while active; preferred by a few
microbenchmarks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202110836.2342685-1-chris@chris-wilson.co.uk

drm/i915/bios: assume vbt is 4-byte aligned into oprom

The unaligned ioread32() will make us read byte by byte looking for the
vbt. We could just as well have done a ioread8() + a shift and avoid the
extra confusion on how we are looking for "$VBT".

However when using ACPI it's guaranteed the VBT is 4-byte aligned
per spec, so we can probably assume it here as well.

v2: do not try to simplify the loop by eliminating the auxiliary counter
(Jani and Ville)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-4-lucas.demarchi@intel.com

drm/i915/bios: fold pci rom map/unmap into copy function

We don't need to keep the pci rom mapped during the entire
intel_bios_init() anymore. Move it to the previous copy_vbt() function
and rename it to oprom_get_vbt() since now it's responsible to to all
operations related to get the vbt from the oprom.

v2: fix double __iomem attribute detected by sparse
v3: fix missing unmap on success (Ville)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-3-lucas.demarchi@intel.com

drm/i915/bios: do not discard address space

When we map the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory.
That doesn't work on my test system, but by dumping the rom via
sysfs I can can get the correct vbt. So change our find_vbt() to do
the same as done by pci_read_rom(), i.e. use memcpy_fromio().

v2: the just the minimal changes by not bothering with the unaligned io
reads: this can be done on top (from Ville and Jani)

v3: drop const in function return since now we are copying the vbt,
rather than just finding it

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-2-lucas.demarchi@intel.com

drm/i915/display: Suspend MST topology manager before destroy fbdev

MST topology needs to be suspended so we don't have any calls to
fbdev after it's finalized. MST will be destroyed later as part of
drm_mode_config_cleanup().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127021609.162700-1-jose.souza@intel.com

drm/i915/vbt: Parse power conservation features block

From VBT 228+ this is block that PSR and other power saving
features configuration should be read from.

v3:
Using DRRS from this new block

v4:
Using BIT()
Fixing DRRS comment in parse_power_conservation_features()

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-5-jose.souza@intel.com

drm/i915/psr: Check if sink PSR capability changed

eDP specification states that sink can have its PSR capability
changed, I have never found any panel doing that but lets add that
for completeness.
For now it is not reading back the PSR capabilities and if possible
re-enabling PSR, this will be added if a panel is found using this
feature.

v4:
Cleaning DP_PSR_CAPS_CHANGE

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-4-jose.souza@intel.com

drm/i915/psr: Enable ALPM lock timeout error interruption

When this error happens sink link is not stable after the required
FW_EXIT_LATENCY period so it will miss the selective update.
As the other PSR errors, for now we are not trying to recover from
it.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-3-jose.souza@intel.com

drm/i915/psr: Refactor psr short pulse handler

eDP spec states that when sink enconters a problem that prevents it
to keep PSR running it should set PSR status to internal error and
set the reason why it happen to PSR_ERROR_STATUS but it is not how it
was implemented.
But also I don't want to change this behavior, who knows if there is
a panel out there that only set the PSR_ERROR_STATUS.

So here refactoring the code a bit to make more easy to read what was
state above as more checks will be added to this function.

v2:
returning a int instead of a bool in psr_get_status_and_error_status()

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-2-jose.souza@intel.com

drm/i915/psr: Add bits per pixel limitation

PSR2 HW only support a limited number of bits per pixel, if mode has
more than supported PSR2 should not be enabled.

BSpec: 50422
BSpec: 7713
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-1-jose.souza@intel.com

drm/i915/dsb: fix cmd_buf being wrongly set

The "err" label is not really "err", but rather "out" since the return
path is shared between error condition and normal path. This broke when
commit 03cea61076f0 ("drm/i915/dsb: fix extra warning on error path
handling") added a "dsb->cmd_buf = NULL;" there, making DSB to stop
working since now all writes would pass-through via mmio.

Remove the set to NULL since it's actually not needed: we only set it if
all steps are successful. While at it, rename the label so this confusion
doesn't happen again.

Fixes: 03cea61076f0 ("drm/i915/dsb: fix extra warning on error path handling")
Resolves: https://gitlab.freedesktop.org/drm/intel/issues/8
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127221119.384754-1-lucas.demarchi@intel.com

drm/i915: Stop using connector->encoder and encoder->crtc links in i915_display_info

Migrate away from the legacy encoder->crtc and connector->encoder links
in the debugfs display_info code. Other users still remain so can't kill
these off yet.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-10-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Dump both the uapi and hw states for crtcs and planes

Let's make the display info more useful by dumping both
the uapi and hw states for each crtc/plane.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-9-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Use the canonical [CRTC:%d:%s]/etc. format in i915_display_info

Use the canonical "[CRTC:%d:%s]" format for the obj id/name
in the debugfs display_info dump. Everyone should already be
familiar with the format since it's used in the debug logs
extensively.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-8-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Use drm_modeset_lock_all() in debugfs display info

Make out life easier by just grabbing all modeset locks around
the display_info dump.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-7-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Dump the mode for the crtc just the once

No point in repeating the crtc mode for each cloned encoder.
Just print it once, and avoid using multiple lines for it.
And while at let's polish the fixed mode print to fit on
one line as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-6-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Refactor debugfs display info code

Pull the crtc dumping stuff into a nice function so the
loop over the crtcs doesn't look like crap.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-5-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Reorganize plane/fb dump in debugfs

Eliminate the special cases for the primary and cursor planes and just
dump all the information consistently for all the planes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-4-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>