Lyude Paul [Tue, 15 Sep 2020 16:49:13 +0000 (12:49 -0400)]
drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
This reverts commit
0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-6-lyude@redhat.com
Lyude Paul [Wed, 16 Sep 2020 16:31:37 +0000 (12:31 -0400)]
drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-5-lyude@redhat.com
Lyude Paul [Mon, 29 Jun 2020 19:01:49 +0000 (15:01 -0400)]
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-4-lyude@redhat.com
Lyude Paul [Fri, 11 Sep 2020 17:53:05 +0000 (13:53 -0400)]
drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v9:
* Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight()
* Remove leftover detritus from lpt_setup_backlight()
v8:
* Go back to getting initial brightness level with
intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-3-lyude@redhat.com
Ville Syrjälä [Mon, 11 Jan 2021 16:37:07 +0000 (18:37 +0200)]
drm/i915: Reuse the async_flip() hook for the async flip disable w/a
On some platforms we need to trigger an extra async flip with
the async flip bit disabled, and then wait for the next vblank
until the async flip bit off state will actually latch.
Currently the w/a is just open coded for skl+ universal planes.
Instead of doing that lets reuse the .async_flip() hook for this
purpose since it needs to write the exact same set of registers.
In order to do this we'll just have the caller pass in the state
of the async flip bit explicitly.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-8-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Ville Syrjälä [Mon, 11 Jan 2021 16:37:06 +0000 (18:37 +0200)]
drm/i915: Move the async_flip bit setup into the .async_flip() hook
Set up the async flip PLANE_CTL bit directly in the
.async_flip() hook. Neither .update_plane() nor .disable_plane()
ever need to set this so having it done by skl_plane_ctl_crtc()
is rather pointless.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-7-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Ville Syrjälä [Mon, 11 Jan 2021 16:37:05 +0000 (18:37 +0200)]
drm/i915: Add plane vfuncs to enable/disable flip_done interrupt
Prepare for more platforms with async flip support by turning
the flip_done interrupt enable/disable into plane vfuncs.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-6-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Ville Syrjälä [Mon, 11 Jan 2021 16:37:04 +0000 (18:37 +0200)]
drm/i915: Generalize the async flip capability check
Only assign the plane->async_flip() vfunc when the plane supports
async flips. For now we keep this artificially limited to the primary
plane since thats the only thing the legacy page flip uapi can target
and there is no async flip support in the atomic uapi yet.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-5-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Ville Syrjälä [Mon, 11 Jan 2021 16:37:03 +0000 (18:37 +0200)]
drm/i915: Drop redundant parens
Drop the pointless extra parens.
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-4-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Ville Syrjälä [Thu, 14 Jan 2021 20:50:45 +0000 (22:50 +0200)]
drm/i915: Fix the PHY compliance test vs. hotplug mishap
I accidentally added the compliance test hacks only to
intel_dp_hotplug() which doesn't even get used on any DDI
platform. Put the same crap into intel_ddi_hotplug().
Cc: Imre Deak <imre.deak@intel.com>
Fixes:
193af12cd681 ("drm/i915: Shove the PHY test into the hotplug work")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-7-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Thu, 14 Jan 2021 20:50:40 +0000 (22:50 +0200)]
drm/i915: Fix the training pattern debug print
Currently we claim to use TPS7 when using TPS4. That is just
confusing, so let's fix the debug print.
And while we're touching this let's add the customary
encoder id/name as well.
v2: Add MISSING_CASE() (Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-2-ville.syrjala@linux.intel.com
Ville Syrjälä [Mon, 18 Jan 2021 16:21:07 +0000 (18:21 +0200)]
drm/i915: Disable TRAINING_PATTERN_SET before stopping the TPS transmission
DP spec says:
"The Source device shall start sending the idle pattern after
it has cleared the Training_Pattern byte in the DPCD."
Currently we do these in operations in the opposite order.
Swap them around to match the spec.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118162107.18424-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Lee Shawn C [Mon, 18 Jan 2021 02:27:53 +0000 (10:27 +0800)]
drm/i915: support two CSC module on gen11 and later
There are two CSC on pipeline on gen11 and later platform.
User space application is allowed to enable CTM and RGB
to YCbCr coversion at the same time now.
v2: check csc capability in {}_color_check function.
v3: can't support two CSC at the same time in {ivb,glk}_color_check.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Shankar Uma <uma.shankar@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118022753.8798-1-shawn.c.lee@intel.com
Rodrigo Vivi [Fri, 15 Jan 2021 22:52:59 +0000 (17:52 -0500)]
Merge drm/drm-next into drm-intel-next
Syncing drm-intel-next and drm-intel-gt-next to unblock ADL enabling.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Dave Airlie [Thu, 14 Jan 2021 11:13:47 +0000 (13:13 +0200)]
drm/i915: split fdi code out from intel_display.c
This just refactors out the fdi code to a separate file.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_fdi.h a bit.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f9d52c3d91f0973af308ede16e266fc9b753ecf9.1610622609.git.jani.nikula@intel.com
Dave Airlie [Thu, 14 Jan 2021 11:13:46 +0000 (13:13 +0200)]
drm/i915: refactor pll code out into intel_dpll.c
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makes sense to be an inline, otherwise this
is pretty much a straight copy cover. Also all the
remaining hooks for g45 and older end up the same now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_dpll.h a bit, de-duped intel_panel_use_ssc().]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74b58e0572858b5d1734818ca594a23040d7d44f.1610622609.git.jani.nikula@intel.com
Dave Airlie [Thu, 14 Jan 2021 11:13:45 +0000 (13:13 +0200)]
drm/i915: refactor some crtc code out of intel display. (v2)
There may be more crtc code that can be pulled out, but this
is a good start.
v2: move plane before this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_crtc.h a bit.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/eacbe964f90d189c5940c12af5e09091b37a19c3.1610622609.git.jani.nikula@intel.com
Ville Syrjälä [Mon, 11 Jan 2021 16:41:11 +0000 (18:41 +0200)]
drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're
actually outputting YCbCr 4:4:4. It would appear some protocol
converters blindy consult this bit even when the source is outputting
RGB, resulting in a visual mess.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111164111.13302-1-ville.syrjala@linux.intel.com
Fixes:
181567aa9f0d ("drm/i915: Do YCbCr 444->420 conversion via DP protocol converters")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Lyude Paul [Thu, 14 Jan 2021 22:17:05 +0000 (17:17 -0500)]
drm/i915: Pass port to intel_panel_bl_funcs.get()
In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().
So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-2-lyude@redhat.com
Zhenyu Wang [Thu, 14 Jan 2021 00:58:19 +0000 (08:58 +0800)]
drm/i915: Try to guess PCH type even without ISA bridge
Some vmm like hyperv and crosvm don't supply any ISA bridge to their guest,
when igd passthrough is equipped on these vmm, guest i915 display may
couldn't work as guest i915 detects PCH_NONE pch type.
When i915 runs as guest, this patch guess pch type through gpu type even
without ISA bridge.
v2: Fix CI warning
v3: Add HAS_DISPLAY()= true condition beforce guessing virt pch, then
refactori.
v4: Fix CI warning
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Co-developed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114005819.4290-1-xiong.y.zhang@intel.com
Chris Wilson [Wed, 23 Dec 2020 10:39:17 +0000 (10:39 +0000)]
drm/i915/display: Bitwise or the conversion colour specifier together
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op?
Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter
'color_spc' is used as return port_cap[3] & color_spc, implying that it
is indeed a mask and not a boolean value.
Fixes:
522508b665df ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201223103917.14687-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 15 Jan 2021 05:03:36 +0000 (15:03 +1000)]
Merge tag 'drm-intel-gt-next-2021-01-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko)
Avoid relying on last item ABI marker in i915_drm.h, add a
comment to mark as deprecated.
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Restore clear residuals security mitigations for Ivybridge and
Baytrail (Chris)
- Close #1858: Allow sysadmin to choose applied GPU security mitigations
through i915.mitigations=... similar to CPU (Chris)
- Fix for #2024: GPU hangs on HSW GT1 (Chris)
- Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville)
- Fix for #2797: False positive GuC loading error message (Chris)
- Fix for #2859: Missing GuC firmware for older Cometlakes (Chris)
- Lessen probability of GPU hang due to DMAR faults [reason 7,
next page table ptr is invalid] on Tigerlake (Chris)
- Fix REVID macros for TGL to fetch correct stepping (Aditya)
- Limit frequency drop to RPe on parking (Chris, Edward)
- Limit W/A
1406941453 to TGL, RKL and DG1 (Swathi)
- Make W/A
22010271021 permanent on DG1 (Lucas)
- Implement W/A
16011163337 to prevent a HS/DS hang on DG1 (Swathi)
- Only disable preemption on gen8 render engines (Chris)
- Disable arbitration around Braswell's PDP updates (Chris)
- Disable arbitration on no-preempt requests (Chris)
- Check for arbitration after writing start seqno before busywaiting (Chris)
- Retain default context state across shrinking (Venkata, CQ)
- Fix mismatch between misplaced vma check and vma insert for 32-bit
addressing userspaces (Chris, CQ)
- Propagate error for vmap() failure instead kernel NULL deref (Chris)
- Propagate error from cancelled submit due to context closure
immediately (Chris)
- Fix RCU race on HWSP tracking per request (Chris)
- Clear CMD parser shadow and GPU reloc batches (Matt A)
- Populate logical context during first pin (Maarten)
- Optimistically prune dma-resv from the shrinker (Chris)
- Fix for virtual engine ownership race (Chris)
- Remove timeslice suppression to restore fairness for virtual engines (Chris)
- Rearrange IVB/HSW workarounds properly between GT and engine (Chris)
- Taint the reset mutex with the shrinker (Chris)
- Replace direct submit with direct call to tasklet (Chris)
- Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris)
- Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko)
- Use raw clock for RC6 time estimation in PMU (Tvrtko)
- Differentiate OOM failures from invalid map types (Chris)
- Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Remove livelock from "do_idle_maps" VT-d W/A (Chris)
- Cancel the preemption timeout early in case engine reset fails (Chris)
- Code flow optimization in the scheduling code (Chris)
- Clear the execlists timers upon reset (Chris)
- Drain the breadcrumbs just once (Chris, Matt A)
- Track the overall GT awake/busy time (Chris)
- Tweak submission tasklet flushing to avoid starvation (Chris)
- Track timelines created using the HWSP to restore on resume (Chris)
- Use cmpxchg64 for 32b compatilibity for active tracking (Chris)
- Prefer recycling an idle GGTT fence to avoid GPU wait (Chris)
- Restructure GT code organization for clearer split between GuC
and execlists (Chris, Daniele, John, Matt A)
- Remove GuC code that will remain unused by new interfaces (Matt B)
- Restructure the CS timestamp clocks code to local to GT (Chris)
- Fix error return paths in perf code (Zhang)
- Replace idr_init() by idr_init_base() in perf (Deepak)
- Fix shmem_pin_map error path (Colin)
- Drop redundant free_work worker for GEM contexts (Chris, Mika)
- Increase readability and understandability of intel_workarounds.c (Lucas)
- Defer enabling the breadcrumb interrupt to after submission (Chris)
- Deal with buddy alloc block sizes beyond 4G (Venkata, Chris)
- Encode fence specific waitqueue behaviour into the wait.flags (Chris)
- Don't cancel the breadcrumb interrupt shadow too early (Chris)
- Cancel submitted requests upon context reset (Chris)
- Use correct locks in GuC code (Tvrtko)
- Prevent use of engine->wa_ctx after error (Chris, Matt R)
- Fix build warning on 32-bit (Arnd)
- Avoid memory leak if platform would have more than 16 W/A (Tvrtko)
- Avoid unnecessary #if CONFIG_PM in PMU code (Chris, Tvrtko)
- Improve debugging output (Chris, Tvrtko, Matt R)
- Make file local variables static (Jani)
- Avoid uint*_t types in i915 (Jani)
- Selftest improvements (Chris, Matt A, Dan)
- Documentation fixes (Chris, Jose)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# Conflicts:
# drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
# drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
# drivers/gpu/drm/i915/gt/intel_lrc.c
# drivers/gpu/drm/i915/gvt/mmio_context.h
# drivers/gpu/drm/i915/i915_drv.h
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114152232.GA21588@jlahtine-mobl.ger.corp.intel.com
Dave Airlie [Fri, 15 Jan 2021 03:41:32 +0000 (13:41 +1000)]
Merge tag 'drm-intel-next-2021-01-12' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- PSR fixes and improvements for selective fetch (Jose)
- GVT build fixed and cleanup (Jani)
- RKL display fixes (Lee, Matt)
- DSI fix (Hans)
- Panel Power and Backlight fixes (Anshuman, Jani)
- RPM fix (Chris)
- Fix HTI port checking (Jose)
- Clean-up in cursor code (Ville)
- Once again, trying to use fast+narrow link on eDP (Ville)
- DG1 display fix (Matt)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210112175151.GA90999@intel.com
Dave Airlie [Thu, 14 Jan 2021 23:05:23 +0000 (09:05 +1000)]
Merge tag 'amd-drm-next-5.12-2021-01-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-5.12-2021-01-08:
amdgpu:
- Rework IH ring handling on vega and navi
- Rework HDP handling for vega and navi
- swSMU documenation updates
- Overdrive support for Sienna Cichlid and newer asics
- swSMU updates for vangogh
- swSMU updates for renoir
- Enable FP16 on DCE8-11
- Misc code cleanups and bug fixes
radeon:
- Fixes for platforms that can't access PCI resources correctly
- Misc code cleanups
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108221811.3868-1-alexander.deucher@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ville Syrjälä [Mon, 19 Oct 2020 21:43:31 +0000 (00:43 +0300)]
drm/i915: Drop one more useless master_transcoder assignment
We dropped the other redundant master_transcoder assignments
earlier, but this one slipped through. Get rid of it as well.
The crtc state gets fully reset before readout so there is
no point in doing this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019214337.19330-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
José Roberto de Souza [Wed, 13 Jan 2021 13:37:59 +0000 (05:37 -0800)]
drm/i915/dg1: Apply WA
1409120013 and
14011059788
DG1 is missing those two WA so instead of copy and paste it to the DG1
function, here calling the function that implements it.
While at it also renaming tgl_init_clock_gating to
gen12lp_init_clock_gating as it is also used by DG1, RKL and ADL-S.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113133759.72055-1-jose.souza@intel.com
Jani Nikula [Wed, 13 Jan 2021 14:13:17 +0000 (16:13 +0200)]
drm/i915/selftests: fix the uint*_t types that have crept in
Always prefer the kernel types over stdint types in i915.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113141317.30765-1-jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:21 +0000 (19:44 +0200)]
drm/i915/pps: rename intel_dp_init_panel_power_sequencer* functions
There are a number of functions that "init" pps in various ways. Try to
find some more consistency in the naming.
Rename:
- intel_dp_init_panel_power_sequencer -> pps_init_delays
- intel_dp_init_panel_power_sequencer_registers -> pps_init_registers
- intel_dp_init_panel_power_timestamps -> pps_init_timestamps
as this is what the functions do. Skip the intel_ prefix here to
emphasize these are static and not exported.
No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/15260c28060f3f90276ab395da4d3999ccdb641f.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:20 +0000 (19:44 +0200)]
drm/i915/pps: rename vlv_init_panel_power_sequencer to vlv_pps_init
This function is a bit of an outlier, but try to change to a name that
is more in line with the rest of the intel_pps functions. No functional
changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/644b89c1d88d4d2cd7a9426ec7d7ea14eb65a8bc.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:19 +0000 (19:44 +0200)]
drm/i915/pps: add locked intel_pps_wait_power_cycle
Prefer keeping the unlocked variants hidden if possible. No functional
changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4b712770deab9de8c3aeea8df35269433977038a.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:18 +0000 (19:44 +0200)]
drm/i915/pps: rename intel_power_sequencer_reset to intel_pps_reset_all
Follow the usual naming pattern for functions. "reset all" because it
iterates over all DP encoders. No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b10013e2c976ca140b1ad62669e18a2e9f1e8c35.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:17 +0000 (19:44 +0200)]
drm/i915/pps: rename intel_dp_check_edp to intel_pps_check_power_unlocked
Follow the usual naming pattern for functions. No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f03f7195fb62b250847909e0972f69a151095529.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:16 +0000 (19:44 +0200)]
drm/i915/pps: abstract intel_pps_encoder_reset()
Add an "encoder reset" call to hide some more pps functions, and clean
up the callers. A minor functional change is not holding the pps lock
across the whole operation in intel_dp_encoder_reset, but instead doing
it in two steps.
v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/84a50f2700b19c6719cd3e1e931c64f1e2027551.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:15 +0000 (19:44 +0200)]
drm/i915/pps: add higher level intel_pps_init() call
Add a new init call to be called only once, unlike some of the other
various init calls. This lets us hide more functions within
intel_pps.c. No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/290865ed9b0ea79120222a24c233a2d596239076.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:14 +0000 (19:44 +0200)]
drm/i915/pps: abstract intel_pps_vdd_off_sync
Add a locked version of intel_pps_vdd_off_sync_unlocked() that does
everything the callers expect it to. No functional changes.
v2: Fix typo (Anshuman)
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e722290208d827c5cae107fe41dbfe41a494793.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:13 +0000 (19:44 +0200)]
drm/i915/pps: rename edp_panel_* to intel_pps_*_unlocked
Follow the usual naming pattern for functions, both for the prefix and
the _unlocked suffix for functions that expect the lock to be held when
calling. No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d119605ba3d9c86647a524375de2d7e3d57a5676.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:12 +0000 (19:44 +0200)]
drm/i915/pps: rename intel_edp_panel_* to intel_pps_*
Follow the usual naming pattern for functions. We don't need to repeat
"panel" here. No functional changes.
v2: Fix comment (Anshuman)
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b858271bd4d9c4a2ce15a13301d7bd9f7d121eb5.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:11 +0000 (19:44 +0200)]
drm/i915/pps: rename intel_edp_backlight_* to intel_pps_backlight_*
Follow the usual naming pattern for functions. No functional changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9887e4e278ed9a20da064bbf1d0845e52b7c3b3d.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:10 +0000 (19:44 +0200)]
drm/i915/pps: rename pps_{,un}lock -> intel_pps_{,un}lock
Start following the usual naming pattern for functions. No functional
changes.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e37623750c592c08720f3b340cf85862d0f0ca12.1610127741.git.jani.nikula@intel.com
Jani Nikula [Fri, 8 Jan 2021 17:44:09 +0000 (19:44 +0200)]
drm/i915/pps: abstract panel power sequencer from intel_dp.c
In a long overdue refactoring, split out all panel sequencer code from
intel_dp.c to new intel_pps.[ch].
The first part is mostly just code movement as-is, without cleanups or
functional changes.
We need to add a vlv_get_dpll() helper to get at the vlv/chv dpll from
pps code.
v2: Rebase.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14cc59d5734432ad976cd49ff8efce8fa413e5b2.1610127741.git.jani.nikula@intel.com
Jani Nikula [Wed, 13 Jan 2021 14:11:58 +0000 (16:11 +0200)]
drm/i915/display: fix the uint*_t types that have crept in
Always prefer the kernel types over stdint types in i915.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113141158.25513-1-jani.nikula@intel.com
Jani Nikula [Wed, 13 Jan 2021 14:37:26 +0000 (16:37 +0200)]
drm/i915/display: remove useless use of inline
skl_scaler_get_filter_select() isn't static and can't be inline.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113143726.19701-1-jani.nikula@intel.com
Chris Wilson [Wed, 13 Jan 2021 22:51:44 +0000 (22:51 +0000)]
drm/i915/gt: Rearrange ivb workarounds
Some rcs0 workarounds were being incorrectly applied to the GT, and so
we failed to restore the expected register settings after a reset.
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/20210113225144.30810-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Jan 2021 22:51:43 +0000 (22:51 +0000)]
drm/i915/gt: Rearrange vlv workarounds
Some rcs0 workarounds were being incorrectly applied to the GT, and so
we failed to restore the expected register settings after a reset.
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/20210113225144.30810-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Jan 2021 20:47:09 +0000 (20:47 +0000)]
drm/i915/gt: Replace open-coded intel_engine_stop_cs()
In the legacy ringbuffer submission, we still had an open-coded version
of intel_engine_stop_cs() with one additional verification step. Transfer
that verification to intel_engine_stop_cs() itself, and call it.
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/20210113204709.15020-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Jan 2021 16:31:15 +0000 (16:31 +0000)]
drm/i915/selftests: Bump the scheduling error threshold for fast heartbeats
Since we are system_highpri_wq, we expected the heartbeat to be
scheduled promptly. However, we see delays of over 10ms upsetting our
assertions. Accept this as inevitable and bump the minimum error
threshold to 20ms (from 6 jiffies).
<6> [616.784749] rcs0: Heartbeat delay: 3570us [2802, 9188]
<6> [616.807790] bcs0: Heartbeat delay: 2111us [745, 4372]
<6> [616.853776] vcs0: Heartbeat delay: 6485us [2424, 11637]
<3> [616.859296] vcs0: Heartbeat delay was 6485us, expected less than 6000us
<3> [616.860901] i915/intel_heartbeat_live_selftests: live_heartbeat_fast failed with error -22
v2: More context from CI.
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/20210113163115.5740-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Jan 2021 20:50:49 +0000 (20:50 +0000)]
drm/i915/selftests: Force a failed engine reset
Inject a fault into the engine reset and check that the outstanding
requests are completed despite the failed reset.
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/20210113205049.22565-1-chris@chris-wilson.co.uk
Imre Deak [Tue, 29 Dec 2020 17:22:01 +0000 (19:22 +0200)]
drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
The DP PHY vswing/pre-emphasis level programming the driver does is
related to the DPTX -> first LTTPR link segment only. Accordingly it
should be only programmed when link training the first LTTPR and kept
as-is when training subsequent LTTPRs and the DPRX. For these latter
PHYs the vs/pe levels will be set in response to writing the
DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
The above is also described in DP Standard v2.0 under 3.6.6.1.
While at it simplify and add the LTTPR that is link trained to the debug
message in intel_dp_set_signal_levels().
Fixes:
b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com
Imre Deak [Tue, 29 Dec 2020 17:22:00 +0000 (19:22 +0200)]
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c
intel_dp_set_signal_levels() is needed for link training, so move it to
intel_dp_link_training.c.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com
Daniele Ceraolo Spurio [Wed, 13 Jan 2021 02:12:36 +0000 (18:12 -0800)]
drm/i915/guc: stop calling execlists_set_default_submission
Initialize all required entries from guc_set_default_submission, instead
of calling the execlists function. The previously inherited setup has
been copied over from the execlist code and simplified by removing the
execlists submission-specific parts.
v2: move setting of relative_mmio flag to engine_setup_common (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-5-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Wed, 13 Jan 2021 02:12:35 +0000 (18:12 -0800)]
drm/i915/guc: init engine directly in GuC submission mode
Instead of starting the engine in execlists submission mode and then
switching to GuC, start directly in GuC submission mode. The initial
setup functions have been copied over from the execlists code
and simplified by removing the execlists submission-specific parts.
v2: remove unneeded unexpected starting state check (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-4-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Wed, 13 Jan 2021 02:12:34 +0000 (18:12 -0800)]
drm/i915/guc: do not dump execlists state with GuC submission
GuC owns the execlists state and the context IDs used for submission, so
the status of the ports and the CSB entries are not something we control
or can decode from the i915 side, therefore we can avoid dumping it. A
follow-up patch will also stop setting the csb pointers when using GuC
submission.
GuC dumps all the required events in the GuC logs when verbosity is set
high enough.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-3-daniele.ceraolospurio@intel.com
Matthew Brost [Wed, 13 Jan 2021 02:12:33 +0000 (18:12 -0800)]
drm/i915/guc: Delete GuC code unused in future patches
Delete GuC code unused in future patches that rewrite the GuC interface
to work with the new firmware. Most of the code deleted relates to
workqueues or execlist port. The code is safe to remove because we still
don't allow GuC submission to be enabled, even when overriding the
modparam, so it currently can't be reached.
The defines + structs for the process descriptor and workqueue remain.
Although the new GuC interface does not require either of these for the
normal submission path multi-lrc submission does. The usage of the
process descriptor and workqueue for multi-lrc will be quite different
from the code that is deleted in this patch. A future patch will
implement multi-lrc submission.
v2: add a code in the commit message about the code being safe to
remove (Chris)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-2-daniele.ceraolospurio@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:20 +0000 (13:41 +0530)]
drm/i915/hdcp: Enable HDCP 2.2 MST support
Enable HDCP 2.2 MST support till Gen12.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-20-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:19 +0000 (13:41 +0530)]
drm/i915/hdcp: Configure HDCP2.2 MST steram encryption status
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream encryption is disabled,
disable the port HDCP encryption and deauthenticate the port.
v2:
- Add connector details in drm_err. [Ram]
- 's/port_auth/hdcp_auth_status'. [Ram]
- Added a debug print for stream enc.
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-19-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:18 +0000 (13:41 +0530)]
drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redundant link check. [Ram]
v4:
- use pipe instead of port to access HDCP2_STREAM_STATUS
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-18-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:17 +0000 (13:41 +0530)]
drm/i915/hdcp: Add HDCP 2.2 stream register
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
B.Spec: 21780
B.Spec: 14410
B.Spec: 50573
v2
- Modified naming convention of HDCP2_STREAM_STATUS
for pre-gen12 platforms inline with B.Spec.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-17-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:16 +0000 (13:41 +0530)]
drm/i915/hdcp: Pass connector to check_2_2_link
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-16-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:15 +0000 (13:41 +0530)]
drm/i915/hdcp: MST streams support in hdcp port_data
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the stream_type
for each stream separately, it just take single input of
stream_type while authenticating the port and applies the
same stream_type to all streams. So driver mark each stream_type
with common highest supported content type for all streams
in DP MST Topology.
Security f/w supports RepeaterAuthStreamManage msg and m'
validation only once during port authentication and encryption.
Though it is not compulsory, security fw should support dynamic
update of content_type and should support RepeaterAuthStreamManage
msg and m' validation whenever required.
v2:
- Init the hdcp port data k for HDMI/DP SST stream.
v3:
- Cosmetic changes. [Uma]
v4:
- 's/port_auth/hdcp_port_auth'. [Ram]
- Commit log improvement.
v5:
- Comment and commit log improvement. [Ram]
v6:
- Check first connector connected status before intel_encoder_is_mst
to avoid any NULL pointer dereference.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Tested-by: Juston Li <juston.li@intel.com>
Acked-by: Juston Li <juston.li@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-15-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:14 +0000 (13:41 +0530)]
drm/hdcp: Max MST content streams
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-14-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:13 +0000 (13:41 +0530)]
misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-13-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:12 +0000 (13:41 +0530)]
drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-12-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:11 +0000 (13:41 +0530)]
drm/i915/hdcp: Pass dig_port to intel_hdcp_init
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-11-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:10 +0000 (13:41 +0530)]
drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
Enable HDCP 1.4 over DP MST for Gen12.
v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
v3:
- Connector detials in debug msg. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-10-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:09 +0000 (13:41 +0530)]
drm/i915/hdcp: Configure HDCP1.4 MST steram encryption status
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the link.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
v3:
- Cosmetic change, removed the value less comment. [Uma]
v4:
- Split the Gen12 HDCP enablement patch. [Ram]
- Add connector details in drm_err.
v5:
- uniformity for connector detail in DMESG. [Ram]
- comments improvement. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-9-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:08 +0000 (13:41 +0530)]
drm/i915/hdcp: HDCP stream encryption support
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.
Both of above requirement are same for all Gen with respect to
B.Spec Documentation.
v2:
- Cosmetic changes function name, error msg print and
stream typo fixes. [Uma]
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-8-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:07 +0000 (13:41 +0530)]
drm/i915/hdcp: Move HDCP enc status timeout to header
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.
Related: 'commit
7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-7-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:06 +0000 (13:41 +0530)]
drm/i915/hdcp: DP MST transcoder for link and stream
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-6-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:05 +0000 (13:41 +0530)]
drm/i915/hdcp: No HDCP when encoder is't initialized
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Juston Li <juston.li@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-5-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:04 +0000 (13:41 +0530)]
drm/i915/hotplug: Handle CP_IRQ for DP-MST
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-4-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:03 +0000 (13:41 +0530)]
drm/i915/hdcp: Get conn while content_type changed
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes:
a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors")
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-3-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 11 Jan 2021 08:11:02 +0000 (13:41 +0530)]
drm/i915/hdcp: Update CP property in update_pipe
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.
v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
WARN_ON.
v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]
Fixes:
33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal state")
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111081120.28417-2-anshuman.gupta@intel.com
Matthew Auld [Tue, 12 Jan 2021 16:43:00 +0000 (16:43 +0000)]
drm/i915: move region_lmem under gt
Device local-memory should be thought of as part the GT, which means it
should also sit under gt/.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
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/20210112164300.356524-1-matthew.auld@intel.com
Jani Nikula [Tue, 12 Jan 2021 17:22:46 +0000 (19:22 +0200)]
drm/i915/lmem: make intel_region_lmem_ops static
There are no users outside of intel_region_lmem.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210112172246.11933-1-jani.nikula@intel.com
Jani Nikula [Tue, 12 Jan 2021 17:04:29 +0000 (19:04 +0200)]
drm/i915/region: make intel_region_map static
There are no users outside of intel_memory_region.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210112170429.27619-1-jani.nikula@intel.com
Chris Wilson [Tue, 12 Jan 2021 10:07:59 +0000 (10:07 +0000)]
drm/i915/gt: Perform an arbitration check before busywaiting
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset preparations) on the first request afterwards. There was
no explicit MI_ARB_CHECK in this sequence as the presumption was that
the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
It did not in this circumstance, so force it.
This patch is based on the assumption that the MI_SEMAPHORE_WAIT failure
to arbitrate is a rare Tigerlake bug, similar to the lite-restore vs
semaphore issues previously seen in the CS. The explicit MI_ARB_CHECK
should always ensure that there is at least one arbitration point in the
request before the MI_SEMAPHORE_WAIT to trigger the IDLE->ACTIVE event.
Upon processing that event, we will clear the stop-ring flag and release
the semaphore from its busywait.
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/20210112100759.32698-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Jan 2021 10:07:58 +0000 (10:07 +0000)]
drm/i915/gt: Check for arbitration after writing start seqno
On the off chance that we need to arbitrate before launching the
payload, perform the check after we signal the request is ready to
start. Assuming instantaneous processing of the CS event, the request
will then be treated as having started when we make the decisions as to
how to process that CS event.
v2: More commentary about the users of i915_request_started() as a
reminder about why we are marking the initial breadcrumb.
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/20210112100759.32698-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Jan 2021 02:00:13 +0000 (02:00 +0000)]
drm/i915/selftests: Allow huge_gem_object to kick the shrinker
A new fi-cml-dallium CI machine has 8G and apparently plenty free, yet
fails some selftests with ENOMEM. The failures all seem to be from
huge_gem_object which does not try very hard to allocate memory,
skipping reclaim entirely. Let's try a bit harder and direct reclaim
before failing.
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/20210112020013.19464-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 12 Jan 2021 01:50:00 +0000 (01:50 +0000)]
drm/i915/gem: Remove stolen node before releasing the region
If this stolen object holds the last reference to the region, we need to
remove our drm_mm_node before freeing the region's drm_mm.
<4> [431.679591] Memory manager not clean during takedown.
<4> [431.679633] WARNING: CPU: 0 PID: 110 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x51/0x100
<4> [431.679655] Modules linked in: i915 vgem btusb snd_hda_codec_hdmi btrtl btbcm btintel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio bluetooth coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ecdh_generic ecc r8169 realtek lpc_ich snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers [last unloaded: i915]
<4> [431.679883] CPU: 0 PID: 110 Comm: kworker/u4:3 Tainted: G U 5.11.0-rc3-CI-CI_DRM_9583+ #1
<4> [431.679895] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
<4> [431.679905] Workqueue: i915 __i915_gem_free_work [i915]
<4> [431.680831] RIP: 0010:drm_mm_takedown+0x51/0x100
<4> [431.680850] Code: 44 24 08 65 48 33 04 25 28 00 00 00 0f 85 b6 00 00 00 48 83 c4 10 5b 5d 41 5c c3 48 89 fb 48 c7 c7 c8 b7 38 82 e8 00 d6 37 00 <0f> 0b 48 8b 3d 96 d5 d1 00 ba 00 10 00 00 be c0 0c 00 00 e8 d7 64
<4> [431.680862] RSP: 0018:
ffffc90000ad7dc0 EFLAGS:
00010282
<4> [431.680879] RAX:
0000000000000000 RBX:
ffff8881109aa140 RCX:
0000000000000001
<4> [431.680888] RDX:
0000000080000001 RSI:
ffffffff8235a70f RDI:
00000000ffffffff
<4> [431.680897] RBP:
ffff8881109aa178 R08:
0000000000000001 R09:
0000000000000001
<4> [431.680906] R10:
0000000025eaec48 R11:
00000000f5b271a7 R12:
ffff88810a38ddc0
<4> [431.680916] R13:
00000000ffffffff R14:
ffffffff82861b70 R15:
ffff88810b715538
<4> [431.680925] FS:
0000000000000000(0000) GS:
ffff88817b800000(0000) knlGS:
0000000000000000
<4> [431.680935] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4> [431.680945] CR2:
000056377cfd7c48 CR3:
00000001045de000 CR4:
00000000001006f0
<4> [431.680954] Call Trace:
<4> [431.680977] __intel_memory_region_destroy+0x24/0x50 [i915]
<4> [431.681340] i915_gem_object_release_stolen+0x26/0x40 [i915]
<4> [431.681637] __i915_gem_free_objects.isra.21+0x1ef/0x3b0 [i915]
<4> [431.681935] process_one_work+0x270/0x5c0
<4> [431.682022] worker_thread+0x37/0x380
<4> [431.682047] ? process_one_work+0x5c0/0x5c0
<4> [431.682062] kthread+0x146/0x170
<4> [431.682077] ? kthread_park+0x80/0x80
<4> [431.682098] ret_from_fork+0x22/0x30
<4> [431.682153] irq event stamp:
1872905
<4> [431.682162] hardirqs last enabled at (
1872911): [<
ffffffff8112bd9a>] console_unlock+0x49a/0x580
<4> [431.682176] hardirqs last disabled at (
1872916): [<
ffffffff8112bd06>] console_unlock+0x406/0x580
<4> [431.682187] softirqs last enabled at (
1872850): [<
ffffffff81e00342>] __do_softirq+0x342/0x48e
<4> [431.682201] softirqs last disabled at (
1872845): [<
ffffffff81c00f52>] asm_call_irq_on_stack+0x12/0x20
<4> [431.682214] ---[ end trace
5d3bcd818e2e3816 ]---
<3> [431.686188] [drm:drm_mm_takedown] *ERROR* node [
0002d000 +
00004000]: inserted at
drm_mm_insert_node_in_range+0x34a/0x5b0
i915_gem_stolen_insert_node_in_range+0x7b/0xa0 [i915]
_i915_gem_object_create_stolen+0x83/0xd0 [i915]
i915_gem_object_create_region+0x61/0x140 [i915]
intel_engine_create_ring+0x176/0x230 [i915]
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2927
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/20210112015000.16108-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 11 Jan 2021 22:52:20 +0000 (22:52 +0000)]
drm/i915: Allow the sysadmin to override security mitigations
The clear-residuals mitigation is a relatively heavy hammer and under some
circumstances the user may wish to forgo the context isolation in order
to meet some performance requirement. Introduce a generic module
parameter to allow selectively enabling/disabling different mitigations.
To disable just the clear-residuals mitigation (on Ivybridge, Baytrail,
or Haswell) use the module parameter: i915.mitigations=auto,!residuals
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
Fixes:
47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org # v5.7
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 11 Jan 2021 22:52:19 +0000 (22:52 +0000)]
drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
The mitigation is required for all gen7 platforms, now that it does not
cause GPU hangs, restore it for Ivybridge and Baytrail.
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: Bloomfield Jon <jon.bloomfield@intel.com>
Reviewed-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 11 Jan 2021 22:52:18 +0000 (22:52 +0000)]
drm/i915/gt: Limit VFE threads based on GT
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
based on plaform and the number of EU based on the number of slices and
subslices. This is a fixed number per platform/gt, so appropriately
limit the number of threads we spawn to match the device.
v2: Oversaturate the system with tasks to force execution on every HW
thread; if the thread idles it is returned to the pool and may be reused
again before an unused thread.
v3: Fix more state commands, which was causing Baytrail to barf.
v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
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: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Randy Wright <rwright@hpe.com>
Cc: stable@vger.kernel.org # v5.7+
Reviewed-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-1-chris@chris-wilson.co.uk
Matt Roper [Fri, 8 Jan 2021 22:25:28 +0000 (14:25 -0800)]
drm/i915/dg1: Update voltage swing tables for DP
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
v2:
- Use a "_hbr2_hbr3" suffix on the table name to make it more clear
that the same table is used for both HBR2 and HBR3 link rates.
(Swathi)
Bspec: 49291
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108222528.1954514-1-matthew.d.roper@intel.com
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Chris Wilson [Mon, 11 Jan 2021 10:57:35 +0000 (10:57 +0000)]
drm/i915/selftests: Include engine name after reset failure
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the
next time this happens, mention which engine that was.
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/20210111105735.21515-4-chris@chris-wilson.co.uk
Chris Wilson [Mon, 11 Jan 2021 10:57:32 +0000 (10:57 +0000)]
drm/i915/gt: Disable arbitration around Braswell's pdp updates
Braswell's pdp workaround is full of dragons, that may be being angered
when they are interrupted. Let's not take that risk and disable
arbitration during the update.
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/20210111105735.21515-1-chris@chris-wilson.co.uk
Ville Syrjälä [Thu, 7 Jan 2021 18:20:25 +0000 (20:20 +0200)]
drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.
To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.
For a bit of history we first tried to go for the fast+narrow in
commit
7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit
f11cb1c19ad0 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.
v2: Deal with output_bpp and uapi vs. hw state split
Reword some comments
v3: Rebase
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Tue, 10 Nov 2020 17:56:24 +0000 (19:56 +0200)]
drm/i915: Fix checkpatch warns in cursor code
Eliminate checkpatch warnings from intel_cursor.c:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: Possible repeated word: 'by'
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110175624.3524-2-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
José Roberto de Souza [Fri, 8 Jan 2021 13:48:02 +0000 (05:48 -0800)]
drm/i915: Fix HTI port checking
There was some misinterpretation of specification, when DDIX_USED is
set, the next bit means 0 for DP and 1 for HDMI.
Anyways this misinterpretation is not causing any issues, this change
is just to comply with specification.
Also as for us it do not matters if it is HDMI or DP, not checking the
port type that HTI is using.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108134802.21280-1-jose.souza@intel.com
Dan Carpenter [Mon, 11 Jan 2021 13:13:20 +0000 (13:13 +0000)]
drm/i915/selftests: Fix some error codes
These error paths return success instead of negative error codes as
intended.
Fixes:
c92724de6db1 ("drm/i915/selftests: Try to detect rollback during batchbuffer preemption")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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/X/xMdcewtft7+QFM@mwanda
Jani Nikula [Fri, 8 Jan 2021 15:28:41 +0000 (17:28 +0200)]
drm/i915/backlight: fix CPU mode backlight takeover on LPT
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.
The CPU mode takeover code added in commit
5b1ec9ac7ab5
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".
This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.
Fixes:
5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.1+
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
Chris Wilson [Sat, 9 Jan 2021 16:34:55 +0000 (16:34 +0000)]
drm/i915: Refactor marking a request as EIO
When wedging the device, we cancel all outstanding requests and mark
them as EIO. Rather than duplicate the small function to do so between
each submission backend, export one.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-3-chris@chris-wilson.co.uk
Chris Wilson [Sat, 9 Jan 2021 16:34:54 +0000 (16:34 +0000)]
drm/i915/gt: Mark up a debug-only function
drivers/gpu/drm/i915//gt/intel_workarounds.c:1394:20: error: function 'is_nonpriv_flags_valid' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static inline bool is_nonpriv_flags_valid(u32 flags)
This is only used by debug build, so mark it as maybe-unused to keep the
compiler from complaining.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-2-chris@chris-wilson.co.uk
Chris Wilson [Sat, 9 Jan 2021 16:34:53 +0000 (16:34 +0000)]
drm/i915/gt: Remove unused function 'dword_in_page'
>> drivers/gpu/drm/i915/gt/intel_lrc.c:17:28: error: unused function 'dword_in_page' [-Werror,-Wunused-function]
static inline unsigned int dword_in_page(void *addr)
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210109163455.28466-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 9 Jan 2021 11:44:53 +0000 (11:44 +0000)]
drm/i915/gt: Exercise lrc_wa_ctx initialisation failure
Inject a fault into lrc_init_wa_ctx() to ensure that we can tolerate a
failure to construct the workarounds.
v2: Avoid mentioning an error for fault-injection, other CI will
complain about the dmesg spam.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210109114453.27798-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:26 +0000 (20:40 +0000)]
drm/i915/gt: Disable arbitration on no-preempt requests
If a request is submitted and known to require no preemption, disable
arbitration around the batch which prevents the HW from handling a
preemption request during the payload.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-7-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:25 +0000 (20:40 +0000)]
drm/i915/gt: Only disable preemption on gen8 render engines
The reason why we did not enable preemption on Broadwater was due to
missing GPGPU workarounds. Since this only applies to rcs0, only
restrict rcs0 (and our global capabilities).
While this does not affect exposing a preemption capability to
userspace, it does affect our internal decisions on whether to use
timeslicing and semaphores between individual engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-6-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:24 +0000 (20:40 +0000)]
drm/i915/gt: Only retire on the last breadcrumb if the last request
We use the completion of the last active breadcrumb to retire the
requests along a timeline. This is purely opportunistic as nothing
guarantees that any particular timeline is terminated by a breadcrumb;
except for parking the engine where we explicitly add a breadcrumb so
that we park quickly and do an explicit retire upon signaling to reduce
the latency dramatically (avoiding a retire worker roundtrip).
With scheduling, we anticipate retiring completed timelines as a matter
of course. Performing the same action from inside the breadcrumbs is
intended to provide similar functionality for legacy ringbuffer
submission.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-5-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:23 +0000 (20:40 +0000)]
drm/i915/gt: Restore ce->signal flush before releasing virtual engine
Before we mark the virtual engine as no longer inflight, flush any
ongoing signaling that may be using the ce->signal_link along the
previous breadcrumbs. On switch to a new physical engine, that link will
be inserted into the new set of breadcrumbs, causing confusion to an
ongoing iterator.
This patch undoes a last minute mistake introduced into commit
bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer"),
whereby instead of unconditionally applying the flush, it was only
applied if the request itself was going to be reused.
v2: Generalise and cancel all remaining ce->signals
Fixes:
bab0557c8dca ("drm/i915/gt: Remove virtual breadcrumb before transfer")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:22 +0000 (20:40 +0000)]
drm/i915/selftests: Rearrange ktime_get to reduce latency against CS
In our tests where we measure the elapsed time on both the CPU and CS
using a udelay, our CS results match the udelay much more accurately
than the ktime (even when using ktime_get_fast_ns). With preemption
disabled, we can go one step lower than ktime and use local_clock.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2919
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-3-chris@chris-wilson.co.uk
Chris Wilson [Fri, 8 Jan 2021 20:40:21 +0000 (20:40 +0000)]
drm/i915/selftests: Skip unstable timing measurements
If any of the perf tests run into 0 time, not only are we liable to
divide by zero, but the result would be highly questionable.
Nevertheless, let's not have a div-by-zero error.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-2-chris@chris-wilson.co.uk
projects / linux-2.6-microblaze.git / log