drm/i915/dsi: Add check for periodic command mode

If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.

v2: Fix sparse error, pass only intel_dsi (Jani)
v3: Use intel_de_read

Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312053841.2794-5-vandita.kulkarni@intel.com

drm/i915/dsi: Add cmd mode flags in display mode private flags

Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.

v2: Add TE flag description (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312053841.2794-4-vandita.kulkarni@intel.com

drm/i915/dsi: Add vblank calculation for command mode

Transcoder timing calculation differ for command mode.

v2: Use is_vid_mode, and use same I915_WRITE (Jani)
v3: Adjust the calculations to reflect dsc compression ratio
v4: Rearrange the vertical and horizontal timing calc, optimize
    local variables usage. (Jani)
v5: Fix the values used for calculation, use afe_clk for
    byte clock calculation, use intel_de_write/read (Jani)

Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312053841.2794-3-vandita.kulkarni@intel.com

drm/i915/dsi: Configure transcoder operation for command mode.

Configure the transcoder to operate in TE GATE command mode
and  take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.

v2: Disable util pin (Jani)
v3: Use intel_de_write (Jani)

Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312053841.2794-2-vandita.kulkarni@intel.com

drm/i915/gt: Only delay the context barrier pm

It is strictly sufficient to only delay the intel_engine_pm_put from the
context barrier (and not from the context exit) in order to prevent the
gem_exec_nop contention. Adding the delay to the context exit incurs
noticably extra penalty for soft-rc6.

Fixes: edee52c927ef ("drm/i915/gt: Delay release of engine-pm after last retirement")
Testcase: igt/i915_pm_rc6_residency/rc6-idle
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/20200323192029.20723-1-chris@chris-wilson.co.uk

drm/i915/selftests: mark huge_gem_object as not shrinkable

It looks like some callers expect a non-volatile object, that they do not
want the contents of the pages lost if they happen to not be looking at it.
The shrinker however sees that we mark the pages as DONTNEED and
believes that it can freely reap them. However, since the huge object
use plain pages, they cannot be swapped out as they have no backing
storge, and the only way we can shrink them is by discarding the
contents. In light of the callers wanting to keep the contents around,
both IS_SHRINKABLE and marking the pages as volatile are incorrect.

If we drop the IS_SHRINKABLE flag we avoid the immediate issue of the
shrinker accidentally removing valuable content. We will have to
remember that a huge object is not suitable for exercising the shrinker
interaction -- although we can introduce a shrinkable one if we require.

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/20200323130821.47914-1-matthew.auld@intel.com

drm/i915/gt: Delay release of engine-pm after last retirement

Keep the engine-pm awake until the next jiffie, to avoid immediate
ping-pong under moderate load. (Forcing the idle barrier excerbates the
moderate load, dramatically increasing the driver overhead.) On the
other hand, delaying the idle-barrier slightly incurs longer rc6-off
and so more power consumption.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/848
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/20200323092841.22240-4-chris@chris-wilson.co.uk

drm/i915: Extend intel_wakeref to support delayed puts

In some cases we want to hold onto the wakeref for a little after the
last user so that we can avoid having to drop and then immediately
reacquire it. Allow the last user to specify if they would like to keep
the wakeref alive for a short hysteresis.

v2: Embrace bitfield.h for adjustable flags.

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/20200323103221.14444-1-chris@chris-wilson.co.uk

drm/i915/selftests/perf: watch out for stolen objects

Stolen memory is allocated at creation, returning -ENOSPC if we run out
space.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1424
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/20200323110301.38806-1-matthew.auld@intel.com

drm/i915: Rely on direct submission to the queue

Drop the pretense of kicking the tasklet (used only for the defunct guc
submission backend, it should just take ownership of the submit!) and so
remove the bh-kicking from around submission.

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/20200323092841.22240-5-chris@chris-wilson.co.uk

drm/i915/gem: Avoid gem_context->mutex for simple vma lookup

As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it is exposed via the radixtree, it is visible to any other
submission).

v2: For brownie points, remove the goto spaghetti.
v3: Tighten up the closed-handle checks.

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/20200323092841.22240-8-chris@chris-wilson.co.uk

drm/i915: Avoid live-lock with i915_vma_parked()

Abuse^W Take advantage that we know we are inside the GT wakeref and
that prevents any client execbuf from reopening the i915_vma in order to
claim all the vma to close without having to drop the spinlock to free
each one individually. By keeping the spinlock, we do not have to
restart if we run concurrently with i915_gem_free_objects -- which
causes them both to restart continually and make very very slow
progress.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1361
Fixes: 77853186e547 ("drm/i915: Claim vma while under closed_lock in i915_vma_parked()")
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/20200323092841.22240-2-chris@chris-wilson.co.uk

drm/i915/gt: Mark timeline->cacheline as destroyed after rcu grace period

Since we take advantage of RCU for some i915_active objects, like the
intel_timeline_cacheline, we need to delay the i915_active_fini until
after the RCU grace period and we perform the kfree -- that is until
after all RCU protected readers.

