Commit Graph

23588 Commits

Author SHA1 Message Date
Pankaj Bharadiya
7bda10095a drm/i915/i915_drv: Prefer drm_WARN_ON over WARN_ON
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN_ON over WARN_ON.

changes since v1:
- Add parentheses around the dev_priv macro argument (Jani)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-7-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:27 +03:00
Pankaj Bharadiya
6db20e27f6 drm/i915/gem: Prefer drm_WARN* over WARN*
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN* over WARN* at places where struct drm_device pointer
can be extracted.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-6-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:23 +03:00
Pankaj Bharadiya
ef3929b64b drm/i915/display/tc: Prefer drm_WARN_ON over WARN_ON
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN_ON over WARN_ON.

Conversion is done with below sementic patch:

@@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
...+>
}

@@
identifier func, T;
@@
func(struct intel_digital_port *T,...) {
+struct drm_i915_private *i915 = to_i915(T->base.base.dev);
<+...
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
...+>

}

changes since v1:
- Add i915 local variable and use it in drm_WARN_ON (Jani)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-5-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:20 +03:00
Pankaj Bharadiya
cb7cbb4b2a drm/i915/display/sdvo: Prefer drm_WARN* over WARN*
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN* over WARN* calls.

changes since v1:
- Added dev_priv local variable and used it in drm_WARN* calls (Jani)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-4-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:16 +03:00
Pankaj Bharadiya
4f36048219 drm/i915/display/dp: Prefer drm_WARN* over WARN*
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN* over WARN* at places where struct intel_dp or struct
drm_i915_private pointer is available.

