- 08 Jul, 2020 7 commits
-
-
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:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708100843.297655-2-michal@hardline.pl
-
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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702083225.20044-1-chris@chris-wilson.co.uk
-
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:
-
- 01 Jul, 2020 7 commits
-
-
Matt Atwood authored
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to use before encoder_type is set. This caused GEN11+ to incorrectly strip HBR3 from source rates for edp. Move intel_dp_set_source_rates() to after encoder_type is set. Add comment to intel_dp_is_edp() describing unsafe usages. v2: Alter intel_dp_set_source_rates final position (Ville/Manasi). Remove outdated comment (Ville). Slight optimization of control flow in intel_dp_init_connector. Slight rewording in commit message. Signed-off-by: -
Ville Syrjälä authored
'level' here means the highest level we can't use, so when checking the fbc watermarks we need a -1 to get at the last enabled level. While at if refactor the code a bit to declutter g4x_compute_pipe_wm(). Signed-off-by:
-
Imre Deak authored
To simplify things, call the combo PHY/TBT PLL calculation functions directly from the corresponding combo/TypeC PLL get functions, instead of calling the same calculation functions after having to recheck if the given PHY is combo or TypeC. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
When the reference clock is 38.4MHz, using the current TBT PLL fractional divider value results in a slightly off TBT link frequency. This causes an endless loop of link training success followed by a bad link signaling and retraining at least on a Dell WD19TB TBT dock. The workaround provided by the HW team is to divide the fractional divider value by two. This fixed the link training problem on the ThinkPad dock. The same workaround is needed on some EHL platforms and for combo PHY PLLs, these will be addressed in a follow-up. Bspec: 49204 References: HSDES#22010772725 References: HSDES#14011861142 Reported-and-tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by:
-
Chris Wilson authored
The obj->lut_list is traversed when the object is closed as the file table is destroyed during process termination. As this occurs before we kill any outstanding context if, due to some bug or another, the closure is blocked, then we fail to shootdown any inflight operations potentially leaving the GPU spinning forever. As we only need to guard the list against concurrent closures and insertions, the hold is short and merits being treated as a simple spinlock. Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701084439.17025-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
We don't need intel_dig_port and dig_port to refer to the same thing. Prefer the latter. v2: fix coding style Signed-off-by:
-
José Roberto de Souza authored
This registers will be used to implement PSR2 manual tracking/selective fetch. v2: - Fixed typo in _PLANE_SEL_FETCH_BASE - Renamed PSR2_MAN_TRK_CTL bits to better match spec names - Renamed _PLANE_SEL_FETCH_* to better match spec names BSpec: 55229 BSpec: 50424 BSpec: 50420 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-3-jose.souza@intel.com
-
