- 31 Mar, 2020 4 commits
-
-
José Roberto de Souza authored
DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type and later eDP ports that have the type changed to INTEL_OUTPUT_EDP. But for all other DDI ports it can drive HDMI or DP depending on what user connects to the ports. ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was checking for INTEL_OUTPUT_DP that was never true, causing wrong vswing tables being used. So here replacing the INTEL_OUTPUT_DP checks by the valid output types that this functions receives as parameters. HDMI cases will be correctly handled as it do not use encoder->type, instead it calls the functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't have retraining. v2: changed INTEL_OUTPUT_DDI to INTEL_OUTPUT_EDP and INTEL_OUTPUT_HDMI Fixes: bd3cf6f7 ("drm/i915/dp/tgl+: Update combo phy vswing tables") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20200330210044.130510-1-jose.souza@intel.com
-
Imre Deak authored
The DDI IO power well must not be enabled for a TypeC port in TBT mode, ensure this during driver loading/system resume. This gets rid of error messages like [drm] *ERROR* power well DDI E TC2 IO state mismatch (refcount 1/enabled 0) and avoids leaking the power ref when disabling the output. Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Chris Wilson authored
process_csb: 0000:00:02.0 bcs0: cs-irq head=4, tail=5 process_csb: 0000:00:02.0 bcs0: csb[5]: status=0x00008002:0x60000020 trace_ports: 0000:00:02.0 bcs0: preempted { ff84:45154! prio 2 } trace_ports: 0000:00:02.0 bcs0: promote { ff84:45155* prio 2 } trace_ports: 0000:00:02.0 bcs0: submit { ff84:45156 prio 2 } process_csb: 0000:00:02.0 bcs0: cs-irq head=5, tail=6 process_csb: 0000:00:02.0 bcs0: csb[6]: status=0x00000018:0x60000020 trace_ports: 0000:00:02.0 bcs0: completed { ff84:45155* prio 2 } process_csb: 0000:00:02.0 bcs0: ring:{start:0x00178000, head:0928, tail:0928, ctl:00000000, mode:00000200} process_csb: 0000:00:02.0 bcs0: rq:{start:00178000, head:08b0, tail:08f0, seqno:ff84:45155, hwsp:45156}, process_csb: 0000:00:02.0 bcs0: ctx:{start:00178000, head:e000928, tail:0928}, process_csb: GEM_BUG_ON("context completed before request") In this sequence, we can see that although we have submitted the next request [ff84:45156] to HW (via ELSP[]) it has not yet reported the lite-restore. Instead, we see the completion event of the currently active request [ff84:45155] but at the time of processing that event, the breadcrumb has not yet been written. Though by the time we do print out the debug info, the seqno write of ff84:45156 has landed! Therefore there is a serialisation problem between the seqno writes and CS events, not just between the CS buffer and its head/tail pointers as previously observed on Icelake. This is not a huge problem, as we don't strictly rely on the breadcrumb to determine HW activity, but it may indicate that interrupt delivery is before the seqno write, aka bringing back the plague of missed interrupts from yesteryear. However, there is no indication of this wider problem, so let's just flush the seqno read before reporting an error. If it persists after the fresh read we can worry again. 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/20200330234318.30638-1-chris@chris-wilson.co.uk
-
Lionel Landwerlin authored
Reading or writing those fields should only happen under stream->oa_buffer.ptr_lock. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: d1df41eb ("drm/i915/perf: rework aging tail workaround") Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330091411.37357-1-lionel.g.landwerlin@intel.com
-
- 30 Mar, 2020 9 commits
-
-
Chris Wilson authored
Upon a GPU reset, we copy the default context image over top of the guilty image. This will rollback the CTX_TIMESTAMP register to before our value of ce->runtime.last. Reset both back to 0 so that we do not encounter an underflow on the next schedule out after resume. This should not be a huge issue in practice, as hangs should be rare in correct code. Signed-off-by:
-
Chris Wilson authored
Use a separate array allocation for the execbuf vma, so that we can track their lifetime independently from the copy of the user arguments. With luck, this has a secondary benefit of splitting the malloc size to within reason and avoid vmalloc. The downside is that we might require two separate vmallocs -- but much less likely. In the process, this prevents a memory leak on the ww_mutex error unwind. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1390Signed-off-by:
-
Chris Wilson authored
We wish that the scheduler emit the context modification commands prior to enabling the oa_config, for which we must explicitly inform it of the ordering constraints. This is especially important as we now wait for the final oa_config setup to be completed and as this wait may be on a distinct context to the state modifications, we need that command packet to be always last in the queue. We borrow the i915_active for its ability to track multiple timelines and the last dma_fence on each; a flexible dma_resv. Keeping track of each dma_fence is important for us so that we can efficiently schedule the requests and reprioritise as required. Reported-by:
-
Chris Wilson authored
For conveniences of callers that just want to use an i915_active to track a wide array of concurrent timelines, wrap the base i915_active struct inside a kref. This i915_active will self-destruct after use. Signed-off-by:
-
Chris Wilson authored
Allow some users the discretion to not immediately return on a normal signal. Hopefully, they will opt to use TASK_KILLABLE instead. Signed-off-by:
-
Chris Wilson authored
Allow a bit of leniency for the CPU scheduler to be distracted while we flush the tasklet and so ensure that we always check the status of the request once more before timing out. v2: Wait until the HW acked the submit, and we do any secondary actions for the submit (e.g. timeslices) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330121644.25277-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Add some extra information into trace_ports to help with reviewing correctness. Signed-off-by:
-
Michal Wajdeczko authored
We report HuC status in debugfs using register read, but we missed that on Gen11+ HuC uses different register. Use correct one. While here, correct placement of the colon. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
There might be many reasons why we failed to successfully load and authenticate HuC firmware, but today we only use single error in case of no HuC hardware. Add some more error codes for most common cases (disabled, not installed, corrupted or mismatched firmware). Signed-off-by:
-
- 27 Mar, 2020 15 commits
-
-
Aditya Swarup authored
Add definitions for registers grouped under Transcoder VRR function with necessary bitfields. Bspec: 49268 v2: Use REG_GENMASK, correct tabs/space indentation and move the definitions near the transcoder section.(Jani) v3: Remove unnecessary prefix from bit/mask definitions.(Manasi) v4: Use 'trans' in macro for better readability.(Manasi) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Chris Wilson authored
In what seems remarkably similar to the w/a required to not reload an idle context with HEAD==TAIL, it appears we must prevent the HW from switching to an idle context in ELSP[1], while simultaneously trying to preempt the HW to run another context and a continuation of the idle context (which is no longer idle). We can achieve this by preventing the context from completing while we reload a new ELSP (by applying ring_set_paused(1) across the whole of dequeue), except this eventually fails due to a lite-restore into a waiting semaphore does not generate an ACK. Instead, we try to avoid making the GPU do anything too challenging and not submit a new ELSP while the interrupts + CSB events appear to have fallen behind the completed contexts. We expect it to catch up shortly so we queue another tasklet execution and hope for the best. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1501Signed-off-by:
-
Ville Syrjälä authored
Dump the port sync stat in intel_dump_pipe_config(). Signed-off-by:
Manasi Navare <manasi.d.anavre@intel.com>
-
Ville Syrjälä authored
Clean up the TRANS_DDI_FUNC_CTL2 programming/readout by using REG_FIELD_PREP() & co. Signed-off-by:
-
Ville Syrjälä authored
Move the port sync readout into the DDI code where it belongs. Signed-off-by:
-
Ville Syrjälä authored
The entire crtc state has been reset before readout so master_transcoder is already set to INVALID. Signed-off-by:
-
Ville Syrjälä authored
This port sync enable/disable stuff is misplaced. It's just another step of the normal TRANS_DDI_FUNC_CTL enable. Move it to its natural place. Signed-off-by:
-
Ville Syrjälä authored
Use the recently introduced encoder .compute_config_late() hook to do the MST master transcoder assignment. Avoids having to do it in a funny way before we know the CPU transcoder of each pipe. And now we can also properly use hw.active instead of uapi.active since it too has been calculated earlier for everyone. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
Userptr causes lockdep to complain when we are using the aliasing-ppgtt (and ggtt, but for that it is rightfully so to complain about) in that when we revoke the userptr we take a mutex which we also use to revoke the mmaps. However, we only revoke mmaps for GGTT bindings and we never allow userptr to create a GGTT binding so the warning should be false and is simply caused by our conflation of the aliasing-ppgtt with the ggtt. So lets try treating the binding into the aliasing-ppgtt as a separate lockclass from the ggtt. The downside is that we are deliberately suppressing lockdep;s ability to warn us of cycles. Closes: https://gitlab.freedesktop.org/drm/intel/issues/478Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200326142727.31962-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
The DP link computation functions shouldn't modify the adjusted_mode so make it const. Signed-off-by:
-
Ville Syrjälä authored
Not sure why this thing is trying to avoid declaring the proper type for these pointers. But since these are used only once let's just get rid of the local variable entirely. Signed-off-by:
-
Kai Vehmanen authored
Commit 632f3ab9 ("drm/i915/audio: add codec wakeup override enabled/disable callback"), added logic to toggle Codec Wake on gen9. This is used by audio driver when it resets the HDA controller. It seems explicit toggling of the wakeline can help to fix problems with probe failing on some gen12 platforms. And based on specs, there is no reason why this programming sequence should not be applied to all gen9+ platforms. No side-effects are seen on gen10/11. So apply the wake-logic to all gen9+ platforms. Link: https://github.com/thesofproject/linux/issues/1847Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Lionel Landwerlin authored
This new parameter let's the application choose how often the OA buffer should be checked on the CPU side for data availability. Longer polling period tend to reduce CPU overhead if the application does not care about somewhat real time data collection. v2: Allow disabling polling completely with 0 value (Lionel) v3: Version the new parameter (Joonas) v4: Rebase (Umesh) v5: Make poll delay value of 0 invalid (Umesh) v6: - Describe poll_oa_period (Ashutosh) - Fix comment for new poll parameter (Lionel) - Drop open_flags in read_properties_unlocked (Lionel) - Rename uapi parameter (Ashutosh) v7: Reword the comment in uapi (Ashutosh) Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
This isn't really gen specific stuff, so just move it to the common code. v2: Rebase (Umesh) v3: Remove comment, pollin is a per stream state already (Ashutosh) Signed-off-by:
-
Lionel Landwerlin authored
We're about to introduce an options to open the perf stream, giving the user ability to configure how often it wants the kernel to poll the OA registers for available data. Right now the workaround against the OA tail pointer race condition requires at least twice the internal kernel polling timer to make any data available. This changes introduce checks on the OA data written into the circular buffer to make as much data as possible available on the first iteration of the polling timer. v2: Use OA_TAKEN macro without the gtt_offset (Lionel) v3: (Umesh) - Rebase - Change report to report32 from below review https://patchwork.freedesktop.org/patch/330704/?series=66697&rev=1 v4: (Ashutosh, Lionel) - Fix checkpatch errors - Fix aging_timestamp initialization - Check for only one valid landed report - Fix check for unlanded report v5: (Ashutosh) - Fix bug in accurately determining landed report. - Optimize the check for landed reports by going as far as the previously determined aged tail. Signed-off-by:
-
- 26 Mar, 2020 11 commits
-
-
Nathan Chancellor authored
A recent commit in clang added -Wtautological-compare to -Wall, which is enabled for i915 after -Wtautological-compare is disabled for the rest of the kernel so we see the following warning on x86_64: ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: result of comparison of constant 576460752303423487 with expression of type 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare] if (unlikely(remain > N_RELOC(ULONG_MAX))) ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely' # define unlikely(x) __builtin_expect(!!(x), 0) ^ 1 warning generated. It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not account for the case where this file is built for 32-bit x86, where ULONG_MAX == UINT_MAX and this check is still relevant. Cast remain to unsigned long, which keeps the generated code the same (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and the warning is silenced so we can catch more potential issues in the future. Closes: https://github.com/ClangBuiltLinux/linux/issues/778Suggested-by:Michel Dänzer <michel@daenzer.net> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
We need to keep the GuC error logs around to debug the load failure, so we can't clean them in the error unwind, which includes uc_fini(). Moving the cleanup to driver remove ensures that the logs stick around long enough for us to dump them. v2: reword commit msg (John) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
uC is a component of the GT, so it makes sense for the uC debugfs files to be in the GT folder. A subfolder has been used to keep the same structure we have for the code. v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files, fix permissions for writable debugfs files. v3: Rename files (Michal), remove blank line (Jani), fix sparse warns. Signed-off-by: -
Daniele Ceraolo Spurio authored
Move the printers to the respective files for clarity. The guc_load_status debugfs has been squashed in the guc_info one, has having separate ones wasn't very useful. The HuC debugfs has been renamed huc_info to match. v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const container_of (Jani) Suggested-by: -
Daniele Ceraolo Spurio authored
We currently initialize HuC support based on GuC being enabled in modparam; this means that huc_is_supported() can return false on HW that does have a HuC when enable_guc=0. The rationale for this behavior is that HuC requires GuC for authentication and therefore is not supported by itself. However, we do not allow defining HuC fw wthout GuC fw and selecting HuC in modparam implicitly selects GuC as well, so we can't actually hit a scenario where HuC is selected alone. Therefore, we can flip the support check to reflect the HW capabilities and fw availability, which is more intuitive and will make it cleaner to log HuC the difference between not supported in HW and not selected. Removing the difference between GuC and HuC also allows us to simplify the init_early, since we don't need to differentiate the support based on the type of uC. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The pool will be private to GuC in the new submission scheme, so we won't be able to print it and we can just drop the current legacy code. Signed-off-by:
-
Andi Shyti authored
When registering debugfs files the intel gt debugfs library forces a 'struct *gt' private data on the caller. To be open to different usages make the new "intel_gt_debugfs_register_files()"[*] function more generic by converting the 'struct *gt' pointer to a 'void *' type. I take the chance to rename the functions by using "intel_gt_" as prefix instead of "debugfs_", so that "debugfs_gt_register_files()" becomes "intel_gt_debugfs_register_files()". Signed-off-by:
-
Uma Shankar authored
This patch fixes the private_flags of mode to be checked and compared against uapi.mode and not from hw.mode. This helps properly trigger modeset at boot if desired by driver. It helps resolve audio_codec initialization issues if display is connected at boot. Initial discussion on this issue has happened on below thread: https://patchwork.freedesktop.org/series/74828/ v2: No functional change. Fixed the Closes tag and added Maarten's RB. v3: Added Fixes tag. Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Souza, Jose <jose.souza@intel.com> Fixes: 58d124ea ("drm/i915: Complete crtc hw/uapi split, v6.") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1363Suggested-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
SweeAun Khor <swee.aun.khor@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200326125111.11081-1-uma.shankar@intel.com
-
Chris Wilson authored
Avoid using the uninitialised len along the impossible error path to shut the compiler up: drivers/gpu/drm/i915/display/intel_dp.c:4928 intel_write_dp_sdp() error: uninitialized symbol 'len'. Signed-off-by:
-
Chris Wilson authored
Beware dereferencing the NULL pointer prior to checking for its existence. <1>[ 3.324694] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 3.324696] #PF: supervisor read access in kernel mode <4>[ 3.324704] hardirqs last enabled at (751): [<ffffffff812a4f77>] d_lookup+0x57/0xa0 <1>[ 3.324709] #PF: error_code(0x0000) - not-present page <4>[ 3.324716] hardirqs last disabled at (752): [<ffffffff8125a1b9>] __slab_alloc.isra.89.constprop.94+0x19/0x70 <4>[ 3.324720] softirqs last enabled at (402): [<ffffffff81e00385>] __do_softirq+0x385/0x47f <6>[ 3.324725] PGD 0 P4D 0 <4>[ 3.324733] softirqs last disabled at (395): [<ffffffff810bab6a>] irq_exit+0xba/0xc0 <4>[ 3.324762] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 3.324768] CPU: 0 PID: 380 Comm: systemd-udevd Not tainted 5.6.0-rc7-CI-CI_DRM_8189+ #1 <4>[ 3.324776] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016 <4>[ 3.324840] RIP: 0010:intel_read_infoframe+0x3a/0x170 [i915] <4>[ 3.324848] Code: 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 31 c0 83 f9 0a 77 12 ba 01 00 00 00 48 d3 e2 f7 c2 c0 05 00 00 48 0f 45 c7 83 fb 03 <4c> 8b 20 0f 84 f2 00 00 00 83 fb 0a 0f 84 f3 00 00 00 83 fb 07 0f <4>[ 3.324865] RSP: 0018:ffffc900005438b0 EFLAGS: 00010212 <4>[ 3.324871] RAX: 0000000000000000 RBX: 0000000000000082 RCX: 0000000000000001 <4>[ 3.324879] RDX: 0000000000000002 RSI: ffff8883f8309000 RDI: ffff8883f80cbe00 <4>[ 3.324887] RBP: ffff8883f8309b34 R08: 000000000000000e R09: 0000000000000001 <4>[ 3.324894] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8883f7ac0000 <4>[ 3.324901] R13: ffff8883f7ac0000 R14: ffff8883f7ac0d90 R15: ffff8883f844d000 <4>[ 3.324908] FS: 00007ffa4a839680(0000) GS:ffff888410000000(0000) knlGS:0000000000000000 <4>[ 3.324917] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 3.324923] CR2: 0000000000000000 CR3: 0000000401aa4002 CR4: 00000000001606f0 <4>[ 3.324930] Call Trace: <4>[ 3.324980] ? gen6_read32+0x272/0x300 [i915] <4>[ 3.325044] intel_ddi_get_config+0x238/0x610 [i915] <4>[ 3.325108] hsw_crt_get_config+0x12/0x40 [i915] <4>[ 3.325173] intel_modeset_setup_hw_state+0x3b3/0x1660 [i915] <4>[ 3.325182] ? ww_mutex_lock+0x39/0x70 <4>[ 3.325190] ? drm_modeset_lock+0xad/0x120 <4>[ 3.325254] intel_modeset_init+0x582/0x1c50 [i915] Fixes: 41919042 ("drm/i915/hdmi: use struct drm_device based logging") Signed-off-by:
-
Chris Wilson authored
We've migrated all the heavy users over to the intel_gt, and can finally drop the last few users and with that the mirror in dev_priv->engine[]. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200325234803.6175-1-chris@chris-wilson.co.uk
-
- 25 Mar, 2020 1 commit
-
-
Jani Nikula authored
Prefer drm_dbg() over DRM_DEV_DEBUG_DRIVER() and drm_err() over dev_err(). Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
