- 27 Mar, 2020 2 commits
-
-
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 <lionel.g.landwerlin@intel.com> Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> 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:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200326181121.16869-7-daniele.ceraolospurio@intel.com
-
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:Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-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:
Andi Shyti <andi.shyti@intel.com> Reviewed-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:
Ville Syrjä <ville.syrjala@linux.intel.com> Signed-off-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 18 commits
-
-
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:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Drop useless macro hiding the return. Fix superfluous whitespace. Rename function to all lowercase. Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Reviewed-by:
-
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Jani Nikula authored
Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: -
Chris Wilson authored
We move the virtual breadcrumb from one physical engine to the next, if the next virtual request is scheduled on a new physical engine. Since the virtual context can only be in one signal queue, we need it to track the current physical engine for the new breadcrumbs. However, to move the list we need both breadcrumb locks -- and since we cannot take both at the same time (unless we are careful and always ensure consistent ordering) stage the movement of the signaler via the current virtual request. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1510 Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Signed-off-by:
-
Chris Wilson authored
If the caller allows and we do not have to wait for any signals, immediately execute the work within the caller's process. By doing so we avoid the overhead of scheduling a new task, and the latency in executing it, at the cost of pulling that work back into the immediate context. (Sometimes we still prefer to offload the task to another cpu, especially if we plan on executing many such tasks in parallel for this client.) Signed-off-by:
-
Chris Wilson authored
We dropped calling process_csb prior to handling direct submission in order to avoid the nesting of spinlocks and lift process_csb() and the majority of the tasklet out of irq-off. However, we do want to avoid ksoftirqd latency in the fast path, so try and pull the interrupt-bh local to direct submission if we can acquire the tasklet's lock. v2: Document the read of pending[0] from outside the tasklet with READ_ONCE. Signed-off-by:
-
Chris Wilson authored
Measure and compare the energy consumed, as reported by the rapl MSR, by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not at least halve the energy consumption of RC0, as this more than likely means we failed to enter RC0 correctly. If we can't measure the energy draw with the MSR, then it will report 0 for both measurements. Since the measurement works on all gen6+, this seems worth flagging as an error. Signed-off-by:
-
Chris Wilson authored
We set the priority hint on execlists to avoid executing the tasklet for when we know that there will be no change in execution order. However, as we set it from the virtual engine for all siblings, but only one physical engine may respond, we leave the hint set on the others stopping direct submission that could take place. If we do not set the hint, we may attempt direct submission even if we don't expect to submit. If we set the hint, we may not do any submission until the tasklet is run (and sometimes we may park the engine before that has had a chance). Ergo there's only a minor ill-effect on mixed virtual/physical engine workloads where we may try and fail to do direct submission more often than required. (Pure virtual / engine workloads will have redundant tasklet execution suppressed as normal.) Closes: https://gitlab.freedesktop.org/drm/intel/issues/1522Signed-off-by:
-
- 24 Mar, 2020 7 commits
-
-
José Roberto de Souza authored
dGFX has local memory so it does not have aperture or support CPU fences but even for iGFX it have a small number of fences. As replacement for fences to track frontbuffer modifications by CPU we have a software tracking that is already in used by FBC and PSR. PSR don't support fences so it shows that this tracking is reliable. So lets make fences a nice-to-have to activate FBC for GEN9+, this will allow us to enable FBC for dGFXs and iGFXs even when there is no available fence. We do not set fences to rotated planes but FBC only have restrictions against 16bpp, so adding it here. Also adding a new check for the tiling format, fences are only set to X and Y tiled planes but again FBC don't have any restrictions against tiling so adding linear as supported as well, other formats should be added after tested but IGT only supports drawing in thse 3 formats. intel_fbc_hw_tracking_covers_screen() maybe can also have the same treatment as fences but BSpec is not clear if the size limitation is for hardware tracking or general use of FBC and I don't have a 5K display to test it, so keeping as is for safety. v2: - Added tiling and pixel format rotation checks - Changed the GEN version not requiring fences to 11 from 9, DDX needs some changes but it don't have support for GEN11+ v3: - Changed back to GEN9+ - Moved GEN test to inside of tiling_is_valid() v4: - moved rotation check to its own functions v5: - renamed rotations_is_valid to rotation_is_valid - moved pre-g4x rotation check to rotation_is_valid() Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: 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/20200319211535.114625-1-jose.souza@intel.com
-
Chris Wilson authored
On Ivybridge, we can go lower than rc6 to rc6p. And this is required for Ivybridge to hit the same minimum power consumption as rc6 on other platforms, so make it so. v2: Update selftest to include all rc6 residency counters Note that Andi did mention that we should be converting the magic numbers into opaque magic macros, so if they ever get reused (unlikely given only Ivybridge used the extra modes) we'll need to pay back the technical debt. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1518 Fixes: 730eaeb5 ("drm/i915/gt: Manual rc6 entry upon parking") Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by:
-
Vandita Kulkarni authored
On dsi cmd mode we do not receive vblanks instead we would get TE and these flags indicate TE is expected on which port. Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Vandita Kulkarni authored
If the GOP has programmed periodic command mode, we need to disable that which would need a deconfigure and configure sequence. v2: Fix sparse error, pass only intel_dsi (Jani) v3: Use intel_de_read Signed-off-by:
-
Vandita Kulkarni authored
Adding TE flags and periodic command mode flags as part of private flags to indicate what TE interrupts we would be getting instead of vblanks in case of mipi dsi command mode. v2: Add TE flag description (Jani) Reviewed-by:
-
Vandita Kulkarni authored
Transcoder timing calculation differ for command mode. v2: Use is_vid_mode, and use same I915_WRITE (Jani) v3: Adjust the calculations to reflect dsc compression ratio v4: Rearrange the vertical and horizontal timing calc, optimize local variables usage. (Jani) v5: Fix the values used for calculation, use afe_clk for byte clock calculation, use intel_de_write/read (Jani) Signed-off-by: -
Vandita Kulkarni authored
Configure the transcoder to operate in TE GATE command mode and take TE events from GPIO. Also disable the periodic command mode, that GOP would have programmed. v2: Disable util pin (Jani) v3: Use intel_de_write (Jani) Signed-off-by:
-
- 23 Mar, 2020 2 commits
-
-
Chris Wilson authored
It is strictly sufficient to only delay the intel_engine_pm_put from the context barrier (and not from the context exit) in order to prevent the gem_exec_nop contention. Adding the delay to the context exit incurs noticably extra penalty for soft-rc6. Fixes: edee52c9 ("drm/i915/gt: Delay release of engine-pm after last retirement") Testcase: igt/i915_pm_rc6_residency/rc6-idle Signed-off-by:
-
Matthew Auld authored
It looks like some callers expect a non-volatile object, that they do not want the contents of the pages lost if they happen to not be looking at it. The shrinker however sees that we mark the pages as DONTNEED and believes that it can freely reap them. However, since the huge object use plain pages, they cannot be swapped out as they have no backing storge, and the only way we can shrink them is by discarding the contents. In light of the callers wanting to keep the contents around, both IS_SHRINKABLE and marking the pages as volatile are incorrect. If we drop the IS_SHRINKABLE flag we avoid the immediate issue of the shrinker accidentally removing valuable content. We will have to remember that a huge object is not suitable for exercising the shrinker interaction -- although we can introduce a shrinkable one if we require. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
