Chris Wilson [Mon, 18 Mar 2019 21:23:47 +0000 (21:23 +0000)]
drm/i915: Hold a reference to the active HW context
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Chris Wilson [Mon, 18 Mar 2019 21:23:46 +0000 (21:23 +0000)]
drm/i915: Lock the gem_context->active_list while dropping the link
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Jani Nikula [Mon, 18 Mar 2019 16:00:19 +0000 (18:00 +0200)]
drm/i915: stick to kernel fixed size types
We no longer allow mixed C99 and kernel types, and the preference is to
use kernel types exclusively. Fix the C99 types that have crept in since
the mass conversion. No functional changes.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Kevin Strasser <kevin.strasser@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/20190318160019.9309-1-jani.nikula@intel.com
Chris Wilson [Mon, 18 Mar 2019 09:51:46 +0000 (09:51 +0000)]
drm/i915: Hold a ref to the ring while retiring
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we stop dereferencing it.
Chris Wilson [Mon, 18 Mar 2019 09:51:51 +0000 (09:51 +0000)]
drm/i915: Switch to use HWS indices rather than addresses
If we use the STORE_DATA_INDEX function we can use a fixed offset and
avoid having to lookup up the engine HWS address. A step closer to being
able to emit the final breadcrumb during request_add rather than later
in the submission interrupt handler.
Ville Syrjälä [Fri, 15 Mar 2019 19:54:44 +0000 (21:54 +0200)]
drm/i915: Fix legacy gamma mode for ICL
We must remember to actually enable the post CSC gamma if
we expect the legacy LUT to work. Seems to fix NV12 crc
tests on the SDR planes. Curiously we apparently managed to
get 100% match for the HDR planes even without chopping
off the low bits.
Jani Nikula [Fri, 15 Mar 2019 13:56:20 +0000 (15:56 +0200)]
drm/i915: use REG_FIELD_PREP() to define register bitfield values
Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.
Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the value fits the mask (when the
value is a constant expression).
Convert power sequencer registers as an example.
v4:
- rebase
v3:
- rename the macro to REG_FIELD_PREP to avoid underscore prefix and to
be in line with kernel macros (Chris)
- rename power of 2 check macro (Chris)
v2:
- add build-time checks with BUILD_BUG_ON_ZERO()
- rename to just _FIELD() due to regmap.h REG_FIELD() clash
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a844edda2afa6b54d9b12a6251da02c43ea8a942.1552657998.git.jani.nikula@intel.com
Jani Nikula [Fri, 15 Mar 2019 13:56:19 +0000 (15:56 +0200)]
drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.
We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_GENMASK(), but also as we'll need to redefine REG_FIELD_PREP() in
follow-up work to make it produce integer constant expressions.
For the most part, REG_FIELD_GET() is shorter than masking followed by
shift, and arguably has more clarity.
REG_FIELD_PREP() can get more verbose than simply shifting in place, but
it does provide masking to ensure we don't overflow the mask, something
we usually don't bother with currently.
Convert power sequencer registers as an example.
v3:
- temp variable removal (Chris)
- rebase
v2:
- Add the REG_FIELD_GET() and REG_FIELD_PREP() wrappers to use them
consistently from the start.
Jani Nikula [Fri, 15 Mar 2019 13:56:18 +0000 (15:56 +0200)]
drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.
We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.
The intention is that these are easier to get right and review against
the spec than hand rolled masks.
Convert power sequencer registers as an example.
v4:
- rebase
v3:
- rename macros to REG_BIT() and REG_GENMASK() to avoid underscore
prefix and to be in line with kernel macros (Chris)
- add compile time checks (Mika)
v2:
- rename macros to just _BIT() and _MASK() to reduce verbosity
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/787307c0ba9bc23471e5ff1e454b8af35771fa37.1552657998.git.jani.nikula@intel.com
Chris Wilson [Mon, 18 Mar 2019 09:51:49 +0000 (09:51 +0000)]
drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Chris Wilson [Thu, 14 Mar 2019 07:58:29 +0000 (07:58 +0000)]
drm/i915: Sanity check mmap length against object size
We assumed that vm_mmap() would reject an attempt to mmap past the end of
the filp (our object), but we were wrong.
Applications that tried to use the mmap beyond the end of the object
would be greeted by a SIGBUS. After this patch, those applications will
be told about the error on creating the mmap, rather than at a random
moment on later access.
Reported-by: Antonio Argenziano <antonio.argenziano@intel.com>
Testcase: igt/gem_mmap/bad-size Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk
drm/i915: do not pass dev_priv to low-level forcewake functions
The only usage we have for it is for the regs pointer. Save a pointer to
the set and ack registers instead of the register offsets to remove this
requirement
v2: Keep passing uncore down to the lowest levels to avoid repeated
pointer chasing in the innermost loops:
Ville Syrjälä [Mon, 18 Feb 2019 19:31:37 +0000 (21:31 +0200)]
drm/i915: Split ilk vs. icl csc matrix handling
Split the csc matrix handling to ilk+ and icl+ functions.
This keeps the logic clear on what is loaded into which
CSC unit on the hardware.
We also fix the icl+ code to load the full->limited range
conversion matrix into the output CSC rather than the pipe
CSC which was used on earlier platforms. And we also turn
on the pipe CSC only when the ctm is present.
Ville Syrjälä [Mon, 18 Feb 2019 19:31:36 +0000 (21:31 +0200)]
drm/i915: Clean the csc limited range/identity programming
Just provide precomputed CSC matrices for the identity and
limited range cases. This removes the remaining nuts and bolts
stuff from ilk_load_csc_matrix(), allowing one to actually
see the high level logic.
Ville Syrjälä [Mon, 18 Feb 2019 19:31:34 +0000 (21:31 +0200)]
drm/i915: Clean up ilk/icl pipe/output CSC programming
We have far too much messy duplicated code in the
pipe/output CSC programming. Simply provide two functions
(ilk_update_pipe_csc() and icl_update_output_csc()) to
program the relevant CSC registers. The desired offsets
and coefficients are passed in as parameters.
Lucas De Marchi [Sat, 9 Mar 2019 03:57:27 +0000 (19:57 -0800)]
drm/i915/icl: remove intel_dpll_is_combophy()
This is only used in intel_display() and shouldn't be needed there.
We don't want to keep converting from pll id to pll type so just remove
the function.
Lucas De Marchi [Sat, 9 Mar 2019 03:57:26 +0000 (19:57 -0800)]
drm/i915/icl: split combo and tbt pll funcs
Like was done for MG and combo, now finish the per-type split of the
vfunc by moving TBT out of the combo functions. Now we can completely
remove icl_pll_id_to_enable_reg() since each PLL type passes all the
information via arguments.
Lucas De Marchi [Sat, 9 Mar 2019 03:57:24 +0000 (19:57 -0800)]
drm/i915/icl: split pll enable in three steps
Create separate functions to 1) enable power, 2) write pll config, and
3) enable pll. Doing this it makes it easier to share the functions for
the different PLL types by passing the right arguments.
Lucas De Marchi [Sat, 9 Mar 2019 03:57:23 +0000 (19:57 -0800)]
drm/i915/icl: split combo and mg pll enable
Let's start using the vfuncs to differentiate MG and Combo PLLs. The end
goal is to decouple the type of the PLL from the IDs since the latter
are likely to change from one platform to another. This also makes the
code easier to read by not having lots of if/else chains on leaf
functions.
Chris Wilson [Wed, 13 Mar 2019 16:28:35 +0000 (16:28 +0000)]
drm/i915: Always kick the execlists tasklet after reset
With direct submission being disabled while the reset in progress, we
have a small window where we may forgo the submission of a new request
and not notice its addition during execlists_reset_finish. To close this
window, always schedule the submission tasklet on coming out of reset to
catch any residual work.
Chris Wilson [Thu, 14 Mar 2019 22:38:38 +0000 (22:38 +0000)]
drm/i915/gtt: Rename i915_vm_is_48b to i915_vm_is_4lvl
Large ppGTT are differentiated by the requirement to go to four levels
to address more than 32b. Given the introduction of more 4 level ppGTT
with different sizes of addressable bits, rename i915_vm_is_48b() to
better reflect the commonality of using 4 levels.
Chris Wilson [Thu, 14 Mar 2019 22:38:36 +0000 (22:38 +0000)]
drm/i915: Record platform specific ppGTT size in intel_device_info
As the maximum addressable bits is determined by platform, record that
information in our static chipset tables. This has the advantage of
being clearly recorded in our capability dumps for dmesg, debugfs and
error states.
Chris Wilson [Thu, 14 Mar 2019 22:38:35 +0000 (22:38 +0000)]
drm/i915: Mark up vGPU support for full-ppgtt
For compatibility reasons, we only care if the vGPU host provides
support for full-ppgtt. This is independent of the addressable memory
size, so remove the conflation of 48b from the capability name.
Based on a patch by Bob Paauwe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314223839.28258-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 14 Mar 2019 08:44:32 +0000 (08:44 +0000)]
drm/i915: Refactor to common helpers for prepare/finish between reset & wedge
Since both GPU reset and declaring the device wedged suspend ongoing
driver activity around a hard reset, we can reuse the same code to
reduce the likelihood of forgetting details surrounding reset from
either path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314084432.3740-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 13 Mar 2019 20:59:44 +0000 (20:59 +0000)]
drm/i915/selftests: Disable preemption while setting up fence-timers
The impossible happens and a future fence expired while we were still
initialising. The probable cause is that the test was preempted and we
lost our scheduler cpu slice. Disable preemption during this test to
rule out preemption as a source of timer disruption.
drm/i915/icl+: Always use TPS2 or TPS3 when exiting PSR1
When any other value than EDP_PSR_TP4_TIME_0US is set, TPS1 and TPS4
will be used to do the link training when exiting PSR1.
Happily the eDP panels tested so far was able to sync with source
even without HBR3/TPS4 support but let use the right training
pattern.
TPS4 support was added to PSR1 registers because HBR3/PSR
specification was not closed when ICL was freezed so if HBR3 was
supported by PSR, ICL would already be ready but it was not added to
specification so lets always disable TPS4.
drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time
A new field with the training pattern(TP) wakeup time for PSR2 was
added to VBT, so lets use it when available otherwise it will
fallback to PSR1 wakeup time.
Rodrigo Vivi [Fri, 8 Mar 2019 21:43:00 +0000 (13:43 -0800)]
drm/i915: Start using comparative INTEL_PCH_TYPE
In order to make it easier to bring up new platforms
without having to take care about all corner cases
that was previously taken care for previous platforms
we already use comparative INTEL_GEN statements.
Let's start doing the same with PCH.
The only caveats are:
- less-than comparisons need to be avoided or done with
attention and check > PCH_NONE as well.
- It is not necessarily a chronological order, but a matter
of south display compatibility/inheritance.
v2: Rebased on top of Jani's clean-up which removed the
need for less-than comparison
Rodrigo Vivi [Fri, 8 Mar 2019 21:42:59 +0000 (13:42 -0800)]
drm/i915: Move PCH_NOP to -1
So we can later use PCH >= comparisons. The ultimate goal
is to make it easier for us to introduce a new platform
with south display engine on PCH just by reusing the previous
one.
Rodrigo Vivi [Fri, 8 Mar 2019 21:42:58 +0000 (13:42 -0800)]
drm/i915/gen11+: First assume next platforms will inherit stuff
This exactly same approach was already used from gen9
to gen10 and from gen10 to gen11. Let's also use it
for gen11+.
Let's first assume that we inherit a similar platform
and than we apply the differences on top.
Different from the previous attempts this will be
done this time with coccinelle. We obviously need to
exclude some case that is really exclusive for gen11
like PCH, Firmware, and few others. Luckly this was
easy to filter by selecting the files we are touching
with coccinelle as exposed below:
Thomas Preston [Wed, 6 Mar 2019 20:06:18 +0000 (20:06 +0000)]
drm/i915/bios: assume eDP is present on port A when there is no VBT
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Kevin Strasser [Wed, 13 Mar 2019 00:38:32 +0000 (17:38 -0700)]
drm/i915/icl: Implement half float formats
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use icl_is_hdr_plane too early
v3:
- Use refactored icl_is_hdr_plane (Ville)
- Use u32 instead of uint32_t (Ville)
v6:
- Rebase and fix merge conflicts
- Reorganize switch statements to keep RGB grouped separately from YUV
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-4-git-send-email-kevin.strasser@intel.com
Kevin Strasser [Wed, 13 Mar 2019 00:38:31 +0000 (17:38 -0700)]
drm/i915: Refactor icl_is_hdr_plane
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
v4:
- Rename variables and move a declaration (Ville)
v6:
- Rebase and fix merge conflict
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-3-git-send-email-kevin.strasser@intel.com
Aditya Swarup [Thu, 7 Mar 2019 02:14:12 +0000 (18:14 -0800)]
drm/i915/icl: Fix CRC mismatch error for DP link layer compliance
Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows
to passthrough FB pixels unmodified across pipe. This fixes the failures
for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
(Lineage #1605353570)
v2: This is also needed to fix failing IGT test case kms_cursor_crc on
ICL.(Mika Kahola)
Make macros consistent with i915_reg.h comments.(Jani Nikula)
Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190307021412.18626-1-aditya.swarup@intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=103232
Chris Wilson [Sat, 9 Mar 2019 16:02:50 +0000 (16:02 +0000)]
drm/i915: Introduce a context barrier callback
In the next patch, we will want to update live state within a context.
As this state may be in use by the GPU and we haven't been explicitly
tracking its activity, we instead attach it to a request we send down
the context setup with its new state and on retiring that request
cleanup the old state as we then know that it is no longer live.
Chris Wilson [Fri, 8 Mar 2019 13:45:12 +0000 (13:45 +0000)]
drm/i915: Suppress the "Failed to idle" warning for gem_eio
It is debatable whether having an error message on suspend for forcibly
cancelling outstanding work is worthwhile. We want to know if it occurs
in the wild (as we will then have to reconsider the approach!), but
equally is not fatal across suspend, as upon resume we automatically
clear the wedged status.
However, CI does trigger this scenario with gem_eio/suspend; as there we
are intentionally wedging the device upon suspend. The dilemma is how
not to trigger a failure report for the dmesg spam, for which the
quickest response is to suppress the warning in the kernel. I'd rather
mark it as accepted in gem_eio, but for now detecting when gem_eio is
playing games and cancelling the warning for that case seems a barely
acceptable hack.
The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.
If PSR1 is active when pipe CRC is enabled the CRC calculations will
be inhibit by the transition to low power states that PSR1 brings.
So lets force a PSR1 exit and as soon as pipe CRC is enabled it will
block PSR1 activation and avoid CRC timeouts when running IGT tests.
There is a little window between the call to force exit PSR and the
write to pipe CRC registers that needs to happen within the minimum
of 6 idles frames otherwise PSR1 will be active again causing the CRC
timeouts but anyways this will at least reduce the occurrence of CRC
timeouts.
This can possibily fix issues present right now but I did not found
any open, I mostly got this issue from previous CI runs of this
series, bellow some exambles:
When PSR2 is active aka after the number of frames programmed in
PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
interrupts causing IGT tests to fail due timeout.
This same behavior don't happen with PSR1, as soon as pipe CRC is
enabled it blocks PSR1 activation so CRC calculation continues to
happens normaly.
This patch also set mode_changed as true when PSR is available to
force atomic check functions to compute new PSR state, otherwise PSR2
would not be disabled.
v4: Only setting mode_changed if has_psr is set(Dhinakaran)
v3: Reusing intel_crtc_crc_prepare() and crc_enabled, only setting
mode_changed if it can do PSR.
v2: Changed commit description to describe that PSR2 inhibit CRC
calculations.
Other features like PSR2 also needs to be disabled while getting CRC
so lets rename ips_force_disable to crc_enabled, drop all this checks
for pipe A and HSW and BDW and make it generic and
hsw_compute_ips_config() will take care of all the checks removed
from here.
v2: Renaming and parameter changes to the functions that prepares the
commit (Ville)
drm/i915: Compute and commit color features in fastsets
In any commit, intel_modeset_pipe_config() will initialilly clear
and then recalculate most of the pipe states but it leave intel
specific color features states in reset state.
If after intel_pipe_config_compare() is detected that a fastset is
possible it will mark update_pipe as true and unsed mode_changed,
causing the color features state to be kept in reset state and then
latter being committed to hardware disabling the color features.
This issue can be reproduced by any code patch that duplicates the
actual(with color features already enabled) state and only mark
mode_changed as true.
drm/i915/psr: Only lookup for enabled CRTCs when forcing a fastset
Forcing a specific CRTC to the eDP connector was causing the
intel_psr_fastset_force() to mark mode_chaged in the wrong and
disabled CRTC causing no update in the PSR state.
Looks like our internal state track do not clear output_types and
has_psr in the disabled CRTCs, not sure if this is the expected
behavior or not but in the mean time this fix the issue.
Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.
Chris Wilson [Fri, 8 Mar 2019 13:25:22 +0000 (13:25 +0000)]
drm/i915: Introduce intel_context.pin_mutex for pin management
Introduce a mutex to start locking the HW contexts independently of
struct_mutex, with a view to reducing the coarse struct_mutex. The
intel_context.pin_mutex is used to guard the transition to and from being
pinned on the gpu, and so is required before starting to build any
request. The intel_context will then remain pinned until the request
completes, but the mutex can be released immediately unpin completion of
pinning the context.
A slight variant of the above is used by per-context sseu that wants to
inspect the pinned status of the context, and requires that it remains
stable (either !pinned or pinned) across its operation. By using the
pin_mutex to serialise operations while pin_count==0, we can take that
pin_mutex for stabilise the boolean pin status.
v2: for Tvrtko!
* Improved commit message.
* Dropped _gpu suffix from gen8_modify_rpcs_gpu.
v3: Repair the locking for sseu selftests
Chris Wilson [Fri, 8 Mar 2019 13:25:21 +0000 (13:25 +0000)]
drm/i915: Track the pinned kernel contexts on each engine
Each engine acquires a pin on the kernel contexts (normal and preempt)
so that the logical state is always available on demand. Keep track of
each engines pin by storing the returned pointer on the engine for quick
access.
Chris Wilson [Fri, 8 Mar 2019 13:25:20 +0000 (13:25 +0000)]
drm/i915: Make context pinning part of intel_context_ops
Push the intel_context pin callback down from intel_engine_cs onto the
context itself by virtue of having a central caller for
intel_context_pin() being able to lookup the intel_context itself.
Chris Wilson [Fri, 8 Mar 2019 13:25:19 +0000 (13:25 +0000)]
drm/i915: Move over to intel_context_lookup()
In preparation for an ever growing number of engines and so ever
increasing static array of HW contexts within the GEM context, move the
array over to an rbtree, allocated upon first use.
Unfortunately, this imposes an rbtree lookup at a few frequent callsites,
but we should be able to mitigate those by moving over to using the HW
context as our primary type and so only incur the lookup on the boundary
with the user GEM context and engines.
v2: Check for no HW context in guc_stage_desc_init
Chris Wilson [Fri, 8 Mar 2019 13:25:18 +0000 (13:25 +0000)]
drm/i915: Store the intel_context_ops in the intel_engine_cs
If we place a pointer to the engine specific intel_context_ops in the
engine itself, we can assign the ops pointer on initialising the
context, and then rely on it being set. This simplifies the code in
later patches.
Chris Wilson [Fri, 8 Mar 2019 13:25:17 +0000 (13:25 +0000)]
drm/i915: Split struct intel_context definition to its own header
This complex struct pulling in half the driver deserves its own
isolation in preparation for intel_context becoming an outright
complicated class of its own.
In order to split this beast into its own header also requests splitting
several of its dependent types and their dependencies into their own
headers as well.
Chris Wilson [Fri, 8 Mar 2019 13:25:16 +0000 (13:25 +0000)]
drm/i915: Track active engines within a context
For use in the next patch, if we track which engines have been used by
the HW, we can reduce the work required to flush our state off the HW to
those engines.
Jani Nikula [Tue, 5 Mar 2019 13:52:15 +0000 (15:52 +0200)]
drm/i915/dp: use single point of truth for PPS divisor register
Set pp_div field of struct pps_registers to INVALID_MMIO_REG when the
register isn't there, and use i915_mmio_reg_valid() instead of repeating
the condition all over the place.
Use INVALID_MMIO_REG explicitly for documentation purposes, even if the
value is unchanged from 0.
Jani Nikula [Tue, 5 Mar 2019 13:52:14 +0000 (15:52 +0200)]
drm/i915/dp: deconflate PPS unlock from divisor register
PPS locking is a thing on pre-DDI, up to and including CPT and PPT.
The PPS divisor register exists up to gen 9 BC, replaced by a field in
the control register starting from gen 9 LP, i.e. BXT, GLK, and CNP on.
Commit b0a08bec9631 ("drm/i915/bxt: eDP Panel Power sequencing") stopped
using the divisor register, but inadvertently conflated the PPS unlock
in the change. No longer doing the unlocking was the right thing to do,
however we should've stopped already at LPT (or DDI platforms).
Deconflate the two.
Arguably this could be moved away from here altogether, but this is the
minimally intrusive change for now.
Chris Wilson [Fri, 8 Mar 2019 09:36:57 +0000 (09:36 +0000)]
drm/i915: Remove has-kernel-context
We can no longer assume execution ordering, and in particular we cannot
assume which context will execute last. One side-effect of this is that
we cannot determine if the kernel-context is resident on the GPU, so
remove the routines that claimed to do so.
Chris Wilson [Fri, 8 Mar 2019 09:36:56 +0000 (09:36 +0000)]
drm/i915: Reduce presumption of request ordering for barriers
Currently we assume that we know the order in which requests run and so
can determine if we need to reissue a switch-to-kernel-context prior to
idling. That assumption does not hold for the future, so instead of
tracking which barriers have been used, simply determine if we have ever
switched away from the kernel context by using the engine and before
idling ensure that all engines that have been used since the last idle
are synchronously switched back to the kernel context for safety (and
else of shrinking memory while idle).
Chris Wilson [Fri, 8 Mar 2019 09:36:55 +0000 (09:36 +0000)]
drm/i915: Refactor common code to load initial power context
We load a context (the kernel context) on both module load and resume in
order to initialise some logical state onto the GPU. We can use the same
routine for both operations, which will become more useful as we
refactor rc6/rps enabling.
Chris Wilson [Fri, 8 Mar 2019 09:36:54 +0000 (09:36 +0000)]
drm/i915: Do a synchronous switch-to-kernel-context on idling
When the system idles, we switch to the kernel context as a defensive
measure (no users are harmed if the kernel context is lost). Currently,
we issue a switch to kernel context and then come back later to see if
the kernel context is still current and the system is idle. However,
if we are no longer privy to the runqueue ordering, then we have to
relax our assumptions about the logical state of the GPU and the only
way to ensure that the kernel context is currently loaded is by issuing
a request to run after all others, and wait for it to complete all while
preventing anyone else from issuing their own requests.
v2: Pull wedging into switch_to_kernel_context_sync() but only after
waiting (though only for the same short delay) for the active context to
finish.
Imre Deak [Thu, 7 Mar 2019 10:32:35 +0000 (12:32 +0200)]
drm/i915/icl: Prevent incorrect DBuf enabling
Pretend that we have only 1 DBuf slice and that 1 slice is always
enabled, until we have a proper way for on-demand toggling of the second
slice. Currently we'll try to incorrectly enable DBuf even when all
pipes are disabled and we are already runtime suspended (as the computed
number of DBuf slices will be 1 in that case).
This also means we'll leave the second slice enabled redundantly (except
when suspended), but that's an acceptable tradeoff until we have a
proper solution.
Ville Syrjälä [Wed, 6 Mar 2019 20:35:44 +0000 (22:35 +0200)]
drm/i915: Fix DRAM size reporting for BXT
The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.
v2: Deobfuscate the math (Chris)
s/GB/GBIT/ in the register bit definitions (Jani)
Ville Syrjälä [Wed, 6 Mar 2019 20:35:42 +0000 (22:35 +0200)]
drm/i915: Polish skl_is_16gb_dimm()
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.
Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.
Now with the watermarks fixes merged, Icelake is stable enough to
have the alpha support protection flag removed.
We have a few ICL 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.alpha_support 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.
Specifically, alpha support says nothing about the development
state of the hardware, and everything about the state of the
driver in a kernel release.
This is semantically no different from the old
preliminary_hw_support flag, but the old one was all too often
interpreted as (preliminary hw) support instead of the intended
(preliminary) hw support, and it was misleading for everyone.
Hence the rename.
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-y.html
Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-iclb.html Cc: James Ausmus <james.ausmus@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190305221153.359-1-jose.souza@intel.com
Chris Wilson [Thu, 7 Mar 2019 10:45:30 +0000 (10:45 +0000)]
drm/i915: Force GPU idle on suspend
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manually do so ourselves. The
advantage is that we can apply more pressure!
As we now perform a GPU reset to clean up any residual kernels, we leave
the GPU in an unknown state and in particular can not talk to the GuC
before we reinitialise it following resume. For example, we no longer
need to tell the GuC to suspend itself, as it is already reset.
Chris Wilson [Thu, 7 Mar 2019 10:45:29 +0000 (10:45 +0000)]
drm/i915: Make I915_GEM_IDLE_TIMEOUT into a macro
Currently we use HZ/5 for detecting a dead gpu on startup, and we will
wish to reuse this value for detecting a dead gpu on suspend, so convert
it into a macro for later convenience.
projects / mirror_ubuntu-jammy-kernel.git / log