Conversion is done with below sementic patch:

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule3@
identifier func, T;
@@
func(struct intel_dp *T,...) {
+ struct drm_i915_private *i915 = dp_to_i915(T);
<+...
(
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}

@rule4@
identifier func, T;
@@
func(...) {
...
struct intel_dp *T = ...;
+ struct drm_i915_private *i915 = dp_to_i915(T);
<+...
(
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-3-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:12 +03:00
Pankaj Bharadiya
4c1ccdf721 drm/i915/display/display_power: Prefer drm_WARN_ON over WARN_ON
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.

Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains
struct is available.

Conversion is done with below sementic patch:

@@
identifier func, T;
@@
func(struct i915_power_domains *T,...) {
+ struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, power_domains);
<+...
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
...+>

}

changes since v1:
- Fix commit subject (Jani)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-2-pankaj.laxminarayan.bharadiya@intel.com
2020-05-19 16:01:07 +03:00
Imre Deak
ae9b6cfe13 drm/i915: Fix AUX power domain toggling across TypeC mode resets
Make sure to select the port's AUX power domain while holding the TC
port lock. The domain depends on the port's current TC mode, which may
get changed under us if we're not holding the lock.

This was left out from
commit 8c10e22626 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers")

Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514204553.27193-1-imre.deak@intel.com
2020-05-19 14:19:22 +03:00
Ville Syrjälä
488e017904 drm/i915: Read out hrawclk on all gen3+ platforms
I've checked a bunch of gen3/4 machines and all seem to have
consistent FSB frequency information in the CLKCFG register.
So let's read out hrawclk on all gen3+ machines. Although
apart from g4x/pnv aux/pps dividers we only really need this
for for i965g/gm cs timestamp increment.

The CLKCFG memory clock values seem less consistent but we
don't care about those here.

For posterity here's a list of CLKCFG vs. FSB dumps from
a bunch of machines (only missing lpt for a full set):
machine CLKCFG     FSB
alv1    0x00001411 533
alv2    0x00000420 400 (Chris)
gdg1    0x20000022 800
gdg2    0x20000022 800
cst     0x00010043 666
blb     0x00002034 1333
pnv1    0x00000423 666
pnv2    0x00000433 666
965gm   0x00004342 800
946gz   0x00000022 800
965g    0x00000422 800
g35     0x00000430 1066
        0x00000434 1333
ctg1    0x00644056 1066
ctg2    0x00644066 1066
elk1    0x00012420 1066
        0x00012424 1333
        0x00012436 1600
        0x00012422 800
elk2    0x00012040 1066

For the mobile parts the chipset docs generally have these
documented to some degree (alv being the exception).

The two settings w/o any evidence are 0x5=400MHz on desktop
and 0x7=1333MHz on mobile. Though the mobile 1333MHz case
probably doesn't even exist since ctg is only documented
to go up to 1066MHz.

v2: Fix 400mhz readout for Chris's alv/celeron machine
    Do a clean mobile vs. dekstop split since that's really
    what seems to be going on

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-3-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-19 12:10:26 +03:00
Ville Syrjälä
42ab330530 drm/i915: Document our lackluster FSB frequency readout
Document the fact that we aren't reading out the actual FSB
frequency but rather just the state of the FSB straps.
Some BIOSen allow you to configure the two independently.
So if someone sets the two up in an inconsistent manner
we'll get the wrong answer here and thus will end up with
incorrect aux/pps clock dividers. Alas, proper docs are no
longer around so we can't do any better.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-19 12:08:20 +03:00
Ville Syrjälä
6f62bda1ea drm/i915: Fix 400 MHz FSB readout on elk
Looks like elk redefines some of the CLKCFG FSB values to
make room for 400 MHz FSB. The setting overlaps with one of
the 266MHz settings (which is even documented in the ctg docs,
and cofirmed to be correct on my ctg). So we limit the special
case to elk only.

Though it might also be that we have some kind of desktop vs.
mobile difference going on here as eg. both g35 and elk
use 0x0 for the 266 MHz setting, vs. 0x6 used by ctg). The
g35 doesn't let me select 400MHz for the FSB strap so can't
confirm which way it would go here. But anyways as it seems
only elk has the 400MHz option we shouldn't lose anything
by limiting the special case to it alone.

My earlier experiments on this appear to have been nonsense as
the comment I added claims that FSB strap of 400MHz results in
a value of 0x4, but I've now retested it and I definitely get a
value of 0x6 instead. So let's remove that bogus comment.

v2: s/_ELK/_ALT/ in the define in anticipation of a full
    mobile vs. desktop CLKCFG split

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-1-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-19 12:06:55 +03:00
Chris Wilson
cba597ac45 drm/i915/display: Return error from dbuf allocation failure
drivers/gpu/drm/i915/intel_pm.c:5920 skl_ddb_add_affected_pipes() error: uninitialized symbol 'ret'.

Fixes: 3cf43cdc63 ("drm/i915: Introduce proper dbuf state")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516190940.12675-1-chris@chris-wilson.co.uk
2020-05-18 20:54:20 +03:00
Ville Syrjälä
b6a13a386e drm/i915: Fix dbuf slice mask when turning off all the pipes
The current dbuf slice computation only happens when there are
active pipes. If we are turning off all the pipes we just leave
the dbuf slice mask at it's previous value, which may be something
other that BIT(S1). If runtime PM will kick in it will however
turn off everything but S1. Then on the next atomic commit (if
the new dbuf slice mask matches the stale value we left behind)
the code will not turn on the other slices we now need. This will
lead to underruns as the planes are trying to use a dbuf slice
that's not powered up.

To work around let's just just explicitly set the dbuf slice mask
to BIT(S1) when we are turning off all the pipes. Really the code
should just calculate this stuff the same way regardless whether
the pipes are on or off, but we're not quite there yet (need a
bit more work on the dbuf state for that).

