Daniele Ceraolo Spurio
c447ff7db3
drm/i915: update with_intel_runtime_pm to use the rpm structure
...
Matching the underlying get/put functions.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Imre Deak <imre.deak@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-8-daniele.ceraolospurio@intel.com
2019-06-14 15:58:33 +01:00
Daniele Ceraolo Spurio
33ec6c9eb3
drm/i915/guc: always use Command Transport Buffers
...
Now that we've moved the Gen9 GuC blobs to version 32 we have CTB
support on all gens, so no need to restrict the usage to Gen11+.
Note that MMIO communication is still required for CTB initialization.
v2: fix commit message nits (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190606224225.14287-1-daniele.ceraolospurio@intel.com
2019-06-09 11:21:33 +01:00
Oscar Mateo
1e83e7a66d
drm/i915/guc: Create vfuncs for the GuC interrupts control functions
...
Controlling and handling of the GuC interrupts is Gen specific.
Create virtual functions to avoid redundant runtime Gen checks.
Gen-specific versions of these functions will follow.
v2: move vfuncs to struct guc (Daniele)
v3: rebased
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-12-michal.wajdeczko@intel.com
2019-05-28 10:07:15 +01:00
Michal Wajdeczko
e958cc9087
drm/i915/guc: Always ask GuC to update power domain states
...
With newer GuC firmware it is always ok to ask GuC to update power
domain states. Make it an unconditional initialization step.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: John Spotswood <john.a.spotswood@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: John Spotswood <john.a.spotswood@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-6-michal.wajdeczko@intel.com
2019-05-28 10:07:06 +01:00
Michal Wajdeczko
386e300fe9
drm/i915/guc: Reset GuC ADS during sanitize
...
GuC stores some data in there, which might be stale after a reset.
Reinitialize whole ADS in case any part of it was corrupted during
previous GuC run.
v2: s/reinit/init, update functions descriptions (Tomek/Michal)
v3: reset ADS right before fw upload
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: MichaĹ Winiarski <michal.winiarski@intel.com >
Cc: Tomasz Lis <tomasz.lis@intel.com >
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com > #v2
Reviewed-by: MichaĹ Winiarski <michal.winiarski@intel.com > #v2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-5-michal.wajdeczko@intel.com
2019-05-28 10:07:05 +01:00
Michal Wajdeczko
a2904ade3d
drm/i915/guc: Don't allow GuC submission
...
Due to the upcoming changes to the GuC ABI interface, we must
disable GuC submission mode until final ABI will be available
on all GuC firmwares.
To avoid regressions on systems configured to run with no longer
supported configuration "enable_guc=3" or "enable_guc=1" clear
GuC submission bit.
v2: force switch to non-GuC submission mode
v3: use GEM_BUG_ON (Joonas)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: John Spotswood <john.a.spotswood@intel.com >
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com >
Cc: Tony Ye <tony.ye@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Cc: Jeff Mcgee <jeff.mcgee@intel.com >
Cc: Antonio Argenziano <antonio.argenziano@intel.com >
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com >
Cc: Martin Peres <martin.peres@linux.intel.com >
Acked-by: Martin Peres <martin.peres@linux.intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-3-michal.wajdeczko@intel.com
2019-05-28 10:07:00 +01:00
Michal Wajdeczko
cc80b2ef24
drm/i915/guc: Change platform default GuC mode
...
Today our most desired GuC configuration is to only enable HuC
if it is available (as we need authenticated HuC firmware to enable
all media codecs on the hardware) and we really don't care about
having GuC submission enabled.
Change platform default GuC mode to match our goal, but note that
we still don't change default modparam value (GuC/HuC disabled).
v2: add why HuC is so important (Joonas)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: John Spotswood <john.a.spotswood@intel.com >
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com >
Cc: Tony Ye <tony.ye@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Cc: Jeff Mcgee <jeff.mcgee@intel.com >
Cc: Antonio Argenziano <antonio.argenziano@intel.com >
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com >
Acked-by: Tony Ye <tony.ye@intel.com >
Reviewed-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com >
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-2-michal.wajdeczko@intel.com
2019-05-28 10:06:59 +01:00
Michal Wajdeczko
eaf20e6933
drm/i915/uc: Skip reset preparation if GuC is already dead
...
We may skip reset preparation steps if GuC is already sanitized.
v2: replace USES_GUC with guc_is_loaded
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190522193203.23932-10-michal.wajdeczko@intel.com
2019-05-23 21:58:36 +01:00
Michal Wajdeczko
a2ce231473
drm/i915/uc: Stop talking with GuC when resetting
...
Knowing that GuC will be reset soon, we may stop all communication
immediately without doing graceful cleanup as it is not needed.
This patch will also help us capture any unwanted/unexpected attempts
to talk with GuC after we decided to reset it. And we need to keep
'disable' part as current and upcoming firmware still expect graceful
cleanup.
v2: update commit msg
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190523172555.2780-1-michal.wajdeczko@intel.com
2019-05-23 21:58:36 +01:00
Michal Wajdeczko
0922f3459f
drm/i915/uc: Skip GuC HW unwinding if GuC is already dead
...
We should not attempt to unwind GuC hardware/firmware setup
if we already have sanitized GuC.
v2: replace USES_GUC with guc_is_loaded
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190522193203.23932-8-michal.wajdeczko@intel.com
2019-05-23 21:58:36 +01:00
Michal Wajdeczko
f1e6b336ba
drm/i915/uc: Use GuC firmware status helper
...
We already have helper function for checking GuC firmware
load status. Replace existing open-coded checks.
v2: drop redundant USES_GUC check
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
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/20190522193203.23932-7-michal.wajdeczko@intel.com
2019-05-23 21:58:36 +01:00
Michal Wajdeczko
89195bab5d
drm/i915/uc: Explicitly sanitize GuC/HuC on failure and finish
...
Explicitly sanitize GuC/HuC on load failure and when we finish
using them to make sure our fw state tracking is always correct.
While around, use new helper in uc_reset_prepare.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190522193203.23932-6-michal.wajdeczko@intel.com
2019-05-23 21:58:36 +01:00
Chris Wilson
818f5cb3e8
drm/i915/guc: Fix runtime suspend
...
We are not allowed to rpm_get() inside the runtime-suspend callback, so
split the intel_uc_suspend() into the core that assumes the caller holds
the wakeref (intel_uc_runtime_suspend), and one that acquires the wakeref
as necessary (intel_uc_suspend).
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Fixes: 79ffac8599chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190502203009.15727-1-chris@chris-wilson.co.uk
2019-05-03 08:38:37 +01:00
Chris Wilson
79ffac8599
drm/i915: Invert the GEM wakeref hierarchy
...
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-24 22:26:49 +01:00
Chris Wilson
112ed2d31a
drm/i915: Move GraphicsTechnology files under gt/
...
Start partitioning off the code that talks to the hardware (GT) from the
uapi layers and move the device facing code under gt/
One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
subdivide that header and body further (and split out the submission
code from the ringbuffer and logical context handling). This patch aims
to be simple motion so git can fixup inflight patches with little mess.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Acked-by: Jani Nikula <jani.nikula@intel.com >
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190424174839.7141-1-chris@chris-wilson.co.uk
2019-04-24 21:01:46 +01:00
Fernando Pacheco
fc488b5903
drm/i915/uc: Place uC firmware in upper range of GGTT
...
Currently we pin the GuC or HuC firmware image just before uploading.
Perma-pin during uC initialization instead and use the range reserved at
the top of the address space.
Moving the firmware resulted in needing to:
- use an additional pinning for the rsa signature which will be used
during HuC auth as addresses above GUC_GGTT_TOP do not map through GTT.
v2: Remove call to set to gtt domain
Do not restore fw gtt mapping unconditionally
Separate out pin/unpin functions and drop usage of pin/unpin
Use uc_fw init/fini functions to bind/unbind fw object
v3: Bind is only needed during xfer (Chris)
Remove attempts to bind outside of xfer (Chris)
Mark fw bind/unbind static
Signed-off-by: Fernando Pacheco <fernando.pacheco@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/20190419230015.18121-4-fernando.pacheco@intel.com
2019-04-20 08:19:32 +01:00
Robert M. Fosha
52b8326060
drm/i915/guc: Retry GuC load for all load failures
...
Currently we only retry to load GuC firmware if the load fails due to
timeout. On Gen9 GuC loading may fail for different reasons, not just
hang/timeout. Direction from the GuC team is to retry for all cases of
GuC load failure on Gen9, not just for timeout.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108593
Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@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/20190329231746.9129-1-robert.m.fosha@intel.com
2019-03-30 08:02:07 +00:00
Sujaritha Sundaresan
1813ae17fd
drm/i915/guc: Calling guc_disable_communication in all suspend paths
...
This aim of this patch is to call guc_disable_communication in all
suspend paths. The reason to introduce this is to resolve a bug that
occurred due to suspend late not being called in the hibernate devices
path.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190220013927.9488-3-sujaritha.sundaresan@intel.com
2019-02-20 23:53:21 +00:00
Chris Wilson
9f58892ea9
drm/i915: Pull all the reset functionality together into i915_reset.c
...
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190116153304.787-1-chris@chris-wilson.co.uk
2019-01-16 22:45:31 +00:00
Jani Nikula
fce43315e8
drm/i915/uc: add dev_priv parameter to intel_uc_is_using_* functions
...
Reveals the build fail fixed in the last hunk. Also prep work.
v2: name it i915 instead of dev_priv (Michal)
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/8e02dcf1b85462d17e96fb183440dd90261b7411.1545920737.git.jani.nikula@intel.com
2018-12-31 15:27:23 +02:00
Lucas De Marchi
cf819eff90
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
...
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Jani Nikula <jani.nikula@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-12 16:52:10 -08:00
Michal Wajdeczko
ad52fcc97c
drm/i915/guc: Fix Gen9 GuC loading workarounds
...
In commit 4502e9ec82daniele.ceraolospurio@intel.com >
References: commit 4502e9ec82michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20181016085931.23532-1-michal.wajdeczko@intel.com
2018-10-17 09:08:00 +01:00
Michal Wajdeczko
b84d9ab0b7
drm/i915/guc: Update GuC power domain states
...
We should update GuC power domain states also when GuC submission
is disabled, otherwise GuC might complain or ignore our requests.
This seems to be required for all currently released GuC firmwares.
v2: it is only needed by pre-Gen11 firmwares
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: John Spotswood <john.a.spotswood@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Cc: Tomasz Lis <tomasz.lis@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180910104150.101752-1-michal.wajdeczko@intel.com
2018-09-10 20:31:55 +01:00
Michal Wajdeczko
f7dc0157e4
drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific init
...
We're fetching GuC/HuC firmwares directly from uc level during
init_early stage but this breaks guc/huc struct isolation and
also strict SW-only initialization rule for init_early. Move fw
fetching to init phase and do it separately per guc/huc struct.
v2: don't forget to move wopcm_init - Michele
v3: fetch in init_misc phase - Michal
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Michel Thierry <michel.thierry@intel.com > #2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180628141522.62788-2-michal.wajdeczko@intel.com
2018-06-28 22:51:33 +01:00
Michal Wajdeczko
c39d2e7e35
drm/i915/guc: Use intel_guc_init_misc to hide GuC internals
...
We will add more init steps to misc phase and there is no need
to expose them separately for use in uc_init_misc function.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180628141522.62788-1-michal.wajdeczko@intel.com
2018-06-28 22:51:32 +01:00
Piotr Piórkowski
50935ac767
drm/i915/guc: Don't store runtime GuC log level in modparam
...
Currently we are using modparam as placeholder for GuC log level.
Stop doing this and keep runtime GuC level in intel_guc_log struct.
v2:
- rename functions intel_guc_log_level_[get|set] to
intel_guc_log_[get|set]_level (Michał Wajdeczko)
- remove GEM_BUG_ON from intel_guc_log_get_level() (Michał Wajdeczko)
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Michał Winiarski <michal.winiarski@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180604141947.8299-1-piotr.piorkowski@intel.com
2018-06-12 15:44:40 +01:00
Michal Wajdeczko
8f1ad1ef1e
drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
...
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
v4: rebased
v5: rebased, pulled out from the series
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180525121858.53928-1-michal.wajdeczko@intel.com
2018-05-25 20:28:54 +01:00
Michel Thierry
4d07f6c40a
drm/i915/guc: enable guc interrupts unconditionally in uc_resume
...
Probably lost while rebasing commit eacd8391f9michel.thierry@intel.com >
Cc: Michał Winiarski <michal.winiarski@intel.com >
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180328205851.16188-1-michel.thierry@intel.com
2018-03-29 11:29:30 +01:00
Michal Wajdeczko
769bfbf943
drm/i915/guc: Make event handler a virtual function
...
On platforms with CTB based GuC communications, we will handle
GuC events in a different way. Let's make event handler a virtual
function to allow easy switch between those variants.
Credits-to: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Oscar Mateo <oscar.mateo@intel.com >
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180326194829.58836-6-michal.wajdeczko@intel.com
2018-03-28 20:35:13 +01:00
Michal Wajdeczko
8c650aefb8
drm/i915/uc: Fetch uC firmware in init_early
...
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20180323123451.59244-2-michal.wajdeczko@intel.com
2018-03-23 17:03:24 +00:00
Michal Wajdeczko
d871bfd008
drm/i915/guc: Unify parameters of public CT functions
...
There is no need to mix parameter types in public CT functions
as we can always accept intel_guc_ct.
v2: fix 'Return' doc, s/dev_priv/i915 (Sagar)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180320162020.38672-1-michal.wajdeczko@intel.com
2018-03-21 15:11:03 +00:00
Michał Winiarski
03380d173a
drm/i915/guc: Don't try to enable GuC logging when we're not using GuC
...
When changing the default values for guc_log_level, we accidentally left
the log enabled on non-guc platforms. Let's fix that.
v2: Define the levels used and remove (now obsolete) comments (Chris)
v3: Use "IS" rather than "TO" for booleans (Chris)
Fixes: 9605d1ce7cchris@chris-wilson.co.uk >
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@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/20180320115517.20423-1-michal.winiarski@intel.com
2018-03-20 14:55:58 +00:00
Michał Winiarski
9605d1ce7c
drm/i915/guc: Default to non-verbose GuC logging
...
Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing with non-verbose logging being disabled.
v2: Bring back the "auto" guc_log_level, now that we fixed the log
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-11-michal.winiarski@intel.com
2018-03-19 12:23:02 +00:00
Michał Winiarski
cb5d64e9f1
drm/i915/guc: Allow user to control default GuC logging
...
While both naming and actual log enable logic in GuC interface are
confusing, we can simply expose the default log as yet another log
level.
GuC logic aside, from i915 point of view we now have the following GuC
log levels:
0 Log disabled
1 Non-verbose log
2-5 Verbose log
v2: Adjust naming after rebase.
v3: Fixed the log_level logic error introduced on rebase.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-10-michal.winiarski@intel.com
2018-03-19 12:23:02 +00:00
Michał Winiarski
4977a287b9
drm/i915/guc: Split relay control and GuC log level
...
Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.
v2: Don't touch guc_log_level on relay creation error, adjust locking
after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar)
Use struct_mutex rather than runtime.lock for set_log_level
v3: Tidy ordering of definitions (Sagar)
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-5-michal.winiarski@intel.com
2018-03-19 12:23:02 +00:00
Michał Winiarski
eacd8391f9
drm/i915/guc: Keep GuC interrupts enabled when using GuC
...
The GuC log contains a separate space used for crash dump.
We even get a separate notification for it. While we're not handling
crash differently yet, it makes sense to decouple the two right now to
simplify the following patches.
v2: Move guc_log_flush_irq_disable up to avoid movement in following
patches (Sagar).
v3: s/guc_log_flush_irq_*/guc_flush_log_msg_*, rebase after mass rename
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com > (v2)
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180319095348.9716-1-michal.winiarski@intel.com
2018-03-19 12:23:01 +00:00
Michal Wajdeczko
56b9a8b083
drm/i915/guc: Update syntax of GuC log functions
...
We moved GuC log related data and code to separate files and
definition but we didn't change functions syntax to follow
object-verb pattern. Let's fix that before we continue with
next round of code refactoring.
v2: rebased
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180314144539.11152-1-michal.wajdeczko@intel.com
[ickle: checkpatch booleans]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-03-15 10:58:11 +00:00
Jackie Li
f08e2035cc
drm/i915/guc: Check the locking status of GuC WOPCM registers
...
GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers which
will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).
This patch moves the GuC WOPCM registers updating code into intel_wopcm.c
and adds check before and after the update to GuC WOPCM registers so that
we can make sure the driver is in a known state after writing to these
write-once registers.
v6:
- Made sure module reloading won't bug the kernel while doing
locking status checking
v7:
- Fixed patch format issues
v8:
- Fixed coding style issue on register lock bit macro definition (Sagar)
v9:
- Avoided to use redundant !! to cast uint to bool (Chris)
- Return error code instead of GEM_BUG_ON for locked with invalid register
values case (Sagar)
- Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
- Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
WOPCM offset register based on the presence of HuC firmware (Michal)
- Use bit fields instead of macros for GuC WOPCM flags (Michal)
v10:
- Refined variable names, removed redundant comments (Joonas)
- Introduced lockable_reg to handle the write once register write and
propagate the write error to caller (Joonas)
- Used lockable_reg abstraction to avoid locking bit check on generic
i915_reg_t (Michal)
- Added log message for error paths (Michal)
- Removed hw_updated flag and only relies on real hardware status
v11:
- Replaced lockable_reg with simplified function (Michal)
- Used new macros for locking bits of WOPCM size/offset registers instead
of using BIT(0) directly (Michal)
- use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
WOPCM register setup instead of calling from intel_uc_init_hw() (Michal)
v12:
- Updated function kernel-doc to align with code changes (Michal)
- Updated code to use wopcm pointer directly (Michal)
v13:
- Updated the ordering of s-o-b/cc/r-b tags (Sagar)
BSpec: 10875, 10833
Signed-off-by: Jackie Li <yaodong.li@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com > (v11)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com > (v12)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-5-git-send-email-yaodong.li@intel.com
2018-03-14 15:35:37 +02:00
Jackie Li
6b0478fb72
drm/i915: Implement dynamic GuC WOPCM offset and size calculation
...
Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. On the other hand, with
current static GuC WOPCM offset and size values (512KB for both offset and
size), the GuC WOPCM size verification will fail on Gen9 even if it can be
fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.
This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To
meet all above requirements, let's provide dynamic partitioning of the
WOPCM that will be based on platform specific HuC/GuC firmware sizes.
v2:
- Removed intel_wopcm_init (Ville/Sagar/Joonas)
- Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
- Removed unnecessary function calls (Joonas)
- Init GuC WOPCM partition as soon as firmware fetching is completed
v3:
- Fixed indentation issues (Chris)
- Removed layering violation code (Chris/Michal)
- Created separat files for GuC wopcm code (Michal)
- Used inline function to avoid code duplication (Michal)
v4:
- Preset the GuC WOPCM top during early GuC init (Chris)
- Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed
v5:
- Moved GuC DMA WOPCM register updating code into intel_wopcm.c
- Took care of the locking status before writing to GuC DMA
Write-Once registers. (Joonas)
v6:
- Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)
v8:
- Updated comments and fixed naming issues (Sagar/Joonas)
- Updated commit message to include more description about the hardware
restriction on GuC WOPCM size (Sagar)
v9:
- Minor changes variable names and code comments (Sagar)
- Added detailed GuC WOPCM layout drawing (Sagar/Michal)
- Refined macro definitions to be reader friendly (Michal)
- Removed redundent check to valid flag (Michal)
- Unified first parameter for exported GuC WOPCM functions (Michal)
- Refined the name and parameter list of hardware restriction checking
functions (Michal)
v10:
- Used shorter function name for internal functions (Joonas)
- Moved init-ealry function into c file (Joonas)
- Consolidated and removed redundant size checks (Joonas/Michal)
- Removed unnecessary unlikely() from code which is only called once
during boot (Joonas)
- More fixes to kernel-doc format and content (Michal)
- Avoided the use of PAGE_MASK for 4K pages (Michal)
- Added error log messages to error paths (Michal)
v11:
- Replaced intel_guc_wopcm with more generic intel_wopcm and attached
intel_wopcm to drm_i915_private instead intel_guc (Michal)
- dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top
offset from GuC WOPCM base) (Michal)
- Moved WOPCM marco definitions into .c source file (Michal)
- Exported WOPCM layout diagram as kernel-doc (Michal)
v12:
- Updated naming, function kernel-doc to align with new changes (Michal)
v13:
- Updated the ordering of s-o-b/cc/r-b tags (Sagar)
- Corrected one tense error in comment (Sagar)
- Corrected typos and removed spurious comments (Joonas)
Bspec: 12690
Signed-off-by: Jackie Li <yaodong.li@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: John Spotswood <john.a.spotswood@intel.com >
Cc: Oscar Mateo <oscar.mateo@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com > (v8)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com > (v9)
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com > (v11)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com > (v12)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1520987574-19351-2-git-send-email-yaodong.li@intel.com
2018-03-14 15:35:33 +02:00
Michal Wajdeczko
c37d572820
drm/i915/uc: Sanitize uC together with GEM
...
Instead of dancing around uC on reset/suspend/resume scenarios,
explicitly sanitize uC when we sanitize GEM to force uC reload
and start from known beginning.
v2: don't forget about reset path (Daniele)
sanitize uc before gem initiated full reset (Daniele)
v3: drop redundant disable_communication in init_hw (Daniele)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180312130308.22952-3-michal.wajdeczko@intel.com
2018-03-12 22:06:19 +00:00
Michal Wajdeczko
3c33fc7c1a
drm/i915/uc: Sanitize uC options early
...
We are sanitizing uC related modparams together with other driver
modparams in intel_sanitize_options called from i915_driver_init_hw,
but this is too late for us as we will want to use USES_GUC/USES_HUC
macros at earlier stage. Since our sanitizing does not require any
MMIO access, we can do it in intel_uc_init_early right after we resolve
firmware names.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
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/20180312130308.22952-2-michal.wajdeczko@intel.com
2018-03-12 22:06:19 +00:00
Michał Winiarski
950724ba88
drm/i915/guc: Create common entry points for log register/unregister
...
We have many functions responsible for allocating different parts of
GuC log runtime called from multiple places. Let's stick with keeping
everything in guc_log_register instead.
v2: Use more generic intel_uc_register name, keep using "misc" suffix (Michał)
s/dev_priv/i915 (Sagar)
Make guc_log_relay_* static (sparse)
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-2-michal.winiarski@intel.com
2018-03-09 22:21:41 +00:00
Michal Wajdeczko
7cfca4afd6
drm/i915/uc: Introduce intel_uc_suspend|resume
...
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.
While here, move call to disable_guc_interrupts after sending suspend
action to the GuC to allow it work also with CTB as comm mechanism.
v2: update commit msg (Sagar)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302111550.21328-1-michal.wajdeczko@intel.com
2018-03-02 23:11:12 +00:00
Sagar Arun Kamble
57312eaacd
drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
...
GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.
While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()
v2: Changed patch to update HuC functions instead of changing
guc_fw_upload and update file structure. (Michal Wajdeczko)
v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1519922745-25441-1-git-send-email-sagar.a.kamble@intel.com
2018-03-02 09:04:45 +00:00
Michal Wajdeczko
bf67ce62a0
drm/i915/guc: Don't forget to free GuC error log
...
We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called.
If we free this log object as part of the late uC cleanup, where
we also release other firmware objects, we can avoid this BUG:
[70841.001413] BUG drm_i915_gem_object (Tainted: G U W ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown()
[70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100
[70841.001466] Call Trace:
[70841.001471] dump_stack+0x5e/0x8e
[70841.001476] slab_err+0x99/0xb0
[70841.001483] ? __slab_alloc.isra.24.constprop.29+0x62/0x70
[70841.001491] ? __kmalloc+0x1f5/0x320
[70841.001497] __kmem_cache_shutdown+0x18b/0x400
[70841.001505] shutdown_cache+0x13/0x1c0
[70841.001511] kmem_cache_destroy+0x1c2/0x240
[70841.001517] ? __mutex_unlock_slowpath+0x38/0x270
[70841.001559] i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.001595] i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.001630] i915_driver_load+0x708/0x1720 [i915]
[70841.001638] ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.001673] i915_pci_probe+0x2d/0x90 [i915]
[70841.001680] pci_device_probe+0x9c/0x120
[70841.001687] driver_probe_device+0x2a9/0x490
[70841.001694] __driver_attach+0xd9/0xe0
[70841.001700] ? driver_probe_device+0x490/0x490
[70841.001705] bus_for_each_dev+0x57/0x90
[70841.001712] bus_add_driver+0x1eb/0x260
[70841.001717] ? 0xffffffffa0685000
[70841.001723] driver_register+0x52/0xc0
[70841.001728] ? 0xffffffffa0685000
[70841.001733] do_one_initcall+0x39/0x170
[70841.001739] ? rcu_read_lock_sched_held+0x6f/0x80
[70841.001746] ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.001753] do_init_module+0x56/0x1ec
[70841.001759] load_module+0x219e/0x2550
[70841.001766] ? vfs_read+0x121/0x140
[70841.001774] ? SyS_finit_module+0xa5/0xe0
[70841.001779] SyS_finit_module+0xa5/0xe0
[70841.001788] entry_SYSCALL_64_fastpath+0x22/0x8f
[70841.001806] INFO: Object 0x00000000eab7ed96 @offset=6208
[70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708
[70841.001861] kmem_cache_alloc+0x23d/0x2d0
[70841.001897] i915_gem_object_create.part.32+0x1f/0x260 [i915]
[70841.001937] intel_guc_allocate_vma+0x15/0x100 [i915]
[70841.001977] intel_guc_log_create+0x34/0x1c0 [i915]
[70841.002014] intel_guc_init+0x5a/0x100 [i915]
[70841.002051] intel_uc_init+0x3e/0xb0 [i915]
[70841.002089] i915_gem_init+0x18e/0x540 [i915]
[70841.002123] i915_driver_load+0xa7a/0x1720 [i915]
[70841.002159] i915_pci_probe+0x2d/0x90 [i915]
[70841.002165] pci_device_probe+0x9c/0x120
[70841.002171] driver_probe_device+0x2a9/0x490
[70841.002177] __driver_attach+0xd9/0xe0
[70841.002182] bus_for_each_dev+0x57/0x90
[70841.002188] bus_add_driver+0x1eb/0x260
[70841.002193] driver_register+0x52/0xc0
[70841.002198] do_one_initcall+0x39/0x170
[70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects
[70841.002491] Call Trace:
[70841.002497] dump_stack+0x5e/0x8e
[70841.002503] kmem_cache_destroy+0x1e0/0x240
[70841.002509] ? __mutex_unlock_slowpath+0x38/0x270
[70841.002551] i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.002586] i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.002621] i915_driver_load+0x708/0x1720 [i915]
[70841.002629] ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.002664] i915_pci_probe+0x2d/0x90 [i915]
[70841.002671] pci_device_probe+0x9c/0x120
[70841.002678] driver_probe_device+0x2a9/0x490
[70841.002684] __driver_attach+0xd9/0xe0
[70841.002690] ? driver_probe_device+0x490/0x490
[70841.002696] bus_for_each_dev+0x57/0x90
[70841.002702] bus_add_driver+0x1eb/0x260
[70841.002708] ? 0xffffffffa0685000
[70841.002713] driver_register+0x52/0xc0
[70841.002719] ? 0xffffffffa0685000
[70841.002724] do_one_initcall+0x39/0x170
[70841.002731] ? rcu_read_lock_sched_held+0x6f/0x80
[70841.002737] ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.002745] do_init_module+0x56/0x1ec
[70841.002751] load_module+0x219e/0x2550
[70841.002758] ? vfs_read+0x121/0x140
[70841.002766] ? SyS_finit_module+0xa5/0xe0
[70841.002772] SyS_finit_module+0xa5/0xe0
[70841.002781] entry_SYSCALL_64_fastpath+0x22/0x8f
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-2-michal.wajdeczko@intel.com
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-02-01 12:33:57 +00:00
Sagar Arun Kamble
70deeaddc6
drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex
...
This patch fixes lockdep issue due to circular locking dependency of
struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex.
For GuC log relay channel we create debugfs file that requires i_mutex_key
lock and we are doing that under struct_mutex. So we introduced newer
dependency as:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem
However, there is dependency from mmap_sem to struct_mutex. Hence we
separate the relay create/destroy operation from under struct_mutex.
Also added runtime check of relay buffer status.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
======================================================
WARNING: possible circular locking dependency detected
4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted
------------------------------------------------------
debugfs_test/1388 is trying to acquire lock:
(&dev->struct_mutex){+.+.}, at: [<00000000d5e1d915>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
but task is already holding lock:
(&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&mm->mmap_sem){++++}:
_copy_to_user+0x1e/0x70
filldir+0x8c/0xf0
dcache_readdir+0xeb/0x160
iterate_dir+0xdc/0x140
SyS_getdents+0xa0/0x130
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #2 (&sb->s_type->i_mutex_key#3){++++}:
start_creating+0x59/0x110
__debugfs_create_file+0x2e/0xe0
relay_create_buf_file+0x62/0x80
relay_late_setup_files+0x84/0x250
guc_log_late_setup+0x4f/0x110 [i915]
i915_guc_log_register+0x32/0x40 [i915]
i915_driver_load+0x7b6/0x1720 [i915]
i915_pci_probe+0x2e/0x90 [i915]
pci_device_probe+0x9c/0x120
driver_probe_device+0x2a3/0x480
__driver_attach+0xd9/0xe0
bus_for_each_dev+0x57/0x90
bus_add_driver+0x168/0x260
driver_register+0x52/0xc0
do_one_initcall+0x39/0x150
do_init_module+0x56/0x1ef
load_module+0x231c/0x2d70
SyS_finit_module+0xa5/0xe0
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #1 (relay_channels_mutex){+.+.}:
relay_open+0x12c/0x2b0
intel_guc_log_runtime_create+0xab/0x230 [i915]
intel_guc_init+0x81/0x120 [i915]
intel_uc_init+0x29/0xa0 [i915]
i915_gem_init+0x182/0x530 [i915]
i915_driver_load+0xaa9/0x1720 [i915]
i915_pci_probe+0x2e/0x90 [i915]
pci_device_probe+0x9c/0x120
driver_probe_device+0x2a3/0x480
__driver_attach+0xd9/0xe0
bus_for_each_dev+0x57/0x90
bus_add_driver+0x168/0x260
driver_register+0x52/0xc0
do_one_initcall+0x39/0x150
do_init_module+0x56/0x1ef
load_module+0x231c/0x2d70
SyS_finit_module+0xa5/0xe0
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #0 (&dev->struct_mutex){+.+.}:
__mutex_lock+0x81/0x9b0
i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_gem_fault+0x201/0x790 [i915]
__do_fault+0x15/0x70
__handle_mm_fault+0x677/0xdc0
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
page_fault+0x4c/0x60
other info that might help us debug this:
Chain exists of:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&mm->mmap_sem);
lock(&sb->s_type->i_mutex_key#3);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
*** DEADLOCK ***
1 lock held by debugfs_test/1388:
#0 : (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
stack backtrace:
CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016
Call Trace:
dump_stack+0x5f/0x86
print_circular_bug.isra.18+0x1d0/0x2c0
__lock_acquire+0x14ae/0x1b60
? lock_acquire+0xaf/0x200
lock_acquire+0xaf/0x200
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
__mutex_lock+0x81/0x9b0
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_mutex_lock_interruptible+0x47/0x130 [i915]
? __pm_runtime_resume+0x4f/0x80
i915_gem_fault+0x201/0x790 [i915]
__do_fault+0x15/0x70
? _raw_spin_unlock+0x29/0x40
__handle_mm_fault+0x677/0xdc0
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
? page_fault+0x36/0x60
page_fault+0x4c/0x60
v2: Added lock protection to guc->log.runtime.relay_chan (Chris)
Fixed locking inside guc_flush_logs uncovered by new lockdep.
v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris)
Prepared intel_guc_init_early. Moved relay_lock inside relay_create
relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal)
Removed struct_mutex lock around guc_log_flush and removed usage
of guc_log_has_relay() from runtime_create path as it needs
struct_mutex lock.
v4: Handle NULL relay sub buffer pointer earlier in read_update_log_buffer
(Chris). Fixed comment suffix **/. (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693
Testcase: igt/debugfs_test/read_all_entries # with enable_guc=1 and guc_log_level=1
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Marta Lofstedt <marta.lofstedt@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-3-git-send-email-sagar.a.kamble@intel.com
2018-01-24 19:44:04 +00:00
Michal Wajdeczko
0ed8795353
drm/i915/guc: Redefine guc_log_level modparam values
...
We used value -1 to indicate "disabled" and values 0..3 to
indicate "enabled", but most of our other modparams are using
-1 for "auto" mode and 0 for "disable". For consistency let's
change our log level values to:
-1: auto (depends on platform and Kconfig.debug settings)
0: disabled
1: enabled (severity level 0 = min)
2: enabled (severity level 1)
3: enabled (severity level 2)
4: enabled (severity level 3 = max)
v2: fix commit message (Sagar)
display sanitized modparam value (Sagar)
unify sanitize messages (Sagar/Michal)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180111152441.21676-1-michal.wajdeczko@intel.com
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-01-18 17:15:48 +00:00
Sagar Arun Kamble
da943b5ab0
drm/i915/guc: Add uc_fini_wq in gem_init unwind path
...
While moving code around for solving lockdep issue for GuC log relay,
spotted that uc_fini_wq is not being called in failure path in gem_init.
Missed in the below commit. Add it.
v2: Removed GEM_BUG_ON(!HAS_GUC()) from intel_uc_fini_wq as init happens
only based on enable_guc module parameter and does not consider has_guc
capability. (Michal)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Fixes: 3176ff49bcmichal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1515588857-10283-1-git-send-email-sagar.a.kamble@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
2018-01-10 14:03:10 +00:00
Michał Winiarski
61b5c1587d
drm/i915/guc: Extract guc_init from guc_init_hw
...
After GPU reset, GuC HW needs to be reinitialized (with FW reload).
Unfortunately, we're doing some extra work there (mostly allocating stuff),
work that can be moved to guc_init and called once at driver load time.
As a side effect we're no longer hitting an assert in
i915_ggtt_enable_guc on suspend/resume.
v2: Do not duplicate disable_communication / reset_guc_interrupts
v3: Add proper teardown after rebase
References: 04f7b24eccmichal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@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/20171213221352.7173-3-michal.winiarski@intel.com
2017-12-14 08:06:56 +00:00
Michał Winiarski
3176ff49bc
drm/i915/guc: Move GuC workqueue allocations outside of the mutex
...
This gets rid of the following lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
------------------------------------------------------
debugfs_test/1351 is trying to acquire lock:
(&dev->struct_mutex){+.+.}, at: [<000000009d90d1a3>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
but task is already holding lock:
(&mm->mmap_sem){++++}, at: [<000000005df01c1e>] __do_page_fault+0x106/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&mm->mmap_sem){++++}:
__might_fault+0x63/0x90
_copy_to_user+0x1e/0x70
filldir+0x8c/0xf0
dcache_readdir+0xeb/0x160
iterate_dir+0xe6/0x150
SyS_getdents+0xa0/0x130
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #5 (&sb->s_type->i_mutex_key#5){++++}:
lockref_get+0x9/0x20
-> #4 ((completion)&req.done){+.+.}:
wait_for_common+0x54/0x210
devtmpfs_create_node+0x130/0x150
device_add+0x5ad/0x5e0
device_create_groups_vargs+0xd4/0xe0
device_create+0x35/0x40
msr_device_create+0x22/0x40
cpuhp_invoke_callback+0xc5/0xbf0
cpuhp_thread_fun+0x167/0x210
smpboot_thread_fn+0x17f/0x270
kthread+0x173/0x1b0
ret_from_fork+0x24/0x30
-> #3 (cpuhp_state-up){+.+.}:
cpuhp_issue_call+0x132/0x1c0
__cpuhp_setup_state_cpuslocked+0x12f/0x2a0
__cpuhp_setup_state+0x3a/0x50
page_writeback_init+0x3a/0x5c
start_kernel+0x393/0x3e2
secondary_startup_64+0xa5/0xb0
-> #2 (cpuhp_state_mutex){+.+.}:
__mutex_lock+0x81/0x9b0
__cpuhp_setup_state_cpuslocked+0x4b/0x2a0
__cpuhp_setup_state+0x3a/0x50
page_alloc_init+0x1f/0x26
start_kernel+0x139/0x3e2
secondary_startup_64+0xa5/0xb0
-> #1 (cpu_hotplug_lock.rw_sem){++++}:
cpus_read_lock+0x34/0xa0
apply_workqueue_attrs+0xd/0x40
__alloc_workqueue_key+0x2c7/0x4e1
intel_guc_submission_init+0x10c/0x650 [i915]
intel_uc_init_hw+0x29e/0x460 [i915]
i915_gem_init_hw+0xca/0x290 [i915]
i915_gem_init+0x115/0x3a0 [i915]
i915_driver_load+0x9a8/0x16c0 [i915]
i915_pci_probe+0x2e/0x90 [i915]
pci_device_probe+0x9c/0x120
driver_probe_device+0x2a3/0x480
__driver_attach+0xd9/0xe0
bus_for_each_dev+0x57/0x90
bus_add_driver+0x168/0x260
driver_register+0x52/0xc0
do_one_initcall+0x39/0x150
do_init_module+0x56/0x1ef
load_module+0x231c/0x2d70
SyS_finit_module+0xa5/0xe0
entry_SYSCALL_64_fastpath+0x1c/0x89
-> #0 (&dev->struct_mutex){+.+.}:
lock_acquire+0xaf/0x200
__mutex_lock+0x81/0x9b0
i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_gem_fault+0x201/0x760 [i915]
__do_fault+0x15/0x70
__handle_mm_fault+0x85b/0xe40
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
page_fault+0x22/0x30
other info that might help us debug this:
Chain exists of:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#5 --> &mm->mmap_sem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&mm->mmap_sem);
lock(&sb->s_type->i_mutex_key#5);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
*** DEADLOCK ***
1 lock held by debugfs_test/1351:
#0 : (&mm->mmap_sem){++++}, at: [<000000005df01c1e>] __do_page_fault+0x106/0x560
stack backtrace:
CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 4.15.0-rc2-CI-Patchwork_7428+ #1
Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
Call Trace:
dump_stack+0x5f/0x86
print_circular_bug+0x230/0x3b0
check_prev_add+0x439/0x7b0
? lockdep_init_map_crosslock+0x20/0x20
? unwind_get_return_address+0x16/0x30
? __lock_acquire+0x1385/0x15a0
__lock_acquire+0x1385/0x15a0
lock_acquire+0xaf/0x200
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
__mutex_lock+0x81/0x9b0
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_mutex_lock_interruptible+0x47/0x130 [i915]
? __pm_runtime_resume+0x4f/0x80
i915_gem_fault+0x201/0x760 [i915]
__do_fault+0x15/0x70
__handle_mm_fault+0x85b/0xe40
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
page_fault+0x22/0x30
RIP: 0033:0x7f98d6f49116
RSP: 002b:00007ffd6ffc3278 EFLAGS: 00010283
RAX: 00007f98d39a2bc0 RBX: 0000000000000000 RCX: 0000000000001680
RDX: 0000000000001680 RSI: 00007ffd6ffc3400 RDI: 00007f98d39a2bc0
RBP: 00007ffd6ffc33a0 R08: 0000000000000000 R09: 00000000000005a0
R10: 000055e847c2a830 R11: 0000000000000002 R12: 0000000000000001
R13: 000055e847c1d040 R14: 00007ffd6ffc3400 R15: 00007f98d6752ba0
v2: Init preempt_work unconditionally (Chris)
v3: Mention that we need the enable_guc=1 for lockdep splat (Chris)
Testcase: igt/debugfs_test/read_all_entries # with i915.enable_guc=1
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@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/20171213221352.7173-2-michal.winiarski@intel.com
2017-12-14 08:06:54 +00:00