<3> [108.204873] ODEBUG: assert_init not available (active state 0) object type: i915_active hint: __cacheline_active+0x0/0x80 [i915]
<4> [108.207377] WARNING: CPU: 3 PID: 2342 at lib/debugobjects.c:488 debug_print_object+0x67/0x90
<4> [108.207400] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec ax88179_178a snd_hwdep usbnet btusb snd_hda_core btrtl mii btbcm btintel snd_pcm bluetooth ecdh_generic ecc i915 i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers
<4> [108.207587] CPU: 3 PID: 2342 Comm: gem_exec_parall Tainted: G     U            5.6.0-rc6-CI-Patchwork_17047+ #1
<4> [108.207609] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
<4> [108.207639] RIP: 0010:debug_print_object+0x67/0x90
<4> [108.207668] Code: 83 c2 01 8b 4b 14 4c 8b 45 00 89 15 87 d2 8a 02 8b 53 10 4c 89 e6 48 c7 c7 38 2b 32 82 48 8b 14 d5 80 2f 07 82 e8 49 d5 b7 ff <0f> 0b 5b 83 05 c3 f6 22 01 01 5d 41 5c c3 83 05 b8 f6 22 01 01 c3
<4> [108.207692] RSP: 0018:ffffc90000e7f890 EFLAGS: 00010282
<4> [108.207723] RAX: 0000000000000000 RBX: ffffc90000e7f8b0 RCX: 0000000000000001
<4> [108.207747] RDX: 0000000080000001 RSI: ffff88817ada8cb8 RDI: 00000000ffffffff
<4> [108.207770] RBP: ffffffffa0341cc0 R08: ffff88816b5a8948 R09: 0000000000000000
<4> [108.207792] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82322d54
<4> [108.207814] R13: ffffffffa0341cc0 R14: ffffffff83df9568 R15: ffff88816064f400
<4> [108.207839] FS:  00007f437d753700(0000) GS:ffff88817ad80000(0000) knlGS:0000000000000000
<4> [108.207863] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [108.207887] CR2: 00007f2ad1fb5000 CR3: 00000001725d8004 CR4: 00000000003606e0
<4> [108.207907] Call Trace:
<4> [108.207959]  debug_object_assert_init+0x15c/0x180
<4> [108.208475]  ? i915_active_acquire_if_busy+0x10/0x50 [i915]
<4> [108.208513]  ? rcu_read_lock_held+0x4d/0x60
<4> [108.208970]  i915_active_acquire_if_busy+0x10/0x50 [i915]
<4> [108.209380]  intel_timeline_read_hwsp+0x81/0x540 [i915]
<4> [108.210262]  __emit_semaphore_wait+0x45/0x1b0 [i915]
<4> [108.210726]  ? i915_request_await_dma_fence+0x143/0x560 [i915]
<4> [108.211156]  i915_request_await_dma_fence+0x28a/0x560 [i915]
<4> [108.211633]  i915_request_await_object+0x24a/0x3f0 [i915]
<4> [108.212102]  eb_submit.isra.47+0x58f/0x920 [i915]
<4> [108.212622]  i915_gem_do_execbuffer+0x1706/0x2c70 [i915]
<4> [108.213071]  ? i915_gem_execbuffer2_ioctl+0xc0/0x470 [i915]

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/20200323092841.22240-1-chris@chris-wilson.co.uk

drm/i915/edp: Ignore short pulse when panel powered off

Few edp panels like Sharp is triggering short and long
hpd pulse after panel is getting powered off.
Currently driver is already ignoring long pulse for eDP
panel but in order to process the short pulse, it turns on
the VDD which requires panel power_cycle_delay + panel_power_on_delay
these delay on Sharp panel introduced the responsiveness overhead
of 800ms in the modeset sequence and as well is in suspend
sequence.
Ignoring any short pulse if panel is powered off.

FIXME: It requires to wait for panel_power_off delay in order
to check the panel power status due to pps_lock because panel triggers
short pulse immediately after writing PP_OFF to PP_CTRL register and
wait_panel_off waits for panel_power_off delay with pps_lock held.
This still creates responsiveness overhead of panel_power_off delay.

v2:
- checking vdd along with panel power to ignore the hpd. [Jani,Ville]
v3:
- safer side check to ignore the long hpd when eDP have power,
  adding type of hpd to debug log. [Jani]

Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318081837.23983-1-anshuman.gupta@intel.com

drm/i915/gt: Leave rps->cur_freq on unpark

Don't override our previous frequency we used after parking, and avoid
continually spiking back to the efficient frequency for mostly idle
workloads. Trust our ability to autotune across a workload switch.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-2-chris@chris-wilson.co.uk

drm/i915/gt: Treat idling as a RPS downclock event

If we park/unpark faster than we can respond to RPS events, we never
will process a downclock event after expiring a waitboost, and thus we
will forever restart the GPU at max clocks even if the workload switches
and doesn't justify full power.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500
Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@chris-wilson.co.uk
Cc: <stable@vger.kernel.org> # v5.5+

drm/i915/gt: Use the correct err_unlock unwind path for a closed context

A silly cut'n'paste copied the unlocked error path and used it inside
the pin_mutex lock, we need to drop that lock before returning.

Fixes: b412c63f1cba ("drm/i915/gt: Report context-is-closed prior to pinning")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200322123241.17694-1-chris@chris-wilson.co.uk

drm/i915/gt: Report context-is-closed prior to pinning

Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.

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

drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off

We only consider crtc_state->enable when initially calculating plane
visibility. Later on we try to override the plane's state to invisible
if the crtc is in DPMS off state (crtc_state->active==false).
Unfortunately the code doing that only updates the plane_state.visible
flag and the crtc_state.active_planes bimask, but forgets to update
some of the other plane bitmasks stored in the crtc_state. Namely
crtc_state.nv12_planes is left set up based on the original visibility
check which makes icl_check_nv12_planes() pick a slave plane for the
flagged plane in the bitmask. Later on we hit the watermark code
which sees a plane with a slave assigned and it then makes the
logical assumption that the master plane must itself be visible.
Since the master's plane_state.visible flag was already cleared
we get a WARN.

Fix the problem by clearing all the plane bitmasks for DPMS off.
This is more or less the wrong approach and instead we should
calculate all the plane related state purely based crtc_state->enable
(to guarantee that the subsequent DPMS on can't fail). However in
the past we definitely had some roadblocks to making that happen.
Not sure how many are left these days, but let's stick to the current
approach since it's a much simpler fix to the immediate problem
(the WARN).

v2: Keep the visible=false, it's important (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/dp: Add writing of DP SDPs

It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]

In order to pack DP HDR Metadata Infoframe SDP, it adds
intel_dp_hdr_metadata_infoframe_sdp_pack() function.
And it follows DP 1.4a spec.
([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and
[Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31])
and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame].

A mechanism and a naming rule of intel_dp_set_infoframes() function
references intel_encoder->set_infoframes() of intel_hdmi.c .
VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases.
Because PSR routine has its own routine of writing a VSC SDP, when the PSR
is enabled, intel_dp_set_infoframes() does not write a VSC SDP.

v3:
  - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be
    used for HDMI), when intel_dp_set_infoframes() function will be called.
  - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp.
v4: Use struct drm_device logging macros
v5:
  - use intel_de_*() functions for register access
  - Addressed review comments from Uma
    Polish commit message and comments
    Add 6bpc to packing of VSC SDP

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com

drm/i915/dp: Add compute routine for DP HDR Metadata Infoframe SDP

It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().