v2: Let's not put the fix into dead code

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 3cf43cdc63 ("drm/i915: Introduce proper dbuf state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518121354.20401-1-ville.syrjala@linux.intel.com
2020-05-18 20:53:19 +03:00
Chris Wilson
f5f7e790a5 drm/i915/gt: Reuse the tasklet priority for virtual as their siblings
In order to keep all the tasklets in the same execution lists and so
fifo ordered, be consistent and use the same priority for all.

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/20200518081440.17948-3-chris@chris-wilson.co.uk
2020-05-18 17:39:54 +01:00
Chris Wilson
67a64e51ba drm/i915/selftests: Refactor sibling selection
Tvrtko spotted that some selftests were using 'break' not 'continue',
which will fail for discontiguous engine layouts such as on Icelake
(which may have vcs0 and vcs2).

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518102911.3463-1-chris@chris-wilson.co.uk
2020-05-18 14:41:47 +01:00
Nathan Chancellor
993fa32eb3 drm/i915: Mark check_shadow_context_ppgtt as maybe unused
When CONFIG_DRM_I915_DEBUG_GEM is not set, clang warns:

drivers/gpu/drm/i915/gvt/scheduler.c:884:1: warning: function
'check_shadow_context_ppgtt' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
check_shadow_context_ppgtt(struct execlist_ring_context *c, struct
intel_vgpu_mm *m)
^
1 warning generated.

This warning is similar to -Wunused-function but rather than warning
that the function is completely unused, it warns that it is used in some
expression within the file but that expression will be evaluated to a
constant or be optimized away in the final assembly, essentially making
it appeared used but really isn't. Usually, this happens when a function
or variable is only used in sizeof, where it will appear to be used but
will be evaluated at compile time and not be required to be emitted.

In this case, the function is only used in GEM_BUG_ON, which is defined
as BUILD_BUG_ON_INVALID, which intentionally follows this pattern. To
fix this warning, add __maybe_unused to make it clear that this is
intentional depending on the configuration.

Fixes: bec3df930f ("drm/i915/gvt: Support PPGTT table load command")
Link: https://github.com/ClangBuiltLinux/linux/issues/1027
Signed-off-by: Nathan Chancellor <natechancellor@gmail.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/20200516023545.3332334-1-natechancellor@gmail.com
2020-05-16 13:41:04 +01:00
Chris Wilson
552e01f663 drm/i915/gem: Retry faulthandlers on ENOSPC
As we no longer use the shmemfs allocation directly, we do not expect to
receive -ENOSPC from a backing store allocation. The potential sources
for -ENOSPC are then our own internal eviction code, so the choice is
either to kill the potential application with SIGBUS or to retry the
faulthandler.

In this patch we retry the fault handler, but since this is a should
never happen condition, it is arguable that we gather up copious debug
and kill the application. At worst, we cause an interruptible busy-wait,
stalling the application -- all causes should be transient and the
system should eventually recover. A small stall is hopefully a better
outcome than random oomkiller.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515200031.12034-1-chris@chris-wilson.co.uk
2020-05-16 10:37:20 +01:00
Ville Syrjälä
70b1a26f29 drm/i915: Clean up dbuf debugs during .atomic_check()
Combine the two per-pipe dbuf debugs into one, and use the canonical
[CRTC:%d:%s] style to identify the crtc. Also use the same style as
the plane code uses for the ddb start/end, and prefix bitmask properly
with 0x to make it clear they are in fact bitmasks.

The "how many total slices we are going to use" debug we move to
outside the crtc loop so it gets printed only once at the end.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-12-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
c7c0e7ebe4 drm/i915: Move the dbuf pre/post plane update
Encapsulate the dbuf state more by moving the pre/post
plane functions out from intel_display.c. We stick them
into intel_pm.c since that's where the rest of the code
lives for now.

Eventually we should add a new file for this stuff at which
point we also need to decide if it makes sense to even split
the wm code from the ddb code, or to keep them together.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-11-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
0cde0e0ff5 drm/i915: Nuke skl_ddb_get_hw_state()
skl_ddb_get_hw_state() is redundant and kinda called in thw wrong
spot anyway. Just kill it.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-10-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
3cf43cdc63 drm/i915: Introduce proper dbuf state
Add a global state to track the dbuf slices. Gets rid of all the nasty
coupling between state->modeset and dbuf recomputation. Also we can now
totally nuke state->active_pipe_changes.

dev_priv->wm.distrust_bios_wm still remains, but that too will get
nuked soon.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-9-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
56f48c1d44 drm/i915: Unify the low level dbuf code
The low level dbuf slice code is rather inconsitent with its
functiona naming and organization. Make it more consistent.

Also share the enable/disable functions between all platforms
since the same code works just fine for all of them.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-8-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
b3f1ff5b5b drm/i915: Polish some dbuf debugs
Polish some of the dbuf code to give more meaningful debug
messages and whatnot. Also we can switch over to the per-device
debugs/warns at the same time.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-7-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Ville Syrjälä
2f9078c34c drm/i915: Make skl_compute_dbuf_slices() behave consistently for all platforms
Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe on
icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's active or
not). Let's make the behaviour consistent and always return 0 for any
inactive pipe.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-6-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2020-05-16 00:16:46 +03:00
Arnd Bergmann
794bdcf71f drm/i915: avoid unused scale_user_to_hw() warning
After the function is no longer marked 'inline', there
is now a new warning pointing out that the only caller
is inside of an #ifdef:

drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning: 'scale_user_to_hw' defined but not used [-Wunused-function]
  493 | static u32 scale_user_to_hw(struct intel_connector *connector,
      |            ^~~~~~~~~~~~~~~~

Move the function itself into that #ifdef as well.

Fixes: 81b55ef1f4 ("drm/i915: drop a bunch of superfluous inlines")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428213106.3139170-1-arnd@arndb.de
2020-05-15 21:34:51 +01:00
Ville Syrjälä
963f328b9c drm/i915: Protect overlay colorkey macro arguments
Put the customary () around the macro argument in the overlay
colorkey macros. And while at switch to using a consistent
case for the hex constants.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-6-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-15 20:12:56 +03:00
Ville Syrjälä
7cd0f22019 drm/i915: Enable pipe gamma for the overlay
We pass the plane data through the pipe gamma for all the other
planes. Can't see why we should treat the overlay differently,
so let's enable pipe gamma for it as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-5-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-15 20:12:08 +03:00
Ville Syrjälä
e0b5d48e55 drm/i915: Configure overlay cc_out precision based on crtc gamma config
Put the overlay color conversion unit into 10bit mode if the
pipe isn't using the 8bit legacy gamma. Not 100% sure this is
what the intention of the bit was but makes at least some sense to
me.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-4-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-15 20:11:17 +03:00
Ville Syrjälä
0e12b4e31f drm/i915: Fix overlay colorkey for 30bpp and 8bpp
As with the video sprites the colorkey is always specified
as 8bpc. For 10bpc primary plane formats we just ignore the
two lsbs of each component. For C8 we'll replicate the same
key to each chanel, which is what the hardware wants.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-15 20:08:56 +03:00
Ville Syrjälä
5e9e0a3a3b drm/i915: Fix max cursor size for i915g/gm
Apparently the 128x128 and 256x256 ARGB cursor modes were
only added on LPT/CST.

While the display section of bspec isn't super clear on the
subject, it does highlight these two modes in a different
color, has a few changlog entries indicating the 256x256 mode
was added for a LPT DCN, and that the 128x128 mode was also
added later (though no DCN/platform note there).

The "device dependencies" bspec section does list the 256x256x32
as a new feature for LPT/CST, and goes on to mention that current
hw only has the 64x64x32 mode (which reinforces the notion that
the 128x128 mode was also added at the same time).

Testing on actual hardware confirms all of this. CI shows all
the 128x128 and 256x256 tests failing on GDG, and my ALV
definitely doesn't like them.

So we shall limit GDG/ALV to 64x64 only. And while at it
let's adjust the mobile gen2 case to list the two platforms
explicitly so that the if-ladder looks reasonably uniform.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-2-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-15 20:07:21 +03:00
Joonas Lahtinen
3a36aa237e drm/i915: Update DRIVER_DATE to 20200515
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-05-15 14:49:24 +03:00
Ville Syrjälä
802a5820fc drm/i915: Extract i915_cs_timestamp_{ns_to_ticks,tick_to_ns}()
Pull the code to do the CS timestamp ns<->ticks conversion into
helpers and use them all over.

The check in i915_perf_noa_delay_set() seems a bit dubious,
so we switch it to do what I assume it wanted to do all along
(ie. make sure the resulting delay in CS timestamp ticks
doesn't exceed 32bits)?

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302143943.32676-5-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-14 20:04:02 +03:00
Ville Syrjälä
56f1b31f1d drm/i915: Store CS timestamp frequency in Hz
kHz isn't accurate enough for storing the CS timestamp
frequency on some of the platforms. Store the value
in Hz instead.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302143943.32676-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
2020-05-14 19:59:53 +03:00
Ville Syrjälä
2e2701582a drm/i915: Nuke pointless div by 64bit
Bunch of places use a 64bit divisor needlessly. Switch
to 32bit divisor.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302143943.32676-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-05-14 19:58:11 +03:00
Stanislav Lisovskiy
8ca6d0237d drm/i915: Enable SAGV support for Gen12
Flip the switch and enable SAGV support
for Gen12 also.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514074853.9508-4-stanislav.lisovskiy@intel.com
2020-05-14 19:08:30 +03:00
Stanislav Lisovskiy
20f505f225 drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.

Currently we are just comparing against all of
those and take minimum(worst case).

v2: Fixed wrong PCode reply mask, removed hardcoded
    values.

v3: Forbid simultaneous legacy SAGV PCode requests and
    restricting qgv points. Put the actual restriction
    to commit function, added serialization(thanks to Ville)
    to prevent commit being applied out of order in case of
    nonblocking and/or nomodeset commits.

v4:
    - Minor code refactoring, fixed few typos(thanks to James Ausmus)
    - Change the naming of qgv point
      masking/unmasking functions(James Ausmus).
    - Simplify the masking/unmasking operation itself,
      as we don't need to mask only single point per request(James Ausmus)
    - Reject and stick to highest bandwidth point if SAGV
      can't be enabled(BSpec)

v5:
    - Add new mailbox reply codes, which seems to happen during boot
      time for TGL and indicate that QGV setting is not yet available.

v6:
    - Increase number of supported QGV points to be in sync with BSpec.

v7: - Rebased and resolved conflict to fix build failure.
    - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus)

v8: - Don't report an error if we can't restrict qgv points, as SAGV
      can be disabled by BIOS, which is completely legal. So don't
      make CI panic. Instead if we detect that there is only 1 QGV
      point accessible just analyze if we can fit the required bandwidth
      requirements, but no need in restricting.

v9: - Fix wrong QGV transition if we have 0 planes and no SAGV
      simultaneously.

v10: - Fix CDCLK corruption, because of global state getting serialized
       without modeset, which caused copying of non-calculated cdclk
       to be copied to dev_priv(thanks to Ville for the hint).

v11: - Remove unneeded headers and spaces(Matthew Roper)
     - Remove unneeded intel_qgv_info qi struct from bw check and zero
       out the needed one(Matthew Roper)
     - Changed QGV error message to have more clear meaning(Matthew Roper)
     - Use state->modeset_set instead of any_ms(Matthew Roper)
     - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used
     - Keep using crtc_state->hw.active instead of .enable(Matthew Roper)
     - Moved unrelated changes to other patch(using latency as parameter
       for plane wm calculation, moved to SAGV refactoring patch)

v12: - Fix rebase conflict with own temporary SAGV/QGV fix.
     - Remove unnecessary mask being zero check when unmasking
       qgv points as this is completely legal(Matt Roper)
     - Check if we are setting the same mask as already being set
       in hardware to prevent error from PCode.
     - Fix error message when restricting/unrestricting qgv points
       to "mask/unmask" which sounds more accurate(Matt Roper)
     - Move sagv status setting to icl_get_bw_info from atomic check
       as this should be calculated only once.(Matt Roper)
     - Edited comments for the case when we can't enable SAGV and
       use only 1 QGV point with highest bandwidth to be more
       understandable.(Matt Roper)

v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä)
     - Changed comment for zero new_mask in qgv points masking function
       to better reflect reality(Ville Syrjälä)
     - Simplified bit mask operation in qgv points masking function
       (Ville Syrjälä)
     - Moved intel_qgv_points_mask closer to gen11 SAGV disabling,
       however this still can't be under modeset condition(Ville Syrjälä)
     - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask
       (Ville Syrjälä)
     - Extracted PCode changes to separate patch.(Ville Syrjälä)
     - Now treat num_planes 0 same as 1 to avoid confusion and
       returning max_bw as 0, which would prevent choosing QGV
       point having max bandwidth in case if SAGV is not allowed,
       as per BSpec(Ville Syrjälä)
     - Do the actual qgv_points_mask swap in the same place as
       all other global state parts like cdclk are swapped.
       In the next patch, this all will be moved to bw state as
       global state, once new global state patch series from Ville
       lands

