- 03 Jul, 2020 7 commits
-
-
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702153723.24327-4-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
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:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-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:
Michał Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200701142752.419878-1-michal@hardline.pl
-
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:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200703004306.11117-1-chris@chris-wilson.co.uk
-
- 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 9 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:Matt Atwood <matthew.s.atwood@intel.com> Reviewed-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:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626234834.26864-2-lucas.demarchi@intel.com
-
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
-
José Roberto de Souza authored
Future patches will bring PSR2 selective fetch configuration validation but most of the configuration checks will be used for HW tracking and selective fetch so the reoder was necessary. Reviewed-by:
-
José Roberto de Souza authored
This property will be used by PSR2 software tracking, adding it to GEN12+. Reviewed-by:
-
- 30 Jun, 2020 11 commits
-
-
Chris Wilson authored
Rearrange the allocation of the mm_struct registration to avoid allocating underneath the i915->mm_lock, so that we avoid tainting the lock (and in turn many other locks that may be held as i915->mm_lock is taken, and those locks we may want on the free [shrinker] paths). In doing so, we convert the lookup to be RCU protected by courtesy of converting the free-worker to be an rcu_work. v2: Remember to use hash_rcu variants to protect the list iteration from concurrent add/del. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619194038.5088-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Often we seem to detect an underrun right after modeset on gen2. It seems to be a spurious detection (potentially the pipe is still in a wonky state when we enable the planes). An extra vblank wait seems to cure it. Signed-off-by:
-
Ville Syrjälä authored
The default fbc1 compression interval we use is 500 frames. That translates to over 8 seconds typically. That's rather excessive so let's drop it to 1 second. The hardware will not attempt recompression unless at least one line has been modified, so a shorter compression interval should not cause extra bandwidth use in the purely idle scenario. Of course in the mostly idle case we are possibly going to recompress a bit more. Should really try to find some kind of sweet spot to minimize the energy usage... Signed-off-by:
-
Ville Syrjälä authored
Avoid the FBC_CONTROL rmw and just store the fbc compression interval in the params/ Signed-off-by:
-
Ville Syrjälä authored
Parametrize the FBC_CONTROL bits for neater code. Also add the one missing bit: "stop compression on modification". Signed-off-by:
-
Ville Syrjälä authored
The hardware host tracking won't nuke the entire cfb (unless the entire fb is written through the gtt) so don't clear the busy_bits for gtt tracking. Not that it really matters anymore since we've lost ORIGIN_GTT usage everywhere. Signed-off-by:
-
Ville Syrjälä authored
The current fence_y_offset calculation is broken. I think it more or less used to do the right thing, but then I changed the plane code to put the final x/y source offsets back into the src rectangle so now it's just subtraacting the same value from itself. The code would never have worked if we allowed the framebuffer to have a non-zero offset. Let's do this in a better way by just calculating the fence_y_offset from the final plane surface offset. Note that we don't align the plane surface address to fence rows so with horizontal panning there's often a horizontal offset from the fence start to the surface address as well. We have no way to tell the hardware about that so we just ignore it. Based on some quick tests the invlidation still happens correctly. I presume due to the invalidation nuking at least the full line (or a segment of multiple lines). Fixes: 54d4d719 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by:
-
Chris Wilson authored
As we close a handle GEM object, we update the drm_file's idr with an error^W NULL pointer to indicate the in-progress closure, and finally removing it. If we read the idr directly, we may then see an invalid object pointer, and in our debugfs per_file_stats() we therefore need to protect against the entry being invalid. [ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e [ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73 [ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293 [ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002 [ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8 [ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0 [ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000 [ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001 [ 1016.651676] FS: 00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000 [ 1016.651680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0 [ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1016.651693] Call Trace: [ 1016.651693] Call Trace: [ 1016.651703] idr_for_each+0x8a/0xe8 [ 1016.651711] i915_gem_object_info+0x2a3/0x3eb [ 1016.651720] seq_read+0x162/0x3ca [ 1016.651727] full_proxy_read+0x5b/0x8d [ 1016.651733] __vfs_read+0x45/0x1bb [ 1016.651741] vfs_read+0xc9/0x15e [ 1016.651746] ksys_read+0x7e/0xde [ 1016.651752] do_syscall_64+0x54/0x68 [ 1016.651758] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by:
Guenter Roeck <linux@roeck-us.net> Fixes: a8c15954 ("drm/i915: Protect debugfs per_file_stats with RCU lock") Signed-off-by:
-
Colin Ian King authored
Currently there is no null check for a failed memory allocation on the dsb object and without this a null pointer dereference error can occur. Fix this by adding a null check. Note: added a drm_err message in keeping with the error message style in the function. Addresses-Coverity: ("Dereference null return") Fixes: afeda4f3 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
There are a couple of spelling mistakes in kernel parameter help text, namely "helpfull" and "paramters". Fix them. Signed-off-by:
-
Oliver Barta authored
A single Ri mismatch doesn't automatically mean that the link integrity is broken. Update and check of Ri and Ri' are done asynchronously. In case an update happens just between the read of Ri' and the check against Ri there will be a mismatch even if the link integrity is fine otherwise. Signed-off-by:
Oliver Barta <oliver.barta@aptiv.com> Reviewed-by:
Sean Paul <sean@poorly.run> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
-
- 29 Jun, 2020 1 commit
-
-
Ville Syrjälä authored
The linetime watermark is a 9 bit value, which gives us a maximum linetime of just below 64 usec. If the linetime exceeds that value we currently just discard the high bits and program the rest into the register, which angers the state checker. To avoid that let's just clamp the value to the max. I believe it should be perfectly fine to program a smaller linetime wm than strictly required, just means the hardware may fetch data sooner than strictly needed. We are further reassured by the fact that with DRRS the spec tells us to program the smaller of the two linetimes corresponding to the two refresh rates. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
- 26 Jun, 2020 2 commits
-
-
Matt Atwood authored
Update code to reflect recent bspec changes Bspec: 52890 Bspec: 53508 Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Matt Roper authored
This workaround now also applies to TGL and RKL, so extend the PCH test to just capture everthing ICP and beyond. Signed-off-by:
-
- 25 Jun, 2020 1 commit
-
-
Ville Syrjälä authored
The DP spec says: "The transmitter shall support at least three levels of voltage swing (Levels 0, 1, and 2). If only three levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 10 (Level 2)), this bit shall be set to 1, and cleared in all other cases. If all four levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 11 (Level 3)), this bit shall be set to 1,and cleared in all other cases." Let's follow that exactly instead of the current apporach where we can set those also for vswing/preemph levels 0 or 1 (or 2 when the platform max is 3). Signed-off-by:
-