While computing, we'll also fill out the infoframes.enable bitmask
appropriately.

v2: Wrap a long line.
v4: Use struct drm_device logging macros
v5: Fix typo [Uma]

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-4-gwan-gyeong.mun@intel.com

drm/i915/dp: Add compute routine for DP VSC SDP

In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.

And it stores computed dp vsc sdp to infoframes.vsc of crtc state.
While computing we'll also fill out the inforames.enable bitmask
appropriately.

The compute routine follows DP 1.4 spec [Table 2-117: VSC SDP Payload for
DB16 through DB18].

v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v5:
  - Rebased
  - Add warning where a bpc is 6 and a pixel format is RGB.
v7: Fix the wrong check of combination bpc 6 and RGB pixelformat

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-3-gwan-gyeong.mun@intel.com

drm: Add DP1.4 VSC SDP Payload related Data Structures

It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.

enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
And enum dp_content_type corresponds "Content Type"
All of them are based on DP 1.4 spec [Table 2-117: VSC SDP Payload for
DB16 through DB18].

v3: Add a new drm data structure for DP VSC SDP
v5: Addressed review comments from Uma
    - Add kernel docs for added data structures
    - Rename enum dp_colorspace to dp_pixelformat
    - Polish commit message
    - Fix typos
    - Drop self-explanatory comments

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-2-gwan-gyeong.mun@intel.com

drm/i915/gt: Cancel a hung context if already closed

Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.

Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20200319170707.8262-2-chris@chris-wilson.co.uk

drm/i915: Use explicit flag to mark unreachable intel_context

I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.

v2:
 * Use already available context flags. (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@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/20200319170707.8262-1-chris@chris-wilson.co.uk

drm/i915: Prefer '%ps' for printing function symbol names

%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.

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/20200319091943.7815-1-chris@chris-wilson.co.uk

drm/i915/workarounds: convert to drm_device based logging macros.

Replace the use of printk based drm logging macros with the struct
drm_device based logging macros.

Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-8-wambui.karugax@gmail.com

drm/i915/rps: use struct drm_device based logging macros.

Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros in i915/gt/intel_rps.c. This also
involves extracting the drm_i915_private device pointer from various
intel types.

This converts the instances of DRM_DEBUG_DRIVER to drm_dbg() while not
converting DRM_DEBUG() instances due to the lack of an analogous
drm_device based macro.

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-7-wambui.karugax@gmail.com

drm/i915/ring_submission: use drm_device based logging macros.

Replace the use of printk based drm logging macros to the struct
drm_device based logging macros in i915/gt/intel_ring_submission.c.
This was done using the following semantic patch that transforms based
on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were fixed manually.

Note that this converts DRM_DEBUG_DRIVER to drm_dbg().

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-6-wambui.karugax@gmail.com

drm/i915/renderstate: use struct drm_device based logging macros.

Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-5-wambui.karugax@gmail.com

drm/i915/rc6: convert to struct drm_device based logging macros.

Converts various instances of the printk based drm logging macros to use
the struct drm_device logging macros. This also involves extracting the
drm_i915_private device from intel types in some cases.

Note that this converts DRM_DEBUG_DRIVER() to drm_dbg().

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-4-wambui.karugax@gmail.com

drm/i915/lrc: convert to struct drm_device based logging macros.

Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros.

Note that this converts DRM_DEBUG_DRIVER() to drm_dbg() but does not
convert DRM_DEBUG() due to the lack of an analogous drm_device based
macro.

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-3-wambui.karugax@gmail.com

drm/i915/ggtt: convert to drm_device based logging macros.

Converts various instances of the printk based drm logging macros to use
the struct drm_device based logging macros in i915/gt/intel_ggtt.c.
This change was done using the following coccinelle script that matches
based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were fixed manually.

Note that this converts DRM_DEBUG_DRIVER to drm_dbg()

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-2-wambui.karugax@gmail.com

drm/i915/tgl: Add new PCI IDs to TGL

Adding 4 new PCI IDs to TGL
Bspec: 44455

Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318221240.8180-1-swathi.dhanavanthri@intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v3)

This fixes a problem found on the MacBookPro 2017 Retina panel.

The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.

This restricts the panel to 8 bpc, not providing the full
color depth of the panel.

This patch adds a quirk specific to the MBP 2017 15" Retina
panel to add the additiional 324000 kbps link rate during
edp setup.

Link to previous discussion of a different attempted fix
with Ville and Jani:

https://patchwork.kernel.org/patch/11325935/

v2: Follow Jani's proposal of defining quirk_rates[] instead
    of just appending 324000. This for better clarity.

v3: Rebased onto current drm-tip, as of 16-March-2020. Adapt
    to new edid_quirks parameter of drm_dp_has_quirk().

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200316042340.4783-1-mario.kleiner.de@gmail.com

drm/i915/hdcp: convert to struct drm_device based logging.

Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_hdcp.c.
This also involves extracting the drm_i915_private device from the
intel_connector type for use in the macros.

v2 by Jani:
- rebase

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/47d5e88dedc08ee48938344296ada550dedd5f90.1583766715.git.jani.nikula@intel.com

drm/i915/fbdev: convert to drm_device based logging.

Convert various instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_fbdev.c.
This also involves extracting the drm_i915_private device from various
intel types.

v2 by Jani:
- fix the final one too

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7081a49d20cc46b1b1144c83a4e21294d121d8a7.1583766715.git.jani.nikula@intel.com

drm/i915/fbc: convert to drm_device based logging macros.

This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were addressed manually.

v2 by Jani:
- also convert pr_info_once to drm based logging

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com

drm/i915/color: Extract icl_read_luts()

For icl+, have hw read out to create hw blob of gamma
lut values. icl+ platforms supports multi segmented gamma
mode by default, add hw lut creation for this mode.

This will be used to validate gamma programming using dsb
(display state buffer) which is a tgl specific feature.

v2: -readout code for multisegmented gamma has to come
     up with some intermediate entries that aren't preserved
     in hardware (Jani N)
    -linear interpolation (Ville)
    -moved common code to check gamma_enable to specific funcs,
     since icl doesn't support that