v14: - Now using global state to serialize access to qgv points
     - Added global state locking back, otherwise we seem to read
       bw state in a wrong way.

v15: - Added TODO comment for near atomic global state locking in
       bw code.

v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed
       with Jani Nikula.
     - Take bw_state_changed flag into use.

v17: - Moved qgv point related manipulations next to SAGV code, as
       those are semantically related(Ville Syrjälä)
     - Renamed those into intel_sagv_(pre)|(post)_plane_update
       (Ville Syrjälä)

v18: - Move sagv related calls from commit tail into
       intel_sagv_(pre)|(post)_plane_update(Ville Syrjälä)

v19: - Use intel_atomic_get_bw_(old)|(new)_state which is intended
       for commit tail stage.

v20: - Return max bandwidth for 0 planes(Ville)
     - Constify old_bw_state in bw_atomic_check(Ville)
     - Removed some debugs(Ville)
     - Added data rate to debug print when no QGV points(Ville)
     - Removed some comments(Ville)

v21, v22, v23: - Fixed rebase conflict

v24: - Changed PCode mask to use ICL_ prefix
v25: - Resolved rebase conflict

v26: - Removed redundant NULL checks(Ville)
     - Removed redundant error prints(Ville)

v27: - Use device specific drm_err(Ville)
     - Fixed parenthesis ident reported by checkpatch
       Line over 100 warns to be fixed together with
       existing code style.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
