Chris Wilson [Wed, 25 Mar 2020 12:02:27 +0000 (12:02 +0000)]
drm/i915: Immediately execute the fenced work
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we still prefer to offload the task to another cpu,
especially if we plan on executing many such tasks in parallel for this
client.)
Chris Wilson [Wed, 25 Mar 2020 12:02:26 +0000 (12:02 +0000)]
drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
v2: Document the read of pending[0] from outside the tasklet with
READ_ONCE.
Chris Wilson [Wed, 25 Mar 2020 10:15:02 +0000 (10:15 +0000)]
drm/i915/selftests: Measure the energy consumed while in RC6
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.
If we can't measure the energy draw with the MSR, then it will report 0
for both measurements. Since the measurement works on all gen6+, this seems
worth flagging as an error.
Chris Wilson [Wed, 25 Mar 2020 10:13:58 +0000 (10:13 +0000)]
drm/i915/execlists: Drop setting sibling priority hint on virtual engines
We set the priority hint on execlists to avoid executing the tasklet for
when we know that there will be no change in execution order. However,
as we set it from the virtual engine for all siblings, but only one
physical engine may respond, we leave the hint set on the others
stopping direct submission that could take place.
If we do not set the hint, we may attempt direct submission even if we
don't expect to submit. If we set the hint, we may not do any submission
until the tasklet is run (and sometimes we may park the engine before
that has had a chance). Ergo there's only a minor ill-effect on mixed
virtual/physical engine workloads where we may try and fail to do direct
submission more often than required. (Pure virtual / engine workloads
will have redundant tasklet execution suppressed as normal.)
drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
dGFX has local memory so it does not have aperture or support
CPU fences but even for iGFX it have a small number of fences.
As replacement for fences to track frontbuffer modifications by CPU
we have a software tracking that is already in used by FBC and PSR.
PSR don't support fences so it shows that this tracking is reliable.
So lets make fences a nice-to-have to activate FBC for GEN9+, this
will allow us to enable FBC for dGFXs and iGFXs even when there is no
available fence.
We do not set fences to rotated planes but FBC only have restrictions
against 16bpp, so adding it here.
Also adding a new check for the tiling format, fences are only set
to X and Y tiled planes but again FBC don't have any restrictions
against tiling so adding linear as supported as well, other formats
should be added after tested but IGT only supports drawing in thse
3 formats.
intel_fbc_hw_tracking_covers_screen() maybe can also have the same
treatment as fences but BSpec is not clear if the size limitation is
for hardware tracking or general use of FBC and I don't have a 5K
display to test it, so keeping as is for safety.
v2:
- Added tiling and pixel format rotation checks
- Changed the GEN version not requiring fences to 11 from 9, DDX
needs some changes but it don't have support for GEN11+
v3:
- Changed back to GEN9+
- Moved GEN test to inside of tiling_is_valid()
v4:
- moved rotation check to its own functions
v5:
- renamed rotations_is_valid to rotation_is_valid
- moved pre-g4x rotation check to rotation_is_valid()
Cc: Daniel Vetter <daniel.vetter@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: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200319211535.114625-1-jose.souza@intel.com
Chris Wilson [Tue, 24 Mar 2020 13:42:32 +0000 (13:42 +0000)]
drm/i915/gt: Select the deepest available parking mode for rc6
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for
Ivybridge to hit the same minimum power consumption as rc6 on other
platforms, so make it so.
v2: Update selftest to include all rc6 residency counters
Note that Andi did mention that we should be converting the magic
numbers into opaque magic macros, so if they ever get reused (unlikely
given only Ivybridge used the extra modes) we'll need to pay back the
technical debt.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518 Fixes: 20ff1deabb8c ("drm/i915/gt: Manual rc6 entry upon parking")
Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324134232.8773-1-chris@chris-wilson.co.uk
Vandita Kulkarni [Thu, 12 Mar 2020 05:38:35 +0000 (11:08 +0530)]
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.
Vandita Kulkarni [Thu, 12 Mar 2020 05:38:34 +0000 (11:08 +0530)]
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)
Vandita Kulkarni [Thu, 12 Mar 2020 05:38:33 +0000 (11:08 +0530)]
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)
Chris Wilson [Mon, 23 Mar 2020 19:20:29 +0000 (19:20 +0000)]
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: 050b5f6cf516 ("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
Matthew Auld [Mon, 23 Mar 2020 13:08:21 +0000 (13:08 +0000)]
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.
Chris Wilson [Mon, 23 Mar 2020 09:28:37 +0000 (09:28 +0000)]
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.
Chris Wilson [Mon, 23 Mar 2020 10:32:21 +0000 (10:32 +0000)]
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.
Chris Wilson [Mon, 23 Mar 2020 09:28:38 +0000 (09:28 +0000)]
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.
Chris Wilson [Mon, 23 Mar 2020 09:28:41 +0000 (09:28 +0000)]
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.
Chris Wilson [Mon, 23 Mar 2020 09:28:35 +0000 (09:28 +0000)]
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: 5d93067baa0b ("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
Chris Wilson [Mon, 23 Mar 2020 09:28:34 +0000 (09:28 +0000)]
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.
Anshuman Gupta [Wed, 18 Mar 2020 08:18:37 +0000 (13:48 +0530)]
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]
Chris Wilson [Sun, 22 Mar 2020 16:32:25 +0000 (16:32 +0000)]
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.
Chris Wilson [Sun, 22 Mar 2020 16:32:24 +0000 (16:32 +0000)]
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: 60057c8cc5ff ("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+
Ville Syrjälä [Wed, 18 Mar 2020 17:45:15 +0000 (19:45 +0200)]
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)
Gwan-gyeong Mun [Tue, 11 Feb 2020 07:46:43 +0000 (09:46 +0200)]
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
Gwan-gyeong Mun [Tue, 11 Feb 2020 07:46:41 +0000 (09:46 +0200)]
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
Gwan-gyeong Mun [Tue, 11 Feb 2020 07:46:40 +0000 (09:46 +0200)]
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
Wambui Karuga [Sat, 14 Mar 2020 18:33:43 +0000 (21:33 +0300)]
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.
Wambui Karuga [Sat, 14 Mar 2020 18:33:42 +0000 (21:33 +0300)]
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;
@@
Wambui Karuga [Sat, 14 Mar 2020 18:33:40 +0000 (21:33 +0300)]
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().
Wambui Karuga [Sat, 14 Mar 2020 18:33:38 +0000 (21:33 +0300)]
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;
@@
Mario Kleiner [Mon, 16 Mar 2020 04:23:40 +0000 (05:23 +0100)]
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:
Wambui Karuga [Tue, 10 Mar 2020 08:52:45 +0000 (10:52 +0200)]
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.
Wambui Karuga [Tue, 10 Mar 2020 08:52:42 +0000 (10:52 +0200)]
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.
Wambui Karuga [Tue, 10 Mar 2020 08:52:41 +0000 (10:52 +0200)]
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;
@@
Swati Sharma [Tue, 17 Mar 2020 13:57:36 +0000 (19:27 +0530)]
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
Anshuman Gupta [Wed, 18 Mar 2020 09:44:48 +0000 (15:14 +0530)]
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]
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.
Chris Wilson [Tue, 17 Mar 2020 16:32:08 +0000 (16:32 +0000)]
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.)
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
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)
Chris Wilson [Mon, 16 Mar 2020 11:38:45 +0000 (11:38 +0000)]
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!
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
Matt Roper [Wed, 11 Mar 2020 16:23:00 +0000 (09:23 -0700)]
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.
Matt Roper [Wed, 11 Mar 2020 16:22:59 +0000 (09:22 -0700)]
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().
Matt Roper [Wed, 11 Mar 2020 16:22:57 +0000 (09:22 -0700)]
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)
Matt Roper [Wed, 11 Mar 2020 16:22:56 +0000 (09:22 -0700)]
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.
Chris Wilson [Thu, 12 Mar 2020 11:53:07 +0000 (11:53 +0000)]
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: 4f15002c8cb0 ("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
Chris Wilson [Wed, 11 Mar 2020 16:03:10 +0000 (16:03 +0000)]
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.
Tvrtko Ursulin [Thu, 12 Mar 2020 11:57:48 +0000 (11:57 +0000)]
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
Chris Wilson [Wed, 11 Mar 2020 22:17:39 +0000 (22:17 +0000)]
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.
Chris Wilson [Wed, 11 Mar 2020 22:17:38 +0000 (22:17 +0000)]
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: cffd25855556 ("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
Kai Vehmanen [Tue, 10 Mar 2020 16:23:38 +0000 (18:23 +0200)]
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.
Chris Wilson [Wed, 11 Mar 2020 09:26:22 +0000 (09:26 +0000)]
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.
Takashi Iwai [Wed, 11 Mar 2020 07:32:56 +0000 (08:32 +0100)]
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().
Wambui Karuga [Tue, 10 Mar 2020 08:52:49 +0000 (10:52 +0200)]
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;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:48 +0000 (10:52 +0200)]
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;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:46 +0000 (10:52 +0200)]
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.
Wambui Karuga [Tue, 10 Mar 2020 08:52:44 +0000 (10:52 +0200)]
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;
@@
Wambui Karuga [Tue, 10 Mar 2020 08:52:43 +0000 (10:52 +0200)]
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;
@@
Wambui Karuga [Mon, 9 Mar 2020 15:12:41 +0000 (17:12 +0200)]
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;
@@
Tvrtko Ursulin [Tue, 10 Mar 2020 16:47:33 +0000 (16:47 +0000)]
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.
Chris Wilson [Tue, 10 Mar 2020 14:24:03 +0000 (14:24 +0000)]
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.
Chris Wilson [Tue, 10 Mar 2020 14:13:18 +0000 (14:13 +0000)]
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
Chris Wilson [Tue, 10 Mar 2020 11:59:47 +0000 (11:59 +0000)]
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.
Chris Wilson [Tue, 10 Mar 2020 10:17:20 +0000 (10:17 +0000)]
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.
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()
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
Chris Wilson [Fri, 6 Mar 2020 13:38:38 +0000 (13:38 +0000)]
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.
projects / kernel.git / log