v3: -use u16 instead of __u16 [Jani N]
    -used single lut [Jani N]
    -improved and more readable for loops [Jani N]
    -read values directly to actual locations and then fill gaps [Jani N]
    -moved cleaning to patch 1 [Jani N]
    -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to
     make it similar to icl_load_luts()
    -renamed icl_compute_interpolated_gamma_blob() to
     icl_compute_interpolated_gamma_lut_values() more sensible, I guess
v4: -removed interpolated func for creating gamma lut values
    -removed readouts of fine and coarse segments, failure to read PAL_PREC_DATA
     correctly
v5: -added gamma_enable check inside read_luts()
v6: -renamed intel_color_lut_entry_equal() to intel_color_lut_entries_equal() [Ville]
    -changed if-else to switch [Ville]
    -removed intel_color_lut_entry_multi_equal() [Ville]
v7: -checkpatch warnings
v8: -rebased
v9: -rebased, aligned with Ville's style of gamma cleanup

Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200317135736.14305-1-swati2.sharma@intel.com

drm/i915: Enable non-contiguous pipe fusing

As we have already enabled supported infrastructure for
non-contiguous pipe fusing in driver, we don't require non-contiguous
pipe_mask check anymore.
It is an unlike condition, it make sense to remove this condition.

changes since RFC:
- using intel_pipe_mask_is_valid() function to check integrity of
  pipe_mask. [Ville]
v2:
- simplify condition in intel_pipe_mask_is_valid(). [Ville]
v3:
- removed non-contiguous pipe fusing check. [Lucas]

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318094448.26239-1-anshuman.gupta@intel.com

drm/i915/perf: Invalidate OA TLB on when closing perf stream

On running several back to back perf capture sessions involving closing
and opening the perf stream, invalid OA reports are seen in the
beginning of the OA buffer in some sessions. Fix this by invalidating OA
TLB when the perf stream is closed or disabled on gen12.

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

drm/i915/gt: Always reschedule the new heartbeat

In order to better respond to new heartbeat intervals given via sysfs,
always reprogramme an active heartbeat upon change (i.e. use
mod_delayed_work to reschedule rather than queue_delayed_work which
ignores an already active work.)

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/20200317163208.30010-1-chris@chris-wilson.co.uk

drm/i915: Fix up documentation paths after file moving

Redirect references to i915_gem_fence_reg.c to gt/intel_ggtt_fencing.c

Fixes: dec9cf9ee8cb ("drm/i915/gt: Pull restoration of GGTT fences underneath the GT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200317141250.20903-1-chris@chris-wilson.co.uk

drm/i915/perf: introduce global sseu pinning

On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.

This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.

As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.

This makes performance analysis for 3D workloads somewhat pointless.

Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).

This change takes the initiative to move all perf related sseu
configuration into i915_perf.c

v2: Make parameter priviliged if different from default

v3: Fix context modifying its sseu config while i915-perf is enabled

v4: Always consider global sseu a privileged operation (Tvrtko)
    Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
    Remove unrelated changes (Tvrtko)

v5: Some typos (Tvrtko)
    Process sseu param in read_properties_unlocked() (Tvrtko)

v6: Actually commit the bits from v5...
    Fixup some checkpath warnings

v7: Only compare engine uabi field (Chris)

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200317132222.2638719-3-lionel.g.landwerlin@intel.com

drm/i915/perf: remove redundant power configuration register override

The caller of i915_oa_init_reg_state() already sets this.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200317132222.2638719-2-lionel.g.landwerlin@intel.com

drm/i915/perf: remove generated code

A little bit of history :

   Back when i915-perf was introduced (4.13), there was no way to
   dynamically add new OA configurations to i915. Only the generated
   configs baked in at build time were allowed.

   It quickly became obvious that we would need to allow applications
   to upload their own configurations, for instance to be able to test
   new ones, and so by the next stable version (4.14) we added uAPIs
   to allow uploading new configurations.

   When adding that capability, we took the opportunity to remove most
   HW configurations except the TestOa one which is a configuration
   IGT would rely on to verify that the HW is outputting correct
   values. At the time it made sense to have that confiuration in at
   the same time a given HW platform added to the i915-perf driver.

Now that IGT has become the reference point for HW configurations (see
commit 53f8f541ca ("lib: Add i915_perf library"), previously this was
located in the GPUTop repository), the need for having those
configurations in i915-perf is gone.

On the Mesa side, we haven't relied on this test configuration for a
while. The MDAPI library always required 4.14 feature level and always
loaded its configuration into i915.

I'm sure nobody will miss this generated stuff in i915 :)

v2: Fix selftests by creating an empty config

v3: Fix unlocking on allocation error (Dan Carpenter)

v4: Fixup checkpatch warnings

v5: Fix incorrect unlock in error path (Umesh)

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200317132222.2638719-1-lionel.g.landwerlin@intel.com

drm/i915/gem: Check for a closed context when looking up an engine

Beware that the context may already be closed as we try to lookup an
engine.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1389
Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200316161447.18410-1-chris@chris-wilson.co.uk

drm/i915/gt: Restore check for invalid vma for fencing

Apparently we do try and attach a fence to an invalid vma (during
execbuf) so we cannot simply assert it never happens and report EINVAL
instead.