[vsyrjala: Drop duplicate intel_sagv_{pre,post}_plane_update() prototypes
           and drop unused NUM_SAGV_POINTS define]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514074853.9508-3-stanislav.lisovskiy@intel.com
2020-05-14 19:08:30 +03:00
Stanislav Lisovskiy
7241c57d31 drm/i915: Add TGL+ SAGV support
Starting from TGL we need to have a separate wm0
values for SAGV and non-SAGV which affects
how calculations are done.

v2: Remove long lines
v3: Removed COLOR_PLANE enum references
v4, v5, v6: Fixed rebase conflict
v7: - Removed skl_plane_wm_level accessor from skl_allocate_pipe_ddb(Ville)
    - Removed sagv_uv_wm0(Ville)
    - can_sagv->use_sagv_wm(Ville)

v8: - Moved tgl_crtc_can_enable_sagv function up(Ville)
    - Changed comment regarding pipe_wm usage(Ville)
    - Call intel_can_enable_sagv and tgl_compute_sagv_wm only
      for Gen12(Ville)
    - Some sagv debugs removed(Ville)
    - skl_print_wm_changes improvements(Ville)
    - Do assignment instead of memcpy in
      skl_pipe_wm_get_hw_state(Ville)

v9: - Removed can_sagv variable(Ville)
    - Removed spurious line(Ville)
    - Changed u32 to unsigned int as agreed(Ville)
    - Assign sagv only for gen12 in
      skl_pipe_wm_get_hw_state(Ville)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Remove the dead 'return false' from intel_crtc_can_enable_sagv()]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514074853.9508-2-stanislav.lisovskiy@intel.com
2020-05-14 19:08:30 +03:00
Joonas Lahtinen
1be8f347d7 Merge tag 'gvt-next-2020-05-12' of https://github.com/intel/gvt-linux into drm-intel-next-queued
gvt-next-2020-05-12

- Support PPGTT update via LRI cmd (Zhenyu)
- Remove extra kmap for shadow ctx update (Zhenyu)
- Move workload cleanup out of execlist handling code (Zhenyu)

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200512094017.GX18545@zhen-hp.sh.intel.com
2020-05-14 18:02:23 +03:00
Gwan-gyeong Mun
7a00e68b43 drm/i915/psr: Use new DP VSC SDP compute routine on PSR
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.

In order to calculate colorimetry information, intel_psr_update()
function and intel_psr_enable() function extend a drm_connector_state
argument.

There are no changes to PSR mechanism.

v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Rebased
v8: Rebased
v10: When a PSR is enabled, it needs to add DP_SDP_VSC to
     infoframes.enable.
     It is needed for comparing between HW and pipe_state of VSC_SDP.
v11: If PSR is disabled by flag, it don't enable psr on pipe compute.
v12: Fix an inconsistent indenting

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-15-gwan-gyeong.mun@intel.com
2020-05-14 13:54:17 +03:00
Gwan-gyeong Mun
cafac5a983 drm/i915/dp: Add compute routine for DP PSR VSC SDP
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VSC SDP.

v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: 1) Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is
        not supported.
     2) Change a checking of PSR state.

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-14-gwan-gyeong.mun@intel.com
2020-05-14 13:54:15 +03:00
Gwan-gyeong Mun
fa37a21327 drm/i915: Stop sending DP SDPs on ddi disable
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.

