summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-intel-next-2020-07-02' of ↵Dave Airlie2020-07-03150-3345/+6035
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v5.9 Highlights: - Rocket Lake (RKL) platform enabling (Matt Roper, Lucas, José, Aditya) Gem/GT: - Numerous selftest fixes and improvements (Chris) - TGL, RKL, EHL workaround updates (Matts Atwood and Roper, Clint, Swathi Dhanavanthri, Chris) - Retry faulthandlers on ENOSPC to avoid oomkiller (Chris) - Numerous refactorings and cleanups (Chris) - Several GT fixes around init/suspend/resume/shutdown (Chris) - Whitelist CTX_TIMESTAMP register on non-RCS (Chris) - Track if an engine requires forcewake w/a (Chris) - Locking improvements (Chris) - Timeslicing improvements (Chris) - Add a safety submission flush in the heartbeat (Chris) - Flush gen3 relocs harder (Chris) - Discard a misplaced GGTT vma (Chris) - Reduce relocation paths to async GPU relocations only (Chris) - It's all build up with no pay off (Chris' own words...) Display: - A plethora of DP MST fixes (Imre) - Implement proper dbuf global state (Ville) - Consider dbuf bandwidth when calculating CDCLK (Stan) - FBC fixes and refactoring (Ville) - PSR fixes and improvements (José, Gwan-gyeong) - Cursor size fixes (Ville) - Overlay color and gamma fixes (Ville) - Fix and improve FSB and HRAWCLK read out (Ville) - Pre allocate and late cleanup of DSB cmd buffer (Animesh) - Stop using mode->private_flags (Ville) - Add plane color encoding support for YCBCR_BT2020 (Kishore Kadiyala) - Update TGL Type-C DP and DKL HBR and HBR+ vswing tables (José) - Fix DSI connector init error path (Vivek) - A plethora of DP vswing/preemph fixes and refactoring (Ville) - Fix TGL DKL vswing sequence selection (Vandita) - Fix ICL hotplug interrupt disabling after storm detection (Imre) - Retry HDCP link integrity check on failure (Oliver Barta) - Fix TBT DPLL fractional divider (Imre) - Fix ICL+ HBR3 source rate (Matt Atwood) - Fix gen2 spurious underruns (Ville) - Fix potential NULL dereference, some spelling fixes (Colin Ian King) - Fix NULL dereference on encoder state probe (Chris) Other: - Backmerge to get mmap locking API (Jani) - Distinguish Comet Lake from Coffee Lake (Chris) - Various compiler warning fixes (Arnd Bergmann, Nathan Chancellor) - WARN* conversions to drm_WARN* (Pankaj) - Switch to device specific parameters with debugfs access (Jani) - Fix agp/intel error path leak (Qiushi Wu) - Forcewake power optimization (Chris) - Irq handler optimization (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87wo3lkbxt.fsf@intel.com
| * drm/i915: Update DRIVER_DATE to 20200702Jani Nikula2020-07-021-2/+2
| | | | | | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Drop vm.ref for duplicate vma on constructionChris Wilson2020-07-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702083225.20044-1-chris@chris-wilson.co.uk
| * drm/i915/gt: Move the heartbeat into the high priority system wqChris Wilson2020-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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/2119 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702095219.963-2-chris@chris-wilson.co.uk
| * drm/i915/gt: Harden the heartbeat against a stuck driverChris Wilson2020-07-022-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702095219.963-1-chris@chris-wilson.co.uk
| * drm/i915/dp: Correctly advertise HBR3 for GEN11+Matt Atwood2020-07-021-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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ä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630233310.10191-1-matthew.s.atwood@intel.com
| * drm/i915: Fix g4x fbc watermark enableVille Syrjälä2020-07-011-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | '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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-12-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/icl+: Simplify combo/TBT PLL calculation call-chainImre Deak2020-07-011-37/+27
| | | | | | | | | | | | | | | | | | | | | | 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: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629185848.20550-2-imre.deak@intel.com
| * drm/i915/tgl+: Fix TBT DPLL fractional divider for 38.4MHz ref clockImre Deak2020-07-011-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Imre Deak <imre.deak@intel.com> Reviewed-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200629185848.20550-1-imre.deak@intel.com
| * drm/i915/gem: Move obj->lut_list under its own lockChris Wilson2020-07-014-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701084439.17025-1-chris@chris-wilson.co.uk
| * drm/i915/display: remove alias to dig_portLucas De Marchi2020-07-011-6/+5
| | | | | | | | | | | | | | | | | | | | | | 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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626234834.26864-2-lucas.demarchi@intel.com
| * drm/i915: Add PSR2 selective fetch registersJosé Roberto de Souza2020-07-011-5/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-3-jose.souza@intel.com
| * drm/i915: Reorder intel_psr2_config_valid()José Roberto de Souza2020-07-011-25/+25
| | | | | | | | | | | | | | | | | | | | 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: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-2-jose.souza@intel.com
| * drm/i915: Add plane damage clips propertyJosé Roberto de Souza2020-07-012-0/+8
| | | | | | | | | | | | | | | | | | This property will be used by PSR2 software tracking, adding it to GEN12+. Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200626010151.221388-1-jose.souza@intel.com
| * drm/i915/gem: Avoid kmalloc under i915->mm_lockChris Wilson2020-06-302-68/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619194038.5088-1-chris@chris-wilson.co.uk
| * drm/i915: Suppress spurious underruns on gen2Ville Syrjälä2020-06-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/fbc: Reduce fbc1 compression interval to 1 secondVille Syrjälä2020-06-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-11-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/fbc: Store the fbc1 compression interval in the paramsVille Syrjälä2020-06-302-7/+8
| | | | | | | | | | | | | | | | | | Avoid the FBC_CONTROL rmw and just store the fbc compression interval in the params/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/fbc: Parametrize FBC_CONTROLVille Syrjälä2020-06-302-11/+15
| | | | | | | | | | | | | | | | | | | | Parametrize the FBC_CONTROL bits for neater code. Also add the one missing bit: "stop compression on modification". Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-9-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/fbc: Don't clear busy_bits for origin==GTTVille Syrjälä2020-06-301-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
| * drm/i915/fbc: Fix fence_y_offset handlingVille Syrjälä2020-06-304-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 54d4d719fa11 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
| * drm/i915: Skip stale object handle for debugfs per-file-statsChris Wilson2020-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: a8c15954d64a ("drm/i915: Protect debugfs per_file_stats with RCU lock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630152724.3734-1-chris@chris-wilson.co.uk
| * drm/i915/display: fix missing null check on allocated dsb objectColin Ian King2020-06-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: afeda4f3b1c8 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616114221.73971-1-colin.king@canonical.com
| * drm/i915: fix a couple of spelling mistakes in kernel parameter help textColin Ian King2020-06-301-2/+2
| | | | | | | | | | | | | | | | | | There are a couple of spelling mistakes in kernel parameter help text, namely "helpfull" and "paramters". Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616082129.65517-1-colin.king@canonical.com
| * drm/i915: HDCP: retry link integrity check on failureOliver Barta2020-06-301-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504123524.7731-1-oliver.barta@aptiv.com
| * drm/i915: Clamp linetime wm to <64usecVille Syrjälä2020-06-291-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200625200003.12436-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
| * drm/i915/gen12: implement Wa_14011508470Matt Atwood2020-06-272-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | Update code to reflect recent bspec changes Bspec: 52890 Bspec: 53508 Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200624215723.2316-1-matthew.s.atwood@intel.com
| * drm/i915: Extend Wa_14010685332 to all ICP+ PCH'sMatt Roper2020-06-261-4/+2
| | | | | | | | | | | | | | | | | | This workaround now also applies to TGL and RKL, so extend the PCH test to just capture everthing ICP and beyond. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617180006.4130501-1-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
| * drm/i915: Fix DP_TRAIN_MAX_{PRE_EMPHASIS,SWING}_REACHED handlingVille Syrjälä2020-06-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512174145.3186-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
| * Merge drm/drm-next into drm-intel-next-queuedJani Nikula2020-06-2515471-323646/+871012
| |\ | | | | | | | | | | | | | | | | | | Catch up with upstream, in particular to get c1e8d7c6a7a6 ("mmap locking API: convert mmap_sem comments"). Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | drm/i915/dp_mst: Enable VC payload allocation after transcoder is enabledImre Deak2020-06-242-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec requires enabling the MST Virtual Channel payload allocation - in a separate step - after the transcoder is enabled, follow this. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200623082411.3889-1-imre.deak@intel.com
| * | drm/i915/dp_mst: Clear the ACT sent flag during encoder disabling tooImre Deak2020-06-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During encoder enabling we clear the flag before starting the ACT sequence and wait for the flag, but the clearing is missing during encoder disabling, add it there too. Since nothing cleared the flag automatically we could've run subsequent disabling steps too early. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-5-imre.deak@intel.com
| * | drm/i915/dp_mst: Clear only the ACT sent flag from DP_TP_STATUSImre Deak2020-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear if the DP_TP_STATUS flags other than the ACT sent flag have some side-effect, so don't clear those; we don't depend on the state of these flags anyway. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-4-imre.deak@intel.com
| * | drm/i915/dp_mst: Move clearing the ACT sent flag closer to its pollingImre Deak2020-06-231-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During transcoder enabling we'll configure the transcoder in MST mode and enable the VC payload allocation, which will start the ACT sequence. Before waiting for the ACT sequence completion, we need to clear the ACT sent flag, but based on the above we can do this right before enabling the transcoder. For clarity, move the flag clearing closer to where we wait for it. While at it also factor out some common code. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616141855.746-3-imre.deak@intel.com
| * | drm/i915/dp_mst: Disable link training fallback on MST linksImre Deak2020-06-231-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the initial probing of an MST sink, MST core will determine the sink's link bandwidth based on its own version of the sink link rate/lane count caps it reads from the DPCD. At a later point (after probing and 1 or more modesets) i915 may limit the link parameters wrt. the original source/sink common caps above due to link training failures during a modeset and the resulting link training fallback logic. Based on the above a modeset following another modeset with a link training error will compute the i915 HW specific and DP protocol timing parameters (data/link M/N and MST TU values) taking into account only the unlimited source/sink common caps, but not taking into account the fallback limits. This will also let DRM core oversubscribe the actual link bandwidth during the MST payload allocation. Prevent the above problem by disabling the link training fallback on MST links for now, until the MST probe time initialization and the MST compute config logic can deal with changing link parameters. The misconfigured timings lead at least to a 'Timed out waiting for DP idle patterns' error. v2: (Ville) - Print link training error message on the MST path too. - Clarify the problem in the commit log. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-2-imre.deak@intel.com
| * | drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encodersImre Deak2020-06-231-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MST encoders must use the master MST transcoder's DP_TP_STATUS and DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder connected to a slave transcoder we reset these register addresses in intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register addresses incorrectly; fix this. One example where the above overwite happens is the encoder HW state validation after enabling multiple streams; see intel_dp_mst_enc_get_config(). After that during disabling any stream we'll get a 'Timed out waiting for ACT sent when disabling' error, due to reading from the incorrect DP_TP_STATUS register. This change replaces https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1 which just papered over the problem. v2: - Correct the failure scenario in the commit log. (José) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-1-imre.deak@intel.com
| * | drm/i915/params: switch to device specific parametersJani Nikula2020-06-2230-109/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
| * | drm/i915/gt: Replace manual kmap_atomic() with pin_map for renderstateChris Wilson2020-06-201-20/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only emit the renderstate once now during module load, it is no longer a concern that we are delaying context creation and so do not need to so eagerly optimise. Since the last time we have looked at the renderstate, we have a pin_map / flush_map facility that supports simple single mappings, replacing the open-coded kmap_atomic() and prepare_write. As it should be a single page, of which we only write a small portion, we stick to a simple WB [kmap] and use clflush on !llc platforms, rather than creating a temporary WC vmapping for the single page. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619234543.17499-2-chris@chris-wilson.co.uk
| * | drm/i915/gvt: Drop redundant prepare_write/pin_pagesChris Wilson2020-06-203-52/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since gvt calls pin_map for the shadow batch buffer, this makes the action of prepare_write [+pin_pages] redundant. We can write into the obj->mm.mapping directory and the flush_map routine knows when it has to flush the cpu cache afterwards. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619234543.17499-1-chris@chris-wilson.co.uk
| * | drm/i915/gt: Show the culmative runtime as part of the engine infoChris Wilson2020-06-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since we always enable the busy-stats, the culmulative runtime should be accurate, and might be useful for diagnosing issues with the engine. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619191053.9654-1-chris@chris-wilson.co.uk
| * | drm/i915/gt: Initialise rps timestampChris Wilson2020-06-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Smatch warns that we may iterate over an empty array of gt->engines[]. One hopes that this is impossible, but nevertheless we can simply appease smatch by initialising the timestamp to zero before we starting probing the busy-time from the engines. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619151938.21740-1-chris@chris-wilson.co.uk
| * | drm/i915/query: Use struct_size() helperGustavo A. R. Silva2020-06-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> 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/20200617220331.GA19550@embeddedor
| * | drm/i915/gt: Always report the sample time for busy-statsChris Wilson2020-06-186-44/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Return the monotonic timestamp (ktime_get()) at the time of sampling the busy-time. This is used in preference to taking ktime_get() separately before or after the read seqlock as there can be some large variance in reported timestamps. For selftests trying to ascertain that we are reporting accurate to within a few microseconds, even a small delay leads to the test failing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-2-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Enable selftesting of busy-statsChris Wilson2020-06-188-170/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A couple of very simple tests to ensure that the basic properties of per-engine busyness accounting [0% and 100% busy] are faithful. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-1-chris@chris-wilson.co.uk
| * | drm/i915/selftests: fix spelling mistake "submited" -> "submitted"Colin Ian King2020-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is a spelling mistake in a pr_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.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/20200617085207.167552-1-colin.king@canonical.com
| * | drm/i915/selftests: Check preemption rollback of different ring queue depthsChris Wilson2020-06-171-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like live_unlite_ring, but instead of simply looking at the impact of intel_ring_direction(), check that preemption more generally works with different depths of queued requests in the ring. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616233733.18050-1-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Use friendly request names for live_timeslice_rewindChris Wilson2020-06-171-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than mixing [012] and (A1, A2, B2) for the request indices, use the enums throughout. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616185518.11948-2-chris@chris-wilson.co.uk
| * | drm/i915/selftests: Exercise far preemption rollbacksChris Wilson2020-06-171-0/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not too long ago, we realised we had issues with a rolling back a context so far for a preemption request we considered the resubmit not to be a rollback but a forward roll. This means we would issue a lite restore instead of forcing a full restore, continuing execution of the old requests rather than causing a preemption. Add a selftest to exercise such a far rollback, such that if we were to skip the full restore, we would execute invalid instructions in the ring and hang. Note that while I was able to confirm that this causes us to do a lite-restore preemption rollback (with commit e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding") disabled), it did not trick the HW into rolling past the old RING_TAIL. Myybe on other HW. References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616185518.11948-1-chris@chris-wilson.co.uk
| * | drm/i915: Remove redundant i915_request_await_object in blit clearsTvrtko Ursulin2020-06-161-31/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One i915_request_await_object is enough and we keep the one under the object lock so it is final. At the same time move async clflushing setup under the same locked section and consolidate common code into a helper function. v2: * Emit initial breadcrumbs after aways are set up. (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200615151449.32605-1-tvrtko.ursulin@linux.intel.com
| * | drm/i915: Mark up inline getters as taking a const i915_requestChris Wilson2020-06-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since these inline routines only return the desired pointer from the i915_request(after checking the preconditions for acquiring said pointer), they can be const. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616183139.4061-1-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-11 13:27:10 +0100