- 08 Jul, 2020 14 commits
-
-
Venkata Sandeep Dhanalakota authored
SSEUs are a GT capability, so track them under gt_info. Signed-off-by:
Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Keep all the SSEU code in the relevant file. The code has also been updated to use intel_gt instead of dev_priv. Based on an original patch by Sandeep. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
We already call 2 gt-related init_mmio functions in driver_mmio_probe and a 3rd one will be added by a follow-up patch, so pre-emptively introduce a gt_init_mmio function to group them. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Since the engines belong to the GT, move the runtime-updated list of available engines to the intel_gt struct. The original mask has been renamed to indicate it contains the maximum engine list that can be found on a matching device. In preparation for other info being moved to the gt in follow up patches (sseu), introduce an intel_gt_info structure to group all gt-related runtime info. v2: s/max_engine_mask/platform_engine_mask (tvrtko), fix selftest Signed-off-by:
-
Daniele Ceraolo Spurio authored
All the info we read in intel_device_info_init_mmio are engine-related and since we already have an engine_init_mmio function we can just perform the operations from there. v2: clarify comment about forcewake requirements and pruning (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
A follow up patch will move the engine mask under the gt structure, so get ready for that. v2: switch the remaining gvt case using dev_priv->gt to gvt->gt (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
Use intel_<uncore/de>_read instead of I915_READ to read the informational registers. Extended from an original sseu-only patch by Sandeep. Signed-off-by:
-
Manasi Navare authored
Based on the platform, Bspec expects us to wait or poll with timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active after enabling DDI_BUF_CTL. v2: * Based on platform, fixed delay or poll (Ville) * Use a helper to do this (Imre, Ville) v3: * Add a new function _active for DDI BUF CTL to be non idle (Ville) v4: * Use the timeout for GLK (Ville) v5: * Add bspec quote, change timeout to 500us (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701221052.8946-2-manasi.d.navare@intel.com
-
Manasi Navare authored
Modify the helper to add a fixed delay or poll with timeout based on platform specification to check for either Idle bit set (DDI_BUF_CTL is idle for disable case) v2: * Use 2 separate functions or idle and active (Ville) v3: * Change the timeout to 16usecs (Ville) v4: * Change the timeout 8, follow spec (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Michał Winiarski authored
Firmware "Selected" state is a transient state - we don't expect to see it after finishing driver probe, we even have asserts sprinkled over i915 to confirm whether that's the case. Unfortunately - we don't handle the transition out of "Selected" in case of GuC fetch error, leading those asserts to fire when calling "intel_huc_is_used()". v2: Add dbg print when moving HuC into error state (Daniele) Reported-by:
Marcin Bernatowicz <marcin.bernatowicz@intel.com> 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: Marcin Bernatowicz <marcin.bernatowicz@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Michał Winiarski authored
It has been pointed out that information about HuC usage doesn't belong in guc_info debugfs. Let's move "supported/used/wanted" matrix to a separate debugfs file, keeping guc_info strictly about GuC. Suggested-by:
-
Ramalingam C authored
drm_hdcp_check_ksvs_revoked() returns the number of revoked keys and error codes when the SRM parsing is failed. Errors in SRM parsing can't affect the HDCP auth, hence with this patch, I915 will look out for revoked key count alone. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200429134555.22106-1-ramalingam.c@intel.com
-
Anshuman Gupta authored
Content Protection property should be updated as per the kernel internal state. Let's say if Content protection is disabled by userspace, CP property should be set to UNDESIRED so that reauthentication will not happen until userspace request it again, but when kernel disables the HDCP due to any DDI disabling sequences like modeset/DPMS operation, kernel should set the property to DESIRED, so that when opportunity arises, kernel will start the HDCP authentication on its own. Somewhere in the line, state machine to set content protection to DESIRED from kernel was broken and IGT coverage was missing for it. This patch fixes it. v2: - Fixing hdcp CP state in connector atomic check function intel_hdcp_atomic_check(). [Maarten] This will require to check hdcp->value in intel_hdcp_update_pipe() in order to avoid enabling hdcp, if it was already enabled. v3: - Rebased. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/350962/?series=72664&rev=2 #v1 Link: https://patchwork.freedesktop.org/patch/359396/?series=72251&rev=3 #v2 Reviewed-by:
-
José Roberto de Souza authored
Two new PCI ids added to ehl. v2: added two additional PCI ids BSpec: 29153 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200707204530.42289-1-jose.souza@intel.com
-
- 07 Jul, 2020 3 commits
-
-
José Roberto de Souza authored
This is new step that was recently added to the combo phy initialization. v2: - using intel_de_rmw() v3: - going back to read() modify and write() as group register can't be read BSpec: 49291 Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Chris Wilson authored
Looking through the attributes for DMA mappings, it appears that by default dma_map_sg will try and create a kernel accessible map of the page. We never access this, as we either have a struct page already or an iomap, so we can request that the dma mapper does not create one. Without a kernel map in place, one presumes the rest of the memory control attributes do not apply. We also explicitly control the caches around the mappings, so we can ask it not to bother synchronising itself. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200706224308.22636-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
On eviction, we acquire the vm->mutex and then wait on the vma->active. Therefore when binding and pinning the vma, we must follow the same sequence, lock/pin the vma then mark it active. Otherwise, we mark the vma as active, then wait for the vm->mutex, and meanwhile the evictor holding the mutex waits upon us to complete our activity. Fixes: 8ccfc20a ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by:
-
- 06 Jul, 2020 5 commits
-
-
Flavio Suligoi authored
Fix typo: "TRIGER" --> "TRIGGER" The two misplelled macros: 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK are not used in any other sources of the kernel, so this change can be consider only a local change for the i915_reg.h file. Signed-off-by:
Flavio Suligoi <f.suligoi@asem.it> Reviewed-by:
-
Michał Winiarski authored
It is not really unexpected to hit wedge on init this way. We're already downgrading error printk when running with fault injection, let's use the same approach for CI tainting. v2: Don't check fault inject in trace dump (Chris) Signed-off-by:
-
Michał Winiarski authored
We can add taint from multiple places, printing the caller allows us to have a better overview of what exactly caused us to do the tainting. v2: Tweak format and print the device (Chris) v3: Move things around (Chris) Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Michał Winiarski authored
Getting wedged device on driver init is pretty much unrecoverable. Since we're running various scenarios that may potentially hit this in CI (module reload / selftests / hotunplug), and if it happens, it means that we can't trust any subsequent CI results, we should just apply the taint to let the CI know that it should reboot (CI checks taint between test runs). v2: Comment that WEDGED_ON_INIT is non-recoverable, distinguish WEDGED_ON_INIT from WEDGED_ON_FINI (Chris) v3: Appease checkpatch, fixup search-replace logic expression mindbomb in assert (Chris) Signed-off-by: -
Matt Atwood authored
The initial CI results did not include a TGL system which includes a panel that is having issues with patch. Revert while we triage. This reverts commit 680c45c7. Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
-
- 03 Jul, 2020 9 commits
-
-
Chris Wilson authored
Reuse the ppgtt_bind_vma() for aliasing_ppgtt_bind_vma() so we can reduce some code near-duplication. The catch is that we need to then pass along the i915_address_space and not rely on vma->vm, as they differ with the aliasing-ppgtt. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200703102519.26539-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Normally i85x/i865 3D activity will block FBC until a 2D blit occurs. I suppose this was meant to avoid recompression while 3D activity is still going on but the frame hasn't yet been presented. Unfortunately that also means that a page flipped 3D workload will permanently block FBC even if it only renders a single frame and then does nothing. Since we are using software render tracking anyway we might as well flip the chicken bit so that 3D does not block FBC. This will avoid the permament FBC blockage in the aforemention use case, but thanks to the software tracking the compressor will not disturb 3D rendering activity. Signed-off-by:
-
Ville Syrjälä authored
Unlike all the other pre-snb desktop platforms i865 actually supports FBC. Let's enable it. Quote from the spec: "DevSDG provides the same Run-Length Encoded Frame Buffer Compression (RLEFBC) function as exists in DevMGM." As i865 only has the one pipe we want to skip massaging the plane<->pipe assignment aimed at getting FBC+LVDS working on the mobile platforms. Signed-off-by:
-
Ville Syrjälä authored
The MSG_FBC_REND_STATE register only exists on snb+. For older platforms (would also work for snb+) we can simply rewite DSPSURF to trigger a flip nuke. While generally RMW is considered harmful we'll use it here for simplicity. And since FBC doesn't exist in i830 we don't have to worry about the DSPSURF double buffering hardware fails present on that platform. Signed-off-by:
-
Ville Syrjälä authored
Consult the actual plane stride instead of the fb stride. The two will disagree when we remap the gtt. The plane stride is what the hw will be fed so that's what we should look at for the FBC retrictions/cfb allocation. Since we no longer require a fence we are going to attempt using FBC with remapping, and so we should look at correct stride. With 90/270 degree rotation the plane stride is stored in units of pixels, so we need to conver it to bytes for the purposes of calculating the cfb stride. Not entirely sure if this matches the hw behaviour though. Need to reverse engineer that at some point... We also need to reorder the pixel format check vs. stride check to avoid triggering a spurious WARN(stride & 63) with cpp==1 and plane stride==32. v2: Try to deal with rotated stride and related WARN Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 691f7ba5 ("drm/i915/display/fbc: Make fences a nice-to-have for GEN9+") Signed-off-by:
-
Stanislav Lisovskiy authored
We still need "Bump up CDCLK" workaround otherwise getting underruns - however currently it blocks 8K as CDCLK = Pixel rate, in 8K case would require CDCLK to be around 1 Ghz which is not possible. v2: - Convert to expression(max(min_cdclk, min(pixel_rate, max_cdclk)) (Ville Syrjälä) - Use type specific min_t, max_t(Ville Syrjälä) Fixes: 46d53e27 ("Revert "drm/i915: Remove unneeded hack now for CDCLK"") Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702091526.10096-1-stanislav.lisovskiy@intel.com
-
Michał Winiarski authored
The information about platform/driver/user view of GuC firmware usage currently requires user to either go through kernel log or parse the combination of "enable_guc" modparam and various debugfs entries. Let's keep things simple and add a "supported/used/wanted" matrix (already used internally by i915) in guc_info debugfs. Signed-off-by:
Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Since gen8 we don't use swizzle anymore. Don't dump registers related to it: registers may or may not be there. v2: pull the rest of driver state reporting before the read out (Chris) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Chris Wilson authored
Rather than reuse the common ctx->mutex for locking the execbuffer LUT, split it into its own lock to avoid being taken [as part of ctx->mutex] at inappropriate times. In particular to avoid the inversion from taking the timeline->mutex for the whole execbuf submission in the next patch. Signed-off-by:
-
- 02 Jul, 2020 9 commits
-
-
Chris Wilson authored
Not only do we need to release the vm.ref we acquired for the vma on the duplicate insert branch, but also for the normal error paths, so roll them all into one. Reported-by:
-
Chris Wilson authored
Since we no longer always take struct_mutex around everything, and want the freedom to create GEM objects, actually taking struct_mutex inside the lock creation ends up pulling the mutex inside other looks. Since we don't use generally use struct_mutex, we can relax the tainting. Signed-off-by:
-
Chris Wilson authored
Avoid waking up the device and taking stale locks if we know that the object is not currently mmapped. This is particularly useful as not many object are actually mmapped and so we can destroy them without waking the device up, and gives us a little more freedom of workqueue ordering during shutdown. v2: Pull the release_mmap() into its single user in freeing the objects, where there can not be any race with a concurrent user of the freed object. Or so one hopes! Signed-off-by:
-
Chris Wilson authored
Only a GGTT mmapping will use the aperture detiling registers, so on a tiling change for an object, we only need to revoke those mmappings and not the CPU mmappings (which are always linear irrespective of the tiling). Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702163623.6402-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
We have a mix of dport, intel_dport, intel_dig_port and dig_port to reference a intel_digital_port struct. Numbers are around 5 intel_dport 36 dport 479 intel_dig_port 352 dig_port Since we already removed the intel_ prefix from most of our other structs, do the same here and prefer dig_port. v2: rename everything in i915, not just a few display sources and reword commit message (from Matt Roper) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701045054.23357-1-lucas.demarchi@intel.com
-
Jani Nikula authored
Signed-off-by: -
Chris Wilson authored
As we allow for parallel threads to create the same vma instance concurrently, and we only filter out the duplicates upon reacquiring the spinlock for the rbtree, we have to free the loser of the constructors' race. When freeing, we should also drop any resource references acquired for the redundant vma. Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by:
-
Chris Wilson authored
As we ensure that the heartbeat is reasonably fast (and should not block), move the heartbeat work into the system_highpri_wq to avoid having this essential task be blocked behind other slow work, such as our own retire_work_handler. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2119Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702095219.963-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the driver gets stuck holding the kernel timeline, we cannot issue a heartbeat and so fail to discover that the driver is indeed stuck and do not issue a GPU reset (which would hopefully unstick the driver!). Switch to using a trylock so that we can query if the heartbeat's timeline mutex is locked elsewhere, and then use the timer to probe if it remains stuck at the same spot for consecutive heartbeats, indicating that the mutex has not been released and the engine has not progressed. Signed-off-by:
-