v5: Polish commit message [Uma]

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-13-gwan-gyeong.mun@intel.com
2020-05-14 13:54:13 +03:00
Gwan-gyeong Mun
76d45d0665 drm/i915: Program DP SDPs on pipe updates
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-12-gwan-gyeong.mun@intel.com
2020-05-14 13:54:10 +03:00
Gwan-gyeong Mun
ce58867ee1 drm/i915: Fix enabled infoframe states of lspcon
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.

Because the current implementation of lspcon is not ready to support
readout infoframes, we need to return 0 here.

In order to support readout to lspcon, we need to implement read_infoframe
and infoframes_enabled. And set_infoframes also have to set an appropriate
bit on crtc_state->infoframes.enable

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-11-gwan-gyeong.mun@intel.com
2020-05-14 13:54:08 +03:00
Gwan-gyeong Mun
2c3928e4d8 drm/i915: Add state readout for DP VSC SDP
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.

v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: Skip checking of VSC SDP when a crtc config has psr.

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-10-gwan-gyeong.mun@intel.com
2020-05-14 13:54:03 +03:00
Gwan-gyeong Mun
dee66f3e07 drm/i915: Add state readout for DP HDR Metadata Infoframe SDP
Added state readout for DP HDR Metadata Infoframe SDP.

v9: Rebased
v10: Rebased

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-9-gwan-gyeong.mun@intel.com
2020-05-14 13:54:01 +03:00
Gwan-gyeong Mun
1bf3657c03 drm/i915: Program DP SDPs with computed configs
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.

Before:
 intel_dp_vsc_enable() and intel_dp_hdr_metadata_enable() compute sdp
 configs and program sdp registers on enable callback of encoder.

After:
 It separates computing of sdp configs and programming of sdp register.
 The compute config callback of encoder calls computing sdp configs.
 The enable callback of encoder calls programming sdp register.

v3: Rebased
v5: Polish commit message [Uma]
v10: Rebased

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-8-gwan-gyeong.mun@intel.com
2020-05-14 13:53:58 +03:00
Gwan-gyeong Mun
42890250d0 drm/i915: Include DP VSC SDP in the crtc state dump
Dump out the DP VSC SDP in the normal crtc state dump

v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
    Use drm core's DP VSC SDP logging function

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-7-gwan-gyeong.mun@intel.com
2020-05-14 13:53:55 +03:00
Gwan-gyeong Mun
e274fb32ff drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.

HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-6-gwan-gyeong.mun@intel.com
2020-05-14 13:53:53 +03:00
Gwan-gyeong Mun
bfbeba29b9 drm/i915: Include HDMI DRM infoframe in the crtc state dump
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-5-gwan-gyeong.mun@intel.com
2020-05-14 13:53:51 +03:00
Gwan-gyeong Mun
1b404b7dbb drm/i915/dp: Read out DP SDPs
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.

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

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

A naming rule and style of intel_read_dp_sdp() function references
intel_read_infoframe() function of intel_hdmi.c

v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v5: Addressed review comments from Uma
  - Polish commit message and comments
  - Combine the if checks of sdp.HB2 and sdp.HB3
  - Add 6bpc to unpacking of VSC SDP

Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514060732.3378396-3-gwan-gyeong.mun@intel.com
2020-05-14 13:53:31 +03:00
Chris Wilson
0f4013fb28 drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a47
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the first engine and marked up this request to reattach
the signaling on the new engine. However, this failed to take into
account that we only attach the breadcrumb if the new request is added
at the start of the queue, which if we are transferring, it is because
we know there to be a request to be signaled (and hence we would not be
attached).

In this attempt, we try to transfer the completed requests to the
irq_worker on its rq->engine->breadcrumbs. This preserves the coupling
between the rq and its breadcrumbs, so that
i915_request_cancel_breadcrumb() does not attempt to manipulate the list
under the wrong lock.

v2: Code sharing is fun.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1862
Fixes: 6c81e21a47 ("drm/i915/gt: Stage the transfer of the virtual breadcrumb")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-1-chris@chris-wilson.co.uk
2020-05-14 10:09:31 +01:00