- 13 Aug, 2019 1 commit
-
-
Zhenyu Wang authored
This fixes typo for VBLANK_TIMER_PERIOD. Reviewed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 09 Aug, 2019 1 commit
-
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(*sparse) + (nr_areas * sizeof(*sparse->areas) with: struct_size(sparse, areas, sparse->nr_areas) and so on... Also, notice that variable size is unnecessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
- 30 Jul, 2019 5 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
Track the currently bound address space used by the HW context. Minor conversions to use the local intel_context.vm are made, leaving behind some more surgery required to make intel_context the primary through the selftests. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730143209.4549-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move it under the i915_ggtt to simplify later transformations to enable intel_context.vm. Signed-off-by:
-
Chris Wilson authored
We only use the init_context vfunc once while recording the default context state, and we use the same sequence in each backend (eliding steps that do not apply). Remove the vfunc for simplicity and de-duplication. Signed-off-by:
-
Jani Nikula authored
Throw out our local hacks of header tests now that the more generic kbuild versions are upstream. At least for now, continue to keep the header tests behind CONFIG_DRM_I915_WERROR=y knob. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190729140847.18557-1-jani.nikula@intel.com
-
- 29 Jul, 2019 4 commits
-
-
Michal Wajdeczko authored
HuC is usually not a critical component, so we can safely ignore firmware load or authentication failures unless HuC was explicitly requested by the user. v2: add convenient way to disable loading (Chris) 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> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by:
-
Rodrigo Vivi authored
Catching up with 5.3-rc* Signed-off-by: -
Chris Wilson authored
As the gen6_ppgtt may refer back to the GGTT for their page-directory slots, make sure those __i915_vm_release are completed prior to shutting down the GGTT. Fixes: b32fa811 ("drm/i915/gtt: Defer address space cleanup to an RCU worker") Signed-off-by:
-
Chris Wilson authored
Smatch spotted that we test at the start of hang_fini for a valid (h->gt is only set after a request is created) but then used it regardless later on. v2: Alternatively, we do not need to check as we now always prime h->gt in hang_init() References: cb823ed9 ("drm/i915/gt: Use intel_gt as the primary object for handling resets") Signed-off-by:
-
- 27 Jul, 2019 1 commit
-
-
Chris Wilson authored
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Function parameter or member 'i915' not described in 'intel_uc_fw_fetch' drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Excess function parameter 'dev_priv' description in 'intel_uc_fw_fetch' Fixes: 97dee74b ("drm/i915/uc: Reorder params in intel_uc_fw_fetch") Signed-off-by:
-
- 26 Jul, 2019 13 commits
-
-
Mahesh Kumar authored
In GEN 12 PORT_C DDI clk_off bit is not equally distanced to A/B, it's at offset 24. Similarly TC port (5/6) clk off bits are at offset 22/23. Extend the macros to cover the additional ports. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-4-lucas.demarchi@intel.com
-
Mahesh Kumar authored
Bit definitions for port-select got changed for TRANS_CLK_SEL & TRANS_DDI_FUNC_CTL registers in TGL. v2 (Lucas): - Nuke TRANS_DDI_PORT_NONE since it's 0: we are already clearing {TGL_,}TRANS_DDI_PORT_MASK (suggested by Ville) - Also cover haswell_get_ddi_port_state() in intel_display.c that was missing - Define macros using the _SHIFT macros so we don't lose other users Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Lucas De Marchi authored
According to the spec when initializing the display in TGL we should not set PORT_CL_DW12 for the Aux channel of the combo PHYs. We will re-use the power well hooks from ICL so only set this register on gen < 12. v2: Generalize check for gen 12 (suggested by José) v3: Rebase after enum phy introduction Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, RSA signature is located after CSS header and uCode so actual RSA offset in the blob can be easily calculated when needed (and we need it only once). Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, uCode is located right after CSS header, so ucode offset is always same as header size. Signed-off-by:
-
Michal Wajdeczko authored
According to Firmware layout definition, CSS header is located in front of the firmware blob, so header offset is always 0. Similarly, size of the CSS header is constant and currently used version is exactly 128. While here, move type/status enums up and keep them together. v2: use sizeof consistently (Daniele), update commit message Signed-off-by:
-
Chris Wilson authored
Modifying a remote context requires careful serialisation with requests on that context, and that serialisation requires us to take their timeline->mutex. Make it so. Note that while struct_mutex rules, we can't create more than one request in parallel, but that age is soon coming to an end. v2: Though it doesn't affect the current users, contexts may share timelines so check if we already hold the right mutex. Signed-off-by:
-
Michal Wajdeczko authored
We are already storing runtime value of log level in private field, so there is no need to modify modparam. Signed-off-by:
-
Tvrtko Ursulin authored
for_each_engine_masked caches the engine mask but what does the caller know. Cache it explicitly for clarity and while at it correct the type to match. Signed-off-by:
-
Chris Wilson authored
Smatch warning that the loop may be empty causing us to check err before it had been set. Ensure that it is initialised to 0, just in case. v2: Refactor the inner loop for better scooping and clarity Fixes: a9877da2 ("drm/i915/oa: Reconfigure contexts on the fly") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190726131458.8310-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
guc->stage_desc_pool is required as part of the init parameters and there is no reason we have to init them after HuC. This fixes a NULL ptr dereference due to guc->stage_desc_pool not being set (no fixes tag since GuC submission can't be enabled yet). Signed-off-by:
-
Michal Wajdeczko authored
All intel_uc_fw_* functions are taking uc_fw as first param except intel_uc_fw_fetch() which is taking i915. Fix that. Signed-off-by:
-
Chris Wilson authored
Currently we use the engine->active.lock to ensure that the request is not retired as we capture the data. However, we only need to ensure that the vma are not removed prior to use acquiring their contents, and since we have already relinquished our stop-machine protection, we assume that the user will not be overwriting the contents before we are able to record them. In order to capture the vma outside of the spinlock, we acquire a reference and mark the vma as active to prevent it from being unbound. However, since it is tricky allocate an entry in the fence tree (doing so would require taking a mutex) while inside the engine spinlock, we use an atomic bit and special case the handling for i915_active_wait. The core benefit is that we can use some non-atomic methods for mapping the device pages, we can remove the slow compression phase out of atomic context (i.e. stop antagonising the nmi-watchdog), and no we longer need large reserves of atomic pages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111215Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725223843.8971-1-chris@chris-wilson.co.uk
-
- 25 Jul, 2019 11 commits
-
-
Michal Wajdeczko authored
Generic uc firmware layout definitions are unlikely to change and are separate to other GuC specific definitions. v2: reordered Signed-off-by:
-
Michal Wajdeczko authored
Sphinx was rendering firmware layout as html table, but since we want to add sizes relations switch to plain text graphics. v2: also update text and do it before move (Daniele) Signed-off-by:
-
Michal Wajdeczko authored
We moved GuC related files to new location but we missed to update .rst file with links. References: commit 0f261b24 ("drm/i915/uc: move GuC and HuC files under gt/uc/") Signed-off-by:
-
Daniele Ceraolo Spurio authored
The way we load the firmwares is the same for both GuC and HuC, the only difference is in the wopcm destination address and the dma flags, so we easily can move the logic to a common function and pass in offset and flags. The only other difference in the uplaod path are some the extra steps that guc does before and after the xfer, but those don't require the guc fw to be pinned in ggtt and can safely be performed before calling the uc_upload function. Note that this patch re-introduces the dma xfer wait for guc loading that was removed with "drm/i915/guc: Propagate the fw xfer timeout". This is not going to slow us down on a successful load (the dma has to complete before fw init can start), but could slightly increase the timeout in case of a fw init error. v2: use _fw variants for uncore accesses (Chris), fix guc_fw status on failed wait. v3: use dev_err and print DMA_CTRL (Chris) Signed-off-by: -
Daniele Ceraolo Spurio authored
The gt is our new central structure for uc-related code, so we can use that instead of jumping back to i915 via the fw object. Since we have it in the upload function it is easy to pass it through the lower levels of the xfer process instead of continuosly jumping via uc_fw->uc->gt, which will also make things a bit cleaner for the next patch. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The binary is perma-pinned and the rsa is not going to change, so copy it only once and not on every load. v2: onion unwind (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
The way we copy the RSA is the same for GuC and HuC, so we can move the logic in a common function. this will also make any update needed for local memory easier. v2: return the number of copied bytes and check it (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
We currently track fetch and load status separately, but the 2 are actually sequential in the uc lifetime (fetch must complete before we can attempt the load!). Unifying the 2 variables we can better follow the sequential states and improve our trackng of the uC state. Also, sprinkle some GEM_BUG_ON to make sure we transition correctly between states. v2: rename states, add the running state (Michal), drop some logs in the fetch path (Michal, Chris) v3: re-rename states, extend early status check to all helpers (Michal) Suggested-by: -
Daniele Ceraolo Spurio authored
Instead of having 2 identical functions for GuC and HuC firmware selection, we can unify the selection logic and just use different lists based on FW type. Note that the revid is not relevant for current blobs, but the upcoming CML will be identified as CFL rev 5, so by considering the revid we're ready for that. v2: rework blob list defs (Michal), add order check (Chris), fuse GuC and HuC lists into one. v3: remove difference between no uC HW and no uC FW, simplify related selection code, check the whole fw list (Michal) Signed-off-by: -
Daniele Ceraolo Spurio authored
There are 2 issues around handling of missing uC support: - We treat lack of uC HW and lack of uC FW definition as 2 different cases, but both of them mean that we don't support the uC on the platform we're running on. - We rely on the modparam to decide if we can take uC paths or not, but we don't sanitize it if it is set incorrectly on platform with no uC support. To fix both of them, unify the 2 cases in a single one and sanitize the modparam on invalid configuration (after printing an error message). The log has been adapted as well, since the user doesn't care why we don't support GuC/HuC (no HW or no FW), just that we do not. Developers can easily find the answer based on the platform, so we can simplify the log. Correcting the modparam has been preferred over failing the load since this is what we usually do for non-supported feature (e.g. the now gone enable_ppgtt would fall back to the highest supported PPGTT mode if the selected one was not available). Note that this patch purposely doesn't change the behavior for platforms that do have uC support, in which case we will still fail if enable_guc is set and the firmware is not available on the system. Suggested-by:
-
Daniele Ceraolo Spurio authored
We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC and HAS_HUC, with only 1 exception. Since our HW always has either both uC or neither of them, just replace all the checks with a unified HAS_UC. v2: use HAS_GT_UC (Michal) v3: fix comment (Michal) Signed-off-by:
-
- 24 Jul, 2019 1 commit
-
-
Daniele Ceraolo Spurio authored
All the GuC objects are perma-pinned, so their offset can't change at runtime. We can therefore set (and log!) the parameters only once during boot. Suggested-by:
-
- 23 Jul, 2019 3 commits
-
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Fix botched refactoring of the code that uncorrectly split a check on a bool, treating it as a u32. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 84b1ca2f ("drm/i915/uc: prefer intel_gt over i915 in GuC/HuC paths") Signed-off-by:
-
Chris Wilson authored
If the system is already idle, omit the GEM_TRACE saying we are about to wait for idle. It looks confusing in the logs to see a continual stream of wait-for-idle, as one immediately assumes it is stuck in a loop. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723091218.5886-1-chris@chris-wilson.co.uk
-