Fixes: dec9cf9ee8cb ("drm/i915/gt: Pull restoration of GGTT fences underneath the GT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200316205450.15843-1-chris@chris-wilson.co.uk

drm/i915/gt: Allocate i915_fence_reg array

Since the number of fence regs can vary dramactically between platforms,
allocate the array on demand so we don't waste as much space.

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

drm/i915: Remove manual save/resume of fence register state

Since we always reload the fence register state on runtime resume,
having it explicitly in the S0ix resume code is redundant. Indeed, it
is not even being used!

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

drm/i915/gt: Pull restoration of GGTT fences underneath the GT

Make the GT responsible for restoring its fence when it wakes up from
suspend.

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

drm/i915: Move GGTT fence registers under gt/

Since the fence registers control HW detiling through the GGTT
aperture, make them a part of the intel_ggtt under gt/

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

drm/i915/gt: Restrict gen7 w/a batch to Haswell

The residual w/a batch is causing system instablity on Ivybridge and
Baytrail under some workloads, so disable until resolved.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311103640.26572-1-chris@chris-wilson.co.uk

drm/i915: Update DRIVER_DATE to 20200313

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

drm/i915/tgl: Remove require_force_probe protection

We have a few TGL machines in our CI and it is mostly green with
failures in tests that will not impact future Linux installations.
Also there is no warnings, errors, flickering or any visual defects
while doing ordinary tasks like browsing and editing documents in a
dual monitor setup.

As a reminder i915.require_force_probe was created to protect
future Linux installation's iso images that might contain a
kernel from the enabling time of the new platform. Without this
protection most of linux installation was recommending
nomodeset option during installation that was getting stick
there after installation.

Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-u.html
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-tglb.html
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218230822.66801-1-jose.souza@intel.com

drm/i915: Add Wa_1605460711 / Wa_1408767742 to ICL and EHL

This workaround appears under two different numbers (and with somewhat
confused stepping applicability on ICL).  Ultimately it appears we
should just implement this for all stepping of ICL and EHL.

Note that this is identical to Wa_1407928979:tgl that already exists in
our driver too...yet another number referencing the same actual
workaround.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-7-matthew.d.roper@intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

drm/i915: Apply Wa_1406680159:icl,ehl as an engine workaround

The register this workaround updates is a render engine register in the
MCR range, so we should initialize this in rcs_engine_wa_init() rather
than gt_wa_init().

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1222
Fixes: 36204d80bacb ("drm/i915/icl: Wa_1406680159")
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-6-matthew.d.roper@intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

drm/i915: Add Wa_1406306137:icl,ehl

v2:
 - Move to context workarounds.  ROW_CHICKEN4 is part of the context
   image on gen11 (although it isn't on gen12).

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

drm/i915: Add Wa_1604278689:icl,ehl

The bspec description for this workaround tells us to program
0xFFFF_FFFF into both FBC_RT_BASE_ADDR_REGISTER_* registers, but we've
previously found that this leads to failures in CI.  Our suspicion is
that the failures are caused by this valid turning on the "address valid
bit" even though we're intentionally supplying an invalid address.
Experimentation has shown that setting all bits _except_ for the
RT_VALID bit seems to avoid these failures.

v2:
 - Mask off the RT_VALID bit.  Experimentation with CI trybot indicates
   that this is necessary to avoid reset failures on BCS.

v3:
 - Program RT_BASE before RT_BASE_UPPER so that the valid bit is turned
   off by the first write.  (Chris)

Bspec: 11388
Bspec: 33451
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-4-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Add Wa_1209644611:icl,ehl

On gen11 the XY_FAST_COPY_BLT command has some size restrictions on its
usage.  Although this instruction is mainly used by userspace, i915 also
uses it to copy object contents during some selftests, so let's ensure
the restrictions are followed.

Bspec: 6544
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-3-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Handle all MCR ranges

The bspec documents multiple MCR ranges; make sure they're all captured
by the driver.

Bspec: 13991, 52079
Fixes: 592a7c5e082e ("drm/i915: Extend non readable mcr range")
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-2-matthew.d.roper@intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

drm/i915/selftest: Add more poison patterns

Throw in the inverse patterns to create more examples of poison to use
against the LRC state.

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/20200313102812.30173-1-chris@chris-wilson.co.uk

Revert "drm/i915/tgl: Add extra hdc flush workaround"

This reverts commit 36a6b5d964d995b536b1925ec42052ee40ba92c4.

The commit takes care Wa_1604544889 which was fixed on a0 stepping based on
a0 replan. So no SW workaround is required on any stepping now.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Fixes: 36a6b5d964d9 ("drm/i915/tgl: Add extra hdc flush workaround")
Link: https://patchwork.freedesktop.org/patch/msgid/1c751032ce79c80c5485cae315f1a9904ce07cac.1583359940.git.caz.yokoyama@intel.com

drm/i915/gt: Wait for RCUs frees before asserting idle on unload

During driver unload, we have many asserts that we have released our
bookkeeping structs and are idle. In some cases, these struct are
protected by RCU and we do not release them until after an RCU grace
period.

Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312115307.16460-1-chris@chris-wilson.co.uk

drm/i915/selftests: Use igt_random_offset()

Switch igt_vm_isolation() to using igt_random_offset().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312154708.1720-1-chris@chris-wilson.co.uk

drm/i915/gem: Drop relocation slowpath

Since the relocations are no longer performed under a global
struct_mutex, or any other lock, that is also held by pagefault handlers,
we can relax and allow our fast path to take a fault. As we no longer
need to abort the fast path for lock avoidance, we no longer need the
slow path handling at all.

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/20200311160310.26711-1-chris@chris-wilson.co.uk

drm/i915/gen12: Disable preemption timeout

Allow super long OpenCL workloads which cannot be preempted within
the default timeout to run out of the box.

v2:
 * Make it stick out more and apply only to RCS. (Chris)

v3:
 * Mention platform override in kconfig. (Joonas)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: <stable@vger.kernel.org> # v5.6+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Michal Mrozek <Michal.mrozek@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200312115748.29970-1-tvrtko.ursulin@linux.intel.com

drm/i915/gem: Take a copy of the engines for context_barrier_task

When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.

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

drm/i915/gem: Mark up sw-fence notify function

The sw-fence notify function requires to be at least 4-byte aligned so
that we can use the low bits in the function pointer for internal fence
flags. Make it so.

References: https://gitlab.freedesktop.org/drm/intel/issues/1433
Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines")
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/20200311221739.30375-1-chris@chris-wilson.co.uk

drm/i915: Add missing HDMI audio pixel clocks for gen12

Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz
and 593.4/594Mhz. Add the missing rates and add logic to ignore
them if running on older hardware.

Bspec: 49333
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310162338.9387-1-kai.vehmanen@linux.intel.com

drm/i915/gem: Mark up the racy read of the mmap_singleton

[11057.642683] BUG: KCSAN: data-race in i915_gem_mmap [i915] / singleton_release [i915]
[11057.642717]
[11057.642740] write (marked) to 0xffff8881f24471a0 of 8 bytes by task 44668 on cpu 2:
[11057.643162]  singleton_release+0x38/0x60 [i915]
[11057.643192]  __fput+0x160/0x3c0
[11057.643217]  ____fput+0x16/0x20
[11057.643241]  task_work_run+0xba/0x100
[11057.643263]  exit_to_usermode_loop+0xe4/0xf0
[11057.643286]  do_syscall_64+0x27e/0x2c0
[11057.643314]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11057.643339]
[11057.643359] read to 0xffff8881f24471a0 of 8 bytes by task 44667 on cpu 3:
[11057.643774]  i915_gem_mmap+0x295/0x670 [i915]
[11057.643802]  mmap_region+0x62b/0xac0
[11057.643825]  do_mmap+0x414/0x6b0
[11057.643848]  vm_mmap_pgoff+0xa9/0xf0
[11057.643875]  ksys_mmap_pgoff+0x1ac/0x2f0
[11057.643900]  do_syscall_64+0x6e/0x2c0
[11057.643924]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

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

drm/i915/execlists: Track active elements during dequeue

Record the initial active element we use when building the next ELSP
submission, so that we can compare against it latter to see if there's
no change.

Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311092624.10012-2-chris@chris-wilson.co.uk

drm/i915/gt: Pull checking rps->pm_events under the irq_lock

Avoid angering kcsan by serialising the read of the pm_events with the
write in rps_disable_interrupts.

[ 6268.713419] BUG: KCSAN: data-race in intel_rps_park [i915] / rps_work [i915]
[ 6268.713437]
[ 6268.713449] write to 0xffff8881eda8efac of 4 bytes by task 1127 on cpu 3:
[ 6268.713680]  intel_rps_park+0x136/0x260 [i915]
[ 6268.713905]  __gt_park+0x61/0xa0 [i915]
[ 6268.714128]  ____intel_wakeref_put_last+0x42/0x90 [i915]
[ 6268.714352]  __intel_wakeref_put_work+0xd3/0xf0 [i915]
[ 6268.714369]  process_one_work+0x3b1/0x690
[ 6268.714384]  worker_thread+0x80/0x670
[ 6268.714398]  kthread+0x19a/0x1e0
[ 6268.714412]  ret_from_fork+0x1f/0x30
[ 6268.714423]
[ 6268.714435] read to 0xffff8881eda8efac of 4 bytes by task 950 on cpu 2:
[ 6268.714664]  rps_work+0xc2/0x680 [i915]
[ 6268.714679]  process_one_work+0x3b1/0x690
[ 6268.714693]  worker_thread+0x80/0x670
[ 6268.714707]  kthread+0x19a/0x1e0
[ 6268.714720]  ret_from_fork+0x1f/0x30

v2: Mark all reads and writes of rpm->pm_events.

The flow of enabling/disabling rps is stronly ordered, so the writes and
interrupt generation are also strongly ordered -- just this may not be
visible to the compiler, so provide annotations.

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

drm/i915: Extend i915_request_await_active to use all timelines

Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.

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/20200311092044.16353-1-chris@chris-wilson.co.uk

drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().

Signed-off-by: Takashi Iwai <tiwai@suse.de>
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/20200311073256.6535-1-tiwai@suse.de

drm/i915/overlay: convert to drm_device based logging.

Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_overlay.c.
This transformation was achieved using the following coccinelle script:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

Note that this converts DRM_DEBUG to drm_dbg().

Checkpatch warnings were addressed manually.

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ca3c14de13e308419caf33eb4bbf274f5387f1e0.1583766715.git.jani.nikula@intel.com

drm/i915/lvds: convert to drm_device based logging macros.

Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_lvds.c.
This transformation was done by the following coccinelle script that
matches based on the existence of a drm_i915_private device:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were fixed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e622ebd2ce07291f2db56174a0a0b31cc2df67df.1583766715.git.jani.nikula@intel.com

drm/i915/lpe_audio: convert to drm_device based logging macros.

Convert various uses of the printk based drm logging macros to the
struct drm_device based logging macros in
i915/display/intel_lpe_audio.c.

Note that this converts DRM_DEBUG to drm_dbg().

References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/98588d757a3729d7c8a4b1aaa0b5e7d160398b89.1583766715.git.jani.nikula@intel.com

drm/i915/hotplug: convert to drm_device based logging.

Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_hotplug.c.
In some cases, this involves extracting the drm_i915_private pointer from
the drm_device struct to be used in the logging macros.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3dfda89ab4a234f299ada77abd14163cef3f8bd4.1583766715.git.jani.nikula@intel.com

drm/i915/gmbus: convert to drm_device based logging,

Conversion instances of printk based drm logging macros to use the
struct drm_device based logging macros in i915/display/intel_gmbus.c.
This was done using the following coccinelle semantic patch that
transforms based on the existence of an existing drm_i915_private
device:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were addressed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5964ce0a603e2ec0e6110c927a11234e66891258.1583766715.git.jani.nikula@intel.com

drm/i915/fifo_underrun: convert to drm_device based logging.

Convert various instances of the printk based drm logging macros to the
struct drm_device based logging macros in
i915/display/intel_fifo_underrun.c.
This was done using the following coccinelle script:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were addressed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e8e74494c8aa662ab3fb4de1dac63fedef35c47.1583766715.git.jani.nikula@intel.com

drm/i915/dsb: convert to drm_device based logging macros.

This converts uses of the printk based drm logging macros to the struct
drm_device logging macros in i915/display/intel_dsb.c. This was done
using the following coccinelle script:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

Checkpatch warnings were fixed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f2e049c74146f5430ea95653a4f745224d36f960.1583766715.git.jani.nikula@intel.com

drm/i915: Remove debugfs i915_drpc_info and i915_forcewake_domains

The two files have been duplicated under the gt/ subdir and since there
are not apparent users looking for them at the old location lets simply
remove them and duplicated code.

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

drm/i915/execlists: Mark up data-races in virtual engines

The virtual engine passes tokens back and forth to its backing physical
engines.

[   57.372993] BUG: KCSAN: data-race in execlists_dequeue [i915] / virtual_submission_tasklet [i915]
[   57.373012]
[   57.373023] write to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 2:
[   57.373241]  execlists_dequeue+0x6fa/0x2150 [i915]
[   57.373458]  __execlists_submission_tasklet+0x48/0x60 [i915]
[   57.373677]  execlists_submission_tasklet+0xd3/0x170 [i915]
[   57.373694]  tasklet_action_common.isra.0+0x42/0xa0
[   57.373709]  __do_softirq+0xd7/0x2cd
[   57.373723]  irq_exit+0xbe/0xe0
[   57.373735]  do_IRQ+0x51/0x100
[   57.373748]  ret_from_intr+0x0/0x1c
[   57.373963]  engine_retire+0x89/0xe0 [i915]
[   57.373977]  process_one_work+0x3b1/0x690
[   57.373990]  worker_thread+0x80/0x670
[   57.374004]  kthread+0x19a/0x1e0
[   57.374017]  ret_from_fork+0x1f/0x30
[   57.374027]
[   57.374038] read to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 3:
[   57.374256]  virtual_submission_tasklet+0x27/0x5a0 [i915]
[   57.374273]  tasklet_action_common.isra.0+0x42/0xa0
[   57.374288]  __do_softirq+0xd7/0x2cd
[   57.374302]  run_ksoftirqd+0x15/0x20
[   57.374315]  smpboot_thread_fn+0x1ab/0x300
[   57.374329]  kthread+0x19a/0x1e0
[   57.374342]  ret_from_fork+0x1f/0x30

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

drm/i915: Mark up racy read of active rq->engine

As a virtual engine may change the rq->engine to point to the active
request in flight, we need to warn the compiler that an active request's
engine is volatile.

[   95.017686] write (marked) to 0xffff8881e8386b10 of 8 bytes by interrupt on cpu 2:
[   95.018123]  execlists_dequeue+0x762/0x2150 [i915]
[   95.018539]  __execlists_submission_tasklet+0x48/0x60 [i915]
[   95.018955]  execlists_submission_tasklet+0xd3/0x170 [i915]
[   95.018986]  tasklet_action_common.isra.0+0x42/0xa0
[   95.019016]  __do_softirq+0xd7/0x2cd
[   95.019043]  irq_exit+0xbe/0xe0
[   95.019068]  irq_work_interrupt+0xf/0x20
[   95.019491]  i915_request_retire+0x2c5/0x670 [i915]
[   95.019937]  retire_requests+0xa1/0xf0 [i915]
[   95.020348]  engine_retire+0xa1/0xe0 [i915]
[   95.020376]  process_one_work+0x3b1/0x690
[   95.020403]  worker_thread+0x80/0x670
[   95.020429]  kthread+0x19a/0x1e0
[   95.020454]  ret_from_fork+0x1f/0x30
[   95.020476]
[   95.020498] read to 0xffff8881e8386b10 of 8 bytes by task 8909 on cpu 3:
[   95.020918]  __i915_request_commit+0x177/0x220 [i915]
[   95.021329]  i915_gem_do_execbuffer+0x38c4/0x4e50 [i915]
[   95.021750]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[   95.021784]  drm_ioctl_kernel+0xe4/0x120
[   95.021809]  drm_ioctl+0x297/0x4c7
[   95.021832]  ksys_ioctl+0x89/0xb0
[   95.021865]  __x64_sys_ioctl+0x42/0x60
[   95.021901]  do_syscall_64+0x6e/0x2c0
[   95.021927]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

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

drm/i915/gt: Mark up racy reads for intel_context.inflight

When being used across multiple real engines inside a virtual engine,
the intel_context.inflight is updated atomically, and so we must
annotate the racy read from outside the owning context.

[11142.482846] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / __execlists_submission_tasklet [i915]
[11142.482867]
[11142.482878] write (marked) to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 2:
[11142.483107]  __execlists_submission_tasklet+0x1d33/0x2120 [i915]
[11142.483336]  execlists_submission_tasklet+0xd3/0x170 [i915]
[11142.483355]  tasklet_action_common.isra.0+0x42/0xa0
[11142.483371]  __do_softirq+0xd7/0x2cd
[11142.483384]  irq_exit+0xbe/0xe0
[11142.483401]  do_IRQ+0x51/0x100
[11142.483424]  ret_from_intr+0x0/0x1c
[11142.483446]  do_idle+0x133/0x1f0
[11142.483465]  cpu_startup_entry+0x14/0x16
[11142.483483]  start_secondary+0x120/0x180
[11142.483498]  secondary_startup_64+0xa4/0xb0
[11142.483512]
[11142.483528] read to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 1:
[11142.483755]  __execlists_submission_tasklet+0x14e/0x2120 [i915]
[11142.483981]  execlists_submission_tasklet+0xd3/0x170 [i915]
[11142.483999]  tasklet_action_common.isra.0+0x42/0xa0
[11142.484014]  __do_softirq+0xd7/0x2cd
[11142.484028]  do_softirq_own_stack+0x2a/0x40
[11142.484046]  do_softirq.part.0+0x26/0x30
[11142.484071]  __local_bh_enable_ip+0x46/0x50
[11142.484299]  i915_gem_do_execbuffer+0x39c1/0x4e50 [i915]
[11142.484528]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[11142.484546]  drm_ioctl_kernel+0xe4/0x120
[11142.484559]  drm_ioctl+0x297/0x4c7
[11142.484572]  ksys_ioctl+0x89/0xb0
[11142.484586]  __x64_sys_ioctl+0x42/0x60
[11142.484610]  do_syscall_64+0x6e/0x2c0
[11142.484627]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

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

drm/i915: Tweak scheduler's kick_submission()

Skip useless priority bumping on adding a new dependency by making sure
that we do update the priority if we would have rescheduled the active
cotnext.

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/20200310115947.6482-1-chris@chris-wilson.co.uk

drm/i915: Defer semaphore priority bumping to a workqueue

Since the semaphore fence may be signaled from inside an interrupt
handler from inside a request holding its request->lock, we cannot then
enter into the engine->active.lock for processing the semaphore priority
bump as we may traverse our call tree and end up on another held
request.

CPU 0:
[ 2243.218864]  _raw_spin_lock_irqsave+0x9a/0xb0
[ 2243.218867]  i915_schedule_bump_priority+0x49/0x80 [i915]
[ 2243.218869]  semaphore_notify+0x6d/0x98 [i915]
[ 2243.218871]  __i915_sw_fence_complete+0x61/0x420 [i915]
[ 2243.218874]  ? kmem_cache_free+0x211/0x290
[ 2243.218876]  i915_sw_fence_complete+0x58/0x80 [i915]
[ 2243.218879]  dma_i915_sw_fence_wake+0x3e/0x80 [i915]
[ 2243.218881]  signal_irq_work+0x571/0x690 [i915]
[ 2243.218883]  irq_work_run_list+0xd7/0x120
[ 2243.218885]  irq_work_run+0x1d/0x50
[ 2243.218887]  smp_irq_work_interrupt+0x21/0x30
[ 2243.218889]  irq_work_interrupt+0xf/0x20

CPU 1:
[ 2242.173107]  _raw_spin_lock+0x8f/0xa0
[ 2242.173110]  __i915_request_submit+0x64/0x4a0 [i915]
[ 2242.173112]  __execlists_submission_tasklet+0x8ee/0x2120 [i915]
[ 2242.173114]  ? i915_sched_lookup_priolist+0x1e3/0x2b0 [i915]
[ 2242.173117]  execlists_submit_request+0x2e8/0x2f0 [i915]
[ 2242.173119]  submit_notify+0x8f/0xc0 [i915]
[ 2242.173121]  __i915_sw_fence_complete+0x61/0x420 [i915]
[ 2242.173124]  ? _raw_spin_unlock_irqrestore+0x39/0x40
[ 2242.173137]  i915_sw_fence_complete+0x58/0x80 [i915]
[ 2242.173140]  i915_sw_fence_commit+0x16/0x20 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1318
Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.2+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310101720.9944-1-chris@chris-wilson.co.uk

Merge tag 'gvt-next-2020-03-10' of https://github.com/intel/gvt-linux into drm-intel-next-queued

gvt-next-2020-03-10

- Fix CFL dmabuf display after vfio edid enabling (Tina)
- Clean up scan non-priv batch debugfs entry (Chris)
- Use intel engines initialized in gvt, cleanup previous ring id (Chris)
- Use intel_gt instead (Chris)

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310081928.GG28483@zhen-hp.sh.intel.com

drm/i915/display: Do not write in removed FBC fence registers

Platforms without fences don't have FBC host tracking and those
registers are marked as reserved in those platforms.

v2: checking num_fences to write to FBC fence registers (Ville)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-2-jose.souza@intel.com

drm/i915/display: Deactive FBC in fastsets when disabled by parameter

Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()

[IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw
Setting dangerous option enable_fbc - tainting kernel
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f
i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz
[drm:intel_dp_compute_config [i915]] Force DSC en = 0
[drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset]
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
[drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0
[drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid>
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]]  rotation: 0x1, scaler: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]]  src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0
i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1
i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS
------------[ cut here ]------------
i915 0000:00:02.0: drm_WARN_ON(fbc->active)
WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915]
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers
CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G     U            5.5.0-CI-Trybot_5651+ #1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915]
Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1
RSP: 0018:ffffc90000613b68 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006
RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1
RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000
R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40
R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000
FS:  00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0
PKRU: 55555554
Call Trace:
 intel_fbc_disable+0x4a/0x50 [i915]
 intel_update_crtc+0x12c/0x1d0 [i915]
 skl_commit_modeset_enables+0x14d/0x600 [i915]
 intel_atomic_commit_tail+0x30d/0x1480 [i915]
 ? queue_work_on+0x31/0x70
 ? intel_atomic_commit_ready+0x3f/0x48 [i915]
 ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
 intel_atomic_commit+0x312/0x390 [i915]
 intel_psr_fastset_force+0x119/0x150 [i915]
 i915_edp_psr_debug_set+0x53/0x70 [i915]
 simple_attr_write+0xb0/0xd0
 full_proxy_write+0x51/0x80
 vfs_write+0xb9/0x1d0
 ksys_write+0x9f/0xe0
 do_syscall_64+0x4f/0x220
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8157240281
Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281
RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152
R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000
irq event stamp: 55208
hardirqs last  enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330
hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last  enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0
---[ end trace afa50c52e5a512bb ]---
[drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A
i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1]
i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A]
[drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0
i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0

v2:
using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville)

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/20200306185833.53984-1-jose.souza@intel.com

drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/
drm_dp_mst_connector_early_unregister(),
so let's hook that up.

Changes since v1:
* Call intel_connector_register/unregister() from
  intel_dp_mst_connector_late_register/unregister() so we don't lose
  error injection - Ville Syrjälä
Changes since v2:
* Don't forget to clean up if intel_connector_register() fails - Ville

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310195122.1590925-1-lyude@redhat.com

drm/i915: Improve the start alignment of bonded pairs

Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.

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/20200306133852.3420322-3-chris@chris-wilson.co.uk

drm/i915/gt: Defend against concurrent updates to execlists->active

[  206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[  206.875654]
[  206.875666] race at unknown origin, with read to 0xffff8881f7644480 of 8 bytes by task 703 on cpu 3:
[  206.875901]  __i915_schedule+0x7fc/0x930 [i915]
[  206.876130]  __bump_priority+0x63/0x80 [i915]
[  206.876361]  __i915_sched_node_add_dependency+0x258/0x300 [i915]
[  206.876593]  i915_sched_node_add_dependency+0x50/0xa0 [i915]
[  206.876824]  i915_request_await_dma_fence+0x1da/0x530 [i915]
[  206.877057]  i915_request_await_object+0x2fe/0x470 [i915]
[  206.877287]  i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[  206.877517]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  206.877535]  drm_ioctl_kernel+0xe4/0x120
[  206.877549]  drm_ioctl+0x297/0x4c7
[  206.877563]  ksys_ioctl+0x89/0xb0
[  206.877577]  __x64_sys_ioctl+0x42/0x60
[  206.877591]  do_syscall_64+0x6e/0x2c0
[  206.877606]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

v2: Be safe and include mb

References: https://gitlab.freedesktop.org/drm/intel/issues/1318
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/20200309170540.10332-1-chris@chris-wilson.co.uk

drm/i915: Lock gmbus/aux mutexes while changing cdclk

gmbus/aux may be clocked by cdclk, thus we should make sure no
transfers are ongoing while the cdclk frequency is being changed.
We do that by simply grabbing all the gmbus/aux mutexes. No one
else should be holding any more than one of those at a time so
the lock ordering here shouldn't matter.

v2: Use mutex_lock_nest_lock() (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302174442.5803-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Pass the crtc to the low level read_lut() funcs

The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-10-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Fix readout of PIPEGCMAX

PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.ffff. Clamp the value so that it gets
saturated to the max the uapi supports.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-9-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Refactor LUT read functions

Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-8-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Clean up integer types in color code

A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-7-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/

chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-6-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>