summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_uc.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/guc: Fix runtime suspendChris Wilson2019-05-031-8/+17
| | | | | | | | | | | | | | 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: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by: Chris Wilson <chris@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
* drm/i915: Invert the GEM wakeref hierarchyChris Wilson2019-04-241-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915: Move GraphicsTechnology files under gt/Chris Wilson2019-04-241-1/+1
| | | | | | | | | | | | | | | | 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
* drm/i915/uc: Place uC firmware in upper range of GGTTFernando Pacheco2019-04-201-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Retry GuC load for all load failuresRobert M. Fosha2019-03-301-1/+1
| | | | | | | | | | | | | | | 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
* drm/i915/guc: Calling guc_disable_communication in all suspend pathsSujaritha Sundaresan2019-02-201-4/+19
| | | | | | | | | | | | | | 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
* drm/i915: Pull all the reset functionality together into i915_reset.cChris Wilson2019-01-161-0/+1
| | | | | | | | | 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
* drm/i915/uc: add dev_priv parameter to intel_uc_is_using_* functionsJani Nikula2018-12-311-6/+6
| | | | | | | | | | 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
* drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi2018-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Fix Gen9 GuC loading workaroundsMichal Wajdeczko2018-10-171-1/+1
| | | | | | | | | | | | | | | | | | In commit 4502e9ec820d ("drm/i915/uc: Unify firmware loading") we stopped converting errors detected during firmware transfer into -EAGAIN and this indirectly killed our workarounds for Gen9 GuC. Reactivate those workarounds by looking for actual -ETIMEDOUT error. Testcase: igt@drv_selftest@live_hangcheck Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> References: commit 4502e9ec820d ("drm/i915/uc: Unify firmware loading") Signed-off-by: Michal Wajdeczko <michal.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
* drm/i915/guc: Update GuC power domain statesMichal Wajdeczko2018-09-101-0/+4
| | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc specific initMichal Wajdeczko2018-06-281-13/+15
| | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Use intel_guc_init_misc to hide GuC internalsMichal Wajdeczko2018-06-281-4/+2
| | | | | | | | | | | 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
* drm/i915/guc: Don't store runtime GuC log level in modparamPiotr Piórkowski2018-06-121-1/+1
| | | | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.cMichal Wajdeczko2018-05-251-65/+64
| | | | | | | | | | | | | | | | | 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
* drm/i915/guc: enable guc interrupts unconditionally in uc_resumeMichel Thierry2018-03-291-2/+1
| | | | | | | | | | | | | | Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC interrupts enabled when using GuC"). Not really needed since i915_gem_init_hw is called before uc_resume, but it brings symmetry to uc_suspend. Signed-off-by: Michel Thierry <michel.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
* drm/i915/guc: Make event handler a virtual functionMichal Wajdeczko2018-03-281-0/+2
| | | | | | | | | | | | | | 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
* drm/i915/uc: Fetch uC firmware in init_earlyMichal Wajdeczko2018-03-231-19/+18
| | | | | | | | | | | | | | | | 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
* drm/i915/guc: Unify parameters of public CT functionsMichal Wajdeczko2018-03-211-2/+2
| | | | | | | | | | | | | | 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
* drm/i915/guc: Don't try to enable GuC logging when we're not using GuCMichał Winiarski2018-03-201-12/+11
| | | | | | | | | | | | | | | | | | 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: 9605d1ce7c6b ("drm/i915/guc: Default to non-verbose GuC logging") Reported-by: Chris Wilson <chris@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
* drm/i915/guc: Default to non-verbose GuC loggingMichał Winiarski2018-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Allow user to control default GuC loggingMichał Winiarski2018-03-191-5/+9
| | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Split relay control and GuC log levelMichał Winiarski2018-03-191-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Keep GuC interrupts enabled when using GuCMichał Winiarski2018-03-191-9/+5
| | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Update syntax of GuC log functionsMichal Wajdeczko2018-03-151-2/+2
| | | | | | | | | | | | | | | | | 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>
* drm/i915/guc: Check the locking status of GuC WOPCM registersJackie Li2018-03-141-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915: Implement dynamic GuC WOPCM offset and size calculationJackie Li2018-03-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Sanitize uC together with GEMMichal Wajdeczko2018-03-121-1/+18
| | | | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Sanitize uC options earlyMichal Wajdeczko2018-03-121-2/+4
| | | | | | | | | | | | | | | | 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
* drm/i915/guc: Create common entry points for log register/unregisterMichał Winiarski2018-03-091-17/+24
| | | | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Introduce intel_uc_suspend|resumeMichal Wajdeczko2018-03-021-0/+45
| | | | | | | | | | | | | | | | | 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
* drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure ↵Sagar Arun Kamble2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Don't forget to free GuC error logMichal Wajdeczko2018-02-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutexSagar Arun Kamble2018-01-241-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Redefine guc_log_level modparam valuesMichal Wajdeczko2018-01-181-6/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915/guc: Add uc_fini_wq in gem_init unwind pathSagar Arun Kamble2018-01-101-2/+0
| | | | | | | | | | | | | | | | | | 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: 3176ff49bc3e ("drm/i915/guc: Move GuC workqueue allocations outside of the mutex") Cc: Michał 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/1515588857-10283-1-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/guc: Extract guc_init from guc_init_hwMichał Winiarski2017-12-141-25/+46
| | | | | | | | | | | | | | | | | | | | | | 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: 04f7b24eccdf ("drm/i915/guc: Assert that we switch between known ggtt->invalidate functions") 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> 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
* drm/i915/guc: Move GuC workqueue allocations outside of the mutexMichał Winiarski2017-12-141-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* drm/i915/guc: Move shared data allocation away from submission pathMichał Winiarski2017-12-141-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need shared data for actions (e.g. guc suspend/resume), and we're using those with GuC submission disabled. Let's introduce intel_guc_init and move shared data alloc there. This fixes GPF during module unload with HuC, but without GuC submission: BUG: unable to handle kernel NULL pointer dereference at 000000005aee7809 IP: intel_guc_suspend+0x34/0x140 [i915] PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915(O-) netconsole x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mei_me i2c_i801 mei prime_numbers [last unloaded: i915] CPU: 2 PID: 2794 Comm: rmmod Tainted: G U W O 4.15.0-rc2+ #297 Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016 task: 0000000055945c61 task.stack: 00000000264ccb43 RIP: 0010:intel_guc_suspend+0x34/0x140 [i915] RSP: 0018:ffffc90000483df8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff880829180000 RCX: 0000000000000000 RDX: 0000000000000006 RSI: ffff880844c2c938 RDI: ffff880844c2c000 RBP: ffff880829180000 R08: 00000000a29c58c1 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa040ba40 R13: ffffffffa040bab0 R14: ffff88084a195060 R15: 000055df3ef357a0 FS: 00007ff43c043740(0000) GS:ffff88084e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000f9 CR3: 000000083f179005 CR4: 00000000003606e0 Call Trace: i915_gem_suspend+0x9d/0x130 [i915] ? i915_driver_unload+0x68/0x180 [i915] i915_driver_unload+0x70/0x180 [i915] i915_pci_remove+0x15/0x20 [i915] pci_device_remove+0x36/0xb0 device_release_driver_internal+0x15f/0x220 driver_detach+0x3a/0x80 bus_remove_driver+0x58/0xd0 pci_unregister_driver+0x29/0x90 SyS_delete_module+0x150/0x1e0 entry_SYSCALL_64_fastpath+0x23/0x9a RIP: 0033:0x7ff43b51b5c7 RSP: 002b:00007ffe6825a758 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007ff43b51b5c7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055df3ef35808 RBP: 0000000000000000 R08: 00007ffe682596d1 R09: 0000000000000000 R10: 00007ff43b594880 R11: 0000000000000206 R12: 000055df3ef357a0 R13: 00007ffe68259740 R14: 000055df3ef35260 R15: 000055df3ef357a0 Code: 00 00 02 74 03 31 c0 c3 53 48 89 fb 48 83 ec 10 e8 52 0f f8 ff 48 b8 01 05 00 00 02 00 00 00 48 89 44 24 04 48 8b 83 00 12 00 00 <f6> 80 f9 00 00 00 01 0f 84 a7 00 00 00 f6 80 98 00 00 00 01 0f RIP: intel_guc_suspend+0x34/0x140 [i915] RSP: ffffc90000483df8 CR2: 00000000000000f9 ---[ end trace 23a192a61d937a3e ]--- Fixes: b8e5eb960b28 ("drm/i915/guc: Allocate separate shared data object for GuC communication") 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-1-michal.winiarski@intel.com
* drm/i915/huc: Load HuC only if requestedMichal Wajdeczko2017-12-061-5/+23
| | | | | | | | | | | | | | | | | | | | Our new "enable_guc" modparam allows to control whenever HuC should be loaded. However existing code will try load and authenticate HuC always when we use the GuC. This patch is trying to enforce modparam selection. v2: no need to cast PTR_ERR (Chris) fetch/fini only if required (Michal) fix wrong break (Sagar) v3: add new goto label (Sagar) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20171206135316.32556-7-michal.wajdeczko@intel.com
* drm/i915/guc: Combine enable_guc_loading|submission modparamsMichal Wajdeczko2017-12-061-44/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have two module parameters that control GuC: "enable_guc_loading" and "enable_guc_submission". Whenever we need submission=1, we also need loading=1. We also need loading=1 when we want to want to load and verify the HuC. Lets combine above module parameters into one "enable_guc" modparam. New supported bit values are: 0=disable GuC (no GuC submission, no HuC) 1=enable GuC submission 2=enable HuC load Special value "-1" can be used to let driver decide what option should be enabled for given platform based on hardware/firmware availability or preference. Explicit enabling any of the GuC features makes GuC load a required step, fallback to non-GuC mode will not be supported. v2: Don't use -EIO v3: define modparam bits (Chris) v4: rely on implicit cast (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@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/20171206135316.32556-6-michal.wajdeczko@intel.com
* drm/i915/uc: Don't fetch GuC firmware if no plan to use GuCMichal Wajdeczko2017-12-061-0/+6
| | | | | | | | | | | | | If we don't plan to use GuC then we should not try to fetch GuC and HuC firmwares. We can save memory and avoid possible dmesg noise. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20171206135316.32556-4-michal.wajdeczko@intel.com
* drm/i915/guc: Introduce USES_GUC_xxx helper macrosMichal Wajdeczko2017-12-061-12/+11
| | | | | | | | | | | | | | In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update dev_info message. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20171206135316.32556-3-michal.wajdeczko@intel.com
* drm/i915/guc: Move firmware selection to init_earlyMichal Wajdeczko2017-12-061-1/+1
| | | | | | | | | | | | | | Doing GuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20171206135316.32556-2-michal.wajdeczko@intel.com
* drm/i915/huc: Move firmware selection to init_earlyMichal Wajdeczko2017-12-061-3/+1
| | | | | | | | | | | | | | Doing HuC firmware path selection from sanitize_options function is not perfect, while there is no problem with doing so during early init stage as we already have all needed data. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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/20171206135316.32556-1-michal.wajdeczko@intel.com
* drm/i915/guc: Rename i915_guc_submission.c|h to intel_guc_submission.c|hSagar Arun Kamble2017-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | With all component structures and functions named appropriately, change the names of GuC submission source files. There were bunch of style issues in guc_submission.c that are highlighted now by checkpatch. Fix those. Update name in Documentation/gpu. (Joonas) v2: Rebase. v3: Rebase. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-6-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/guc: Update name and prototype of GuC submission interface functionsSagar Arun Kamble2017-11-161-7/+9
| | | | | | | | | | | | | | | | | | | | | | | i915 GuC submission is hardware interface and GuC APIs that are not user facing should be named intel_guc* hence we change GuC submission related functions name prefix to intel_guc. Also changed the parameter to these functions to intel_guc struct. v2: Using local guc variable in intel_uc_fini_hw. (Michal Wajdeczko) Rebase. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-4-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/guc: Rename the function that resets the GuCMichel Thierry2017-11-021-2/+2
| | | | | | | | | | | | | | | intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. v2: Print error message in English (Tvrtko). Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171030185616.32836-2-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915/guc: Update Guc messages on load failureMichal Wajdeczko2017-10-161-4/+5
| | | | | | | | | | | | | | In case of GuC firmware loading failure we were reporting DRM_ERROR also for case when GuC loading was not strictly required. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-14-michal.wajdeczko@intel.com
* drm/i915/guc: Pick better place for Guc final status messageMichal Wajdeczko2017-10-161-0/+6
| | | | | | | | | | | | | | | | GuC status message printed right after firmware upload may be too optimistic, as we may fail on subsequent steps. Move that message to the end of intel_uc_init_hw where we know the status for sure. v2: use dev_info (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-9-michal.wajdeczko@intel.com