Re: [PATCH] drm/i915/gt: debugfs: Evaluate forcewake usage within locks
On Fri, Jun 07, 2024 at 04:51:31PM +0200, Andi Shyti wrote: > The forcewake count and domains listing is multi process critical > and the uncore provides a spinlock for such cases. > > Lock the forcewake evaluation section in the fw_domains_show() > debugfs interface. > > Signed-off-by: Andi Shyti > --- > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > index 4fcba42cfe34..0437fd8217e0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c > @@ -71,6 +71,8 @@ static int fw_domains_show(struct seq_file *m, void *data) > struct intel_uncore_forcewake_domain *fw_domain; > unsigned int tmp; > > + spin_lock_irq(>lock); > + > seq_printf(m, "user.bypass_count = %u\n", > uncore->user_forcewake_count); > > @@ -79,6 +81,8 @@ static int fw_domains_show(struct seq_file *m, void *data) > intel_uncore_forcewake_domain_to_str(fw_domain->id), > READ_ONCE(fw_domain->wake_count)); > > + spin_unlock_irq(>lock); I was going to ask to move all of this to a function inside intel_uncore.c so we keep the lock access in there But then I noticed it is already spread all over :( Well, perhaps we should start from here to set the precedence and move things to its own component... but well, I won't block or make it hard, we do need this change and the overall uncore cleanup could be orthogonal. Reviewed-by: Rodrigo Vivi > + > return 0; > } > DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(fw_domains); > -- > 2.45.1 >
[PULL] drm-xe-next
r post hwconfig uC initialization step drm/xe/uc: Move GuC submission init to post hwconfig step drm/xe/pf: Don't advertise support to enable VFs if not ready drm/xe/pf: Implement pci_driver.sriov_configure callback drm/xe/guc: Add more KLV helper macros drm/xe/guc: Introduce GuC KLV thresholds set drm/xe/guc: Add support for threshold KLVs in to_string() helper drm/xe/pf: Introduce functions to configure VF thresholds drm/xe/pf: Allow configuration of VF thresholds over debugfs drm/xe/guc: Add GUC2PF_ADVERSE_EVENT to ABI drm/xe/pf: Track adverse events notifications from GuC drm/xe/pf: Expose PF monitor details via debugfs drm/xe/guc: Add VF2GUC_MATCH_VERSION to ABI drm/xe/guc: Add VF2GUC_VF_RESET to ABI drm/xe/guc: Add VF2GUC_QUERY_SINGLE_KLV to ABI drm/xe/vf: Add support for VF to query its configuration drm/xe/vf: Custom hardware config load step if VF drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs drm/xe: Fix xe_uc.h drm/xe: Fix xe_gsc.h drm/xe: Fix xe_huc.h drm/xe: Fix xe_guc_pc.h drm/i915/display: Add missing include to intel_vga.c drm/xe: Don't rely on indirect includes from xe_mmio.h drm/xe: Cleanup xe_mmio.h drm/xe/guc: Allow to initialize submission with limited set of IDs drm/xe/vf: Custom GuC initialization if VF drm/xe/uc: Don't emit false error if running in execlist mode drm/xe/vf: Use register values obtained from the PF drm/xe/guc: Add GLOBAL_CFG_GMD_ID KLV definition drm/xe/vf: Obtain value of GMDID register from GuC drm/xe/vf: Provide early access to GMDID register drm/xe/vf: Cache value of the GMDID register drm/xe/vf: Treat GMDID as another runtime register drm/xe/vf: Read VF configuration prior to GGTT initialization drm/xe/vf: Use only assigned GGTT region drm/xe: Store platform name in xe_device.info drm/xe: Use platform name in xe_assert() drm/xe: Drop undesired prefix from the platform name drm/xe: Move XEHP_MTCFG_ADDR register definition to xe_regs.h drm/xe: Move BAR definitions to dedicated file drm/xe: Drop xe_ prefix from static functions in xe_mmio.c drm/xe: Promote VRAM initialization function to own file drm/xe/vf: Setup VRAM based on received config data drm/xe: Split MCR initialization drm/xe/pf: Update the LMTT when freeing VF GT config drm/xe/vf: Support only GuC/HuC firmwares drm/xe/vf: Custom uC initialization drm/xe/vf: Custom GuC reset drm/xe/vf: Custom GT restart Niranjana Vishwanathapura (8): drm/xe: Minor cleanup in LRC handling drm/xe: Add Indirect Ring State support drm/xe: Dump Indirect Ring State registers drm/xe/xe2: Enable Indirect Ring State support for Xe2 drm/xe: Properly handle alloc_guc_id() failure drm/xe: Remove unwanted mutex locking drm/xe: Decouple xe_exec_queue and xe_lrc drm/xe: Add kernel-doc to some xe_lrc interfaces Nirmoy Das (11): drm/xe: Remove uninitialized end var from xe_gt_tlb_invalidation_range() drm/xe: Introduce has_atomic_enable_pte_bit device info drm/xe: Move vm bind bo validation to a helper function drm/xe: Introduce has_device_atomics_on_smem device info drm/xe: Add function to check if BO has single placement drm/xe: Refactor default device atomic settings drm/xe: Add warn when level can not be zero. drm/xe/tests: Use uninterruptible VM lock drm/xe: Check empty pinned BO list with lock held. drm/xe: Add engine name to the engine reset and cat-err log drm/xe: Use missing lock in relay_needs_worker Oded Gabbay (1): MAINTAINERS: update Xe driver maintainers Riana Tauro (4): drm/xe: Standardize power gate registers drm/xe: Enable Coarse Power Gating drm/xe/xe_gt_idle: use GT forcewake domain assertion drm/xe: move disable_c6 call Rodrigo Vivi (13): drm/xe: make xe_pm_runtime_lockdep_map a static struct drm/xe: Introduce a simple wedged state drm/xe: declare wedged upon GuC load failure drm/xe: Force wedged state and block GT reset upon any GPU hang drm/xe: Introduce the wedged_mode debugfs drm/xe: Demote CCS_MODE info to debug only drm/xe: Fix xe_pm_runtime_get_if_active return drm/xe: Fix xe_pm_runtime_get_if_in_use documentation drm/xe: Relax runtime pm protection during execution drm/xe: Relax runtime pm protection around VM drm/xe: Prepare display for D3Cold drm/xe: Stop checking for power_lost on D3Cold drm/xe: Enable D3Cold on 'low' VRAM utilization Shekhar Chauhan (1): drm/xe/xe2hpg: Add Wa_14021490052 Shuicheng Lin (1): drm/xe: Fix UBSAN shift-out-of-bounds failure Tejas Upadhyay (4): drm/xe/xe2: Add workaround 14021567978 drm/xe: skip error capture when exec queue is killed
Re: [PATCH 1/2] drm: Add DRM-managed drm_mm_init()
On Fri, May 24, 2024 at 03:35:17PM +0200, Michal Wajdeczko wrote:
> Add drmm_mm_init(), a helper that provides managed allocator cleanup.
> The allocator will be cleaned up with the final reference of the DRM
> device.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_managed.c | 27 +++
> include/drm/drm_managed.h | 3 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 7646f67bda4e..2fb9656bada3 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -13,6 +13,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "drm_internal.h"
> @@ -310,3 +311,29 @@ void __drmm_mutex_release(struct drm_device *dev, void
> *res)
> mutex_destroy(lock);
> }
> EXPORT_SYMBOL(__drmm_mutex_release);
> +
> +static void __drmm_mm_takedown(struct drm_device *dev, void *res)
> +{
> + struct drm_mm *mm = res;
> +
> + drm_mm_takedown(mm);
> +}
> +
> +/**
> + * drmm_mm_init - _device managed drm_mm_init()
> + * @dev: DRM device
> + * @mm: the drm_mm structure to initialize
> + * @start: start of the range managed by @mm
> + * @size: end of the range managed by @mm
> + *
> + * This is a _device managed version of drm_mm_init().
> + * The initialized allocator will be cleaned up on the final drm_dev_put().
> + *
> + * Return: 0 on success, or a negative errno code otherwise.
> + */
> +int drmm_mm_init(struct drm_device *dev, struct drm_mm *mm, u64 start, u64
> size)
> +{
> + drm_mm_init(mm, start, size);
> + return drmm_add_action_or_reset(dev, __drmm_mm_takedown, mm);
> +}
> +EXPORT_SYMBOL(drmm_mm_init);
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index f547b09ca023..e8c2f29cb88a 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -8,6 +8,7 @@
> #include
>
> struct drm_device;
> +struct drm_mm;
> struct mutex;
>
> typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
> @@ -127,4 +128,6 @@ void __drmm_mutex_release(struct drm_device *dev, void
> *res);
> drmm_add_action_or_reset(dev, __drmm_mutex_release, lock); \
> })\
>
> +int drmm_mm_init(struct drm_device *dev, struct drm_mm *mm, u64 start, u64
> size);
Reviewed-by: Rodrigo Vivi
> +
> #endif
> --
> 2.43.0
>
Re: [PATCH 2/2] drm/xe: Use drm_device managed mutex/mm init helpers in GGTT
On Fri, May 24, 2024 at 03:35:18PM +0200, Michal Wajdeczko wrote:
> There is not need for private release action as there are existing
> drmm_mm_init() and drmm_mutex_init() helpers that can be used.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Thomas Hellström
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/xe/xe_ggtt.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
> index 17e5066763db..7c91fe212dcb 100644
> --- a/drivers/gpu/drm/xe/xe_ggtt.c
> +++ b/drivers/gpu/drm/xe/xe_ggtt.c
> @@ -96,14 +96,6 @@ static void xe_ggtt_clear(struct xe_ggtt *ggtt, u64 start,
> u64 size)
> }
> }
>
> -static void ggtt_fini_early(struct drm_device *drm, void *arg)
> -{
> - struct xe_ggtt *ggtt = arg;
> -
> - mutex_destroy(>lock);
> - drm_mm_takedown(>mm);
> -}
> -
> static void ggtt_fini(struct drm_device *drm, void *arg)
> {
> struct xe_ggtt *ggtt = arg;
> @@ -141,6 +133,7 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
> struct xe_device *xe = tile_to_xe(ggtt->tile);
> struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> unsigned int gsm_size;
> + int err;
>
> if (IS_SRIOV_VF(xe))
> gsm_size = SZ_8M; /* GGTT is expected to be 4GiB */
> @@ -189,12 +182,18 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
> else
> ggtt->pt_ops = _pt_ops;
>
> - drm_mm_init(>mm, xe_wopcm_size(xe),
> - ggtt->size - xe_wopcm_size(xe));
> - mutex_init(>lock);
> + err = drmm_mm_init(>drm, >mm, xe_wopcm_size(xe),
> +ggtt->size - xe_wopcm_size(xe));
> + if (err)
> + return err;
> +
> + err = drmm_mutex_init(>drm, >lock);
> + if (err)
> + return err;
My first impression here is that we would have a bug here if drmm_mm_init
works, but drmm_mutex_init fails, but we are likely safe because the
probe will also entirely fail if this mutex init fails.
> +
> primelockdep(ggtt);
>
> - return drmm_add_action_or_reset(>drm, ggtt_fini_early, ggtt);
But my question here is, why drmm and not devm for this ggtt case that
only makes sense if the hardware/device is up and not about the module
or no reason to keep it alive after the probe failure or device removal.
I know that the question is orthogonal to your patch. But if we decide to
change the course later and move this towards devm, then we need to
get back to the exit function and perhaps regular mutex.
I mean, really nothing against this patch itself, specially if we are
confident that drmm is the way to go with this ggtt. So, I'm not blocking
here:
Reviewed-by: Rodrigo Vivi
> + return 0;
> }
>
> static void xe_ggtt_invalidate(struct xe_ggtt *ggtt);
> --
> 2.43.0
>
Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()
iming %pOF: %s is not a valid parent\n",
> node, __clk_get_name(timing->parent));
> clk_put(timing->parent);
> - return -EINVAL;
> + return i;
> }
>
> timing->parent_index = i;
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 1b7e82a0ad2e..b6f52f44625f 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -1117,9 +1117,9 @@ static ssize_t store_energy_performance_preference(
> if (ret != 1)
> return -EINVAL;
>
> - ret = match_string(energy_perf_strings, -1, str_preference);
> + ret = __match_string(energy_perf_strings, -1, str_preference);
> if (ret < 0)
> - return -EINVAL;
> + return ret;
>
> mutex_lock(_pstate_limits_lock);
> ret = amd_pstate_set_energy_pref_index(cpudata, ret);
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 4b986c044741..1c2ee10415a2 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -832,7 +832,7 @@ static ssize_t store_energy_performance_preference(
> if (ret != 1)
> return -EINVAL;
>
> - ret = match_string(energy_perf_strings, -1, str_preference);
> + ret = __match_string(energy_perf_strings, -1, str_preference);
> if (ret < 0) {
> if (!boot_cpu_has(X86_FEATURE_HWP_EPP))
> return ret;
> diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
> b/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
> index 268052294468..4b8c45e8b164 100644
> --- a/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
> +++ b/drivers/crypto/intel/qat/qat_common/adf_cfg_services.c
> @@ -3,7 +3,7 @@
>
> #include
> #include
> -#include
> +#include
> #include "adf_cfg.h"
> #include "adf_cfg_services.h"
> #include "adf_cfg_strings.h"
> @@ -35,8 +35,7 @@ int adf_get_service_enabled(struct adf_accel_dev *accel_dev)
> return ret;
> }
>
> - ret = match_string(adf_cfg_services, ARRAY_SIZE(adf_cfg_services),
> -services);
> + ret = match_string(adf_cfg_services, services);
> if (ret < 0)
> dev_err(_DEV(accel_dev),
> "Invalid value of " ADF_SERVICES_ENABLED " param: %s\n",
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index aa93129c3397..624743caac4c 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -481,7 +481,7 @@ int drm_get_panel_orientation_quirk(int width, int height)
> if (!bios_date)
> continue;
>
> - i = match_string(data->bios_dates, -1, bios_date);
> + i = __match_string(data->bios_dates, -1, bios_date);
> if (i >= 0)
> return data->orientation;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> index 5a468ed6e26c..f9e7c66fd538 100644
> --- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> @@ -426,7 +426,7 @@ display_crc_ctl_parse_source(const char *buf, enum
> intel_pipe_crc_source *s)
> return 0;
> }
>
> - i = match_string(pipe_crc_sources, ARRAY_SIZE(pipe_crc_sources), buf);
> + i = match_string(pipe_crc_sources, buf);
Acked-by: Rodrigo Vivi
(I believe that the new _match_string(str1, size, str2) deserves a better name,
but since I'm bad with naming stuff, I don't have any good suggestion)
> if (i < 0)
> return i;
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> index 670c9739e5e1..7fb9f5345654 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> @@ -645,8 +645,8 @@ static int nv17_tv_create_resources(struct drm_encoder
> *encoder,
> int i;
>
> if (nouveau_tv_norm) {
> - i = match_string(nv17_tv_norm_names, num_tv_norms,
> - nouveau_tv_norm);
> + i = __match_string(nv17_tv_norm_names, num_tv_norms,
> +nouveau_tv_norm);
> if (i < 0)
> NV_WARN(drm, "Invalid TV norm setting \"%s\"\n",
> nouveau_tv_norm);
> diff --git a/drivers/gpu/drm/
[PATCH] drm/mm: Remove unused drm_mm_replace_node
Last caller was removed with commit 078a5b498d6a ("drm/tests:
Remove slow tests").
Cc: Maxime Ripard
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_mm.c | 35 ---
include/drm/drm_mm.h | 1 -
2 files changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..5ace481c1901 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -648,41 +648,6 @@ void drm_mm_remove_node(struct drm_mm_node *node)
}
EXPORT_SYMBOL(drm_mm_remove_node);
-/**
- * drm_mm_replace_node - move an allocation from @old to @new
- * @old: drm_mm_node to remove from the allocator
- * @new: drm_mm_node which should inherit @old's allocation
- *
- * This is useful for when drivers embed the drm_mm_node structure and hence
- * can't move allocations by reassigning pointers. It's a combination of remove
- * and insert with the guarantee that the allocation start will match.
- */
-void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new)
-{
- struct drm_mm *mm = old->mm;
-
- DRM_MM_BUG_ON(!drm_mm_node_allocated(old));
-
- *new = *old;
-
- __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
- list_replace(>node_list, >node_list);
- rb_replace_node_cached(>rb, >rb, >interval_tree);
-
- if (drm_mm_hole_follows(old)) {
- list_replace(>hole_stack, >hole_stack);
- rb_replace_node_cached(>rb_hole_size,
- >rb_hole_size,
- >holes_size);
- rb_replace_node(>rb_hole_addr,
- >rb_hole_addr,
- >holes_addr);
- }
-
- clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
-}
-EXPORT_SYMBOL(drm_mm_replace_node);
-
/**
* DOC: lru scan roster
*
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index ac33ba1b18bc..f654874c4ce6 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -463,7 +463,6 @@ static inline int drm_mm_insert_node(struct drm_mm *mm,
}
void drm_mm_remove_node(struct drm_mm_node *node);
-void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new);
void drm_mm_init(struct drm_mm *mm, u64 start, u64 size);
void drm_mm_takedown(struct drm_mm *mm);
--
2.43.2
Re: [PATCH] MAINTAINERS: Update Xe driver maintainers
On Fri, May 31, 2024 at 04:10:51PM +0200, Thomas Hellström wrote: > Add Rodrigo Vivi as an Xe driver maintainer. > > Cc: David Airlie > Cc: Daniel Vetter > Cc: Rodrigo Vivi Cc: Lucas De Marchi Acked-by: Rodrigo Vivi > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > > Signed-off-by: Thomas Hellström > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 572be0546e21..8f9982c99257 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11037,6 +11037,7 @@ F:include/uapi/drm/i915_drm.h > INTEL DRM XE DRIVER (Lunar Lake and newer) > M: Lucas De Marchi > M: Thomas Hellström > +M: Rodrigo Vivi > L: intel...@lists.freedesktop.org > S: Supported > W: https://drm.pages.freedesktop.org/intel-docs/ > -- > 2.44.0 >
Re: [PATCH v2] drm/i915: Increase FLR timeout from 3s to 9s
On Mon, May 27, 2024 at 04:00:25PM +0100, Andi Shyti wrote: > On Mon, May 27, 2024 at 11:47:49AM +0100, Andi Shyti wrote: > > On Fri, May 24, 2024 at 10:07:44AM -0400, Rodrigo Vivi wrote: > > > On Fri, May 24, 2024 at 01:58:53AM +0200, Andi Shyti wrote: > > > > Following the guidelines it takes 3 seconds to perform an FLR > > > > reset. Let's give it a bit more slack because this time can > > > > change depending on the platform and on the firmware > > > > > > But did we see any issue with that? > > > > yes, we have some FLR expiration timeouts that apparently are not > > able to bring up the device and the memory is not accessible > > anymore. It's worth giving it a bit more time. > > > > > if that changes per platform and per firmware, shouldn't it all > > > be explicit in the spec as well? > > > > Is it always documented? We might anyway die after the FLR reset > > failure, so that I see it quite safe to wait and pray a little > > more. > > if needed I can improve the log with the dmesg error print. very good points indeed. I believe it would be worth some mentions about the faced issues and good idea about dmesg as well. but up to you. Reviewed-by: Rodrigo Vivi > > Andi
Re: [PATCH v2] drm/i915: Increase FLR timeout from 3s to 9s
On Fri, May 24, 2024 at 01:58:53AM +0200, Andi Shyti wrote:
> Following the guidelines it takes 3 seconds to perform an FLR
> reset. Let's give it a bit more slack because this time can
> change depending on the platform and on the firmware
But did we see any issue with that?
if that changes per platform and per firmware, shouldn't it all
be explicit in the spec as well?
>
> Signed-off-by: Andi Shyti
> ---
> Hi,
>
> In this second version I removed patch 2 that was ignoring the
> FLR reset timeouts, until we develop a proper patch.
>
> This first patch is basically the same as v1. Thanks Nirmoy for
> your review.
>
> Andi
>
> drivers/gpu/drm/i915/intel_uncore.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 729409a4bada..2eba289d88ad 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2614,11 +2614,18 @@ void intel_uncore_prune_engine_fw_domains(struct
> intel_uncore *uncore,
> static void driver_initiated_flr(struct intel_uncore *uncore)
> {
> struct drm_i915_private *i915 = uncore->i915;
> - const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait
> */
> + unsigned int flr_timeout_ms;
> int ret;
>
> drm_dbg(>drm, "Triggering Driver-FLR\n");
>
> + /*
> + * The specification recommends a 3 seconds FLR reset timeout. To be
> + * cautious, we will extend this to 9 seconds, three times the specified
> + * timeout.
> + */
> + flr_timeout_ms = 9000;
> +
> /*
>* Make sure any pending FLR requests have cleared by waiting for the
>* FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
> --
> 2.45.1
>
Re: [PATCH] drm/xe: remove unused struct 'xe_gt_desc'
On Wed, May 22, 2024 at 06:58:40PM +0100, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> 'xe_gt_desc' is unused since
> commit 1e6c20be6c83 ("drm/xe: Drop extra_gts[] declarations and
> XE_GT_TYPE_REMOTE").
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Rodrigo Vivi
and applying it right now...
thanks for the patch
> ---
> drivers/gpu/drm/xe/xe_pci.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index f326dbb1cecd..2ca210480bd1 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -40,12 +40,6 @@ struct xe_subplatform_desc {
> const u16 *pciidlist;
> };
>
> -struct xe_gt_desc {
> - enum xe_gt_type type;
> - u32 mmio_adj_limit;
> - u32 mmio_adj_offset;
> -};
> -
> struct xe_device_desc {
> /* Should only ever be set for platforms without GMD_ID */
> const struct xe_graphics_desc *graphics;
> --
> 2.45.1
>
Re: [PATCH] drm/i915/gem/i915_gem_ttm_move: Fix typo
On Mon, May 13, 2024 at 02:14:51AM -0400, Deming Wang wrote: > The mapings should be replaced by mappings. > > Signed-off-by: Deming Wang Reviewed-by: Rodrigo Vivi and pushed to drm-intel-gt-next thanks for the patch > --- > drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > index 7078af2f8f79..03b00a03a634 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > @@ -155,7 +155,7 @@ void i915_ttm_adjust_gem_after_move(struct > drm_i915_gem_object *obj) > * @bo: The ttm buffer object. > * > * This function prepares an object for move by removing all GPU bindings, > - * removing all CPU mapings and finally releasing the pages sg-table. > + * removing all CPU mappings and finally releasing the pages sg-table. > * > * Return: 0 if successful, negative error code on error. > */ > -- > 2.31.1 >
Re: [PATCH 01/20] drm/drm_managed: try to improve the drmm DOC
On Fri, May 10, 2024 at 07:12:14PM +0100, Matthew Auld wrote:
> Hopefully make it clearer when to use devm vs drmm.
>
> Signed-off-by: Matthew Auld
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_managed.c | 42 +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 7646f67bda4e..20d705bbc0a3 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -34,6 +34,48 @@
> * during the lifetime of the driver, all the functions are fully concurrent
> * safe. But it is recommended to use managed resources only for resources
> that
> * change rarely, if ever, during the lifetime of the _device instance.
> + *
> + * Note that the distinction between devm and drmm is important to get right.
> + * Consider some hotunplug scenarios, where it is valid for there to be
> multiple
> + * unplugged struct _device instances each being kept alive by an open
> + * driver fd. The driver needs a clean separation between what needs to
> happen
> + * when the struct is removed and what needs to happen when a given
> + * struct _device instance is released, as well as in some cases a more
> + * finer grained marking of critical sections that require hardware
> interaction.
> + * See below.
> + *
> + * devm
> + *
> + * In general use devm for cleaning up anything hardware related. So removing
> + * pci mmaps, releasing interrupt handlers, basically anything hw related.
> The
^
Extra space.
> + * devm release actions are called when the struct is removed,
> shortly
> + * after calling into the drivers struct _driver.remove() callback, if
> this
> + * is a pci device.
> + *
> + * devm can be thought of as an alternative to putting all the hw related
nit: perhaps s/thought/seen ?
> + * cleanup directly in the struct _driver.remove() callback, where the
> + * correct ordering of the unwind steps needs to be manually done in the
> error
> + * path of the struct _driver.probe() and again on the remove side. With
> + * devm this is all done automatically.
> + *
> + * drmm
> + *
> + * In general use this for cleaning up anything software related. So data
> + * structures and the like which are tied to the lifetime of a particular
> struct
> + * _device instance.
> + *
> + * drmm can be thought of as an alternative to putting all the software
> related
nit: perhaps s/thought/seen ?
> + * cleanup directly in the struct _driver.release() callback, where again
> + * the correct ordering of the unwind steps needs to be done manually. As
> with
> + * devm this is instead done automatically.
> + *
> + * Sometimes there is no clean separation between software and hardware,
> which
> + * is where drm_dev_enter() comes in. For example, a driver might have some
> + * state tied to a struct _device instance, for which the same cleanup
> path
> + * is called for both a plugged and unplugged device, and the cleanup itself
> + * might require talking to the device if it's still attached to this
> particular
> + * struct _device. For that we instead mark the device sections. See
> + * drm_dev_enter(), drm_dev_exit() and drm_dev_unplug().
perhaps open up a bit more here?
anyway, everything looks good to me.
Sima, thoughts?
> */
>
> struct drmres_node {
> --
> 2.45.0
>
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes our last fixes for v6.9. drm-intel-fixes-2024-05-08: - Automate CCS Mode setting during engine resets (Andi) - Fix audio time stamp programming for DP (Chaitanya) - Fix parsing backlight BDB data (Karthikeyan) The following changes since commit dd5a440a31fae6e459c0d627162825505361: Linux 6.9-rc7 (2024-05-05 14:06:01 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-05-08 for you to fetch changes up to 43b26bdd2ee5cfca80939be910d5b23a50cd7f9d: drm/i915/bios: Fix parsing backlight BDB data (2024-05-07 09:42:27 -0400) - Automate CCS Mode setting during engine resets (Andi) - Fix audio time stamp programming for DP (Chaitanya) - Fix parsing backlight BDB data (Karthikeyan) Andi Shyti (1): drm/i915/gt: Automate CCS Mode setting during engine resets Chaitanya Kumar Borah (1): drm/i915/audio: Fix audio time stamp programming for DP Karthikeyan Ramasubramanian (1): drm/i915/bios: Fix parsing backlight BDB data drivers/gpu/drm/i915/display/intel_audio.c| 113 ++ drivers/gpu/drm/i915/display/intel_bios.c | 19 + drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 -- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +- 6 files changed, 19 insertions(+), 130 deletions(-)
Re: [PATCH] Revert "drm/i915: Remove extra multi-gt pm-references"
On Tue, May 07, 2024 at 10:54:11AM +0200, Janusz Krzysztofik wrote:
> On Tuesday, 7 May 2024 09:30:15 GMT+2 Nirmoy Das wrote:
> > Hi Janusz,
> >
> >
> > Just realized we need Fixes tag for this.
> >
> > Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references")
>
> Whoever is going to push this patch, please feel free to add this tag.
dim b4-shazam gets that automagically, now it was sent in reply ;)
I just pushed the patch. thanks for the patch and reviews.
>
> Thanks,
> Janusz
>
> >
> >
> > Regards,
> >
> > Nirmoy
> >
> > On 5/6/2024 8:02 PM, Janusz Krzysztofik wrote:
> > > This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb.
> > >
> > > There was a patch supposed to fix an issue of illegal attempts to free a
> > > still active i915 VMA object when parking a GT believed to be idle,
> > > reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for
> > > a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit
> > > f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform").
> > >
> > > However, that fix occurred insufficient -- the issue was still reported by
> > > CI. That wakeref was released on exit from i915_gem_do_execbuffer(), then
> > > potentially before completion of the request and deactivation of its
> > > associated VMAs. Moreover, CI reports indicated that single-GT platforms
> > > also suffered sporadically from the same race.
> > >
> > > Since that issue was fixed by another commit f3c71b2ded5c ("drm/i915/vma:
> > > Fix UAF on destroy against retire race"), the changes introduced by that
> > > insufficient fix were dropped as no longer useful. However, that series
> > > resulted in another VMA UAF scenario now being triggered in CI.
> > >
> > > <4> [260.290809] [ cut here ]
> > > <4> [260.290988] list_del corruption. prev->next should be
> > > 888118c5d990, but was 888118c5a510. (prev=888118c5a510)
> > > <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> > > __list_del_entry_valid_or_report+0xb7/0xe0
> > > ..
> > > <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> > > ...
> > > <4> [260.291087] Call Trace:
> > > <4> [260.291089]
> > > <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> > > <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> > > <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> > > <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [260.292301]
> > > ...
> > > <4> [260.292506] ---[ end trace ]---
> > > <4> [260.292782] general protection fault, probably for non-canonical
> > > address 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> > > <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> > > ...
> > > <4> [260.428756] Call Trace:
> > > <4> [260.431192]
> > > <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> > > <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [639.411134]
> > > ...
> > > <4> [639.449979] ---[ end trace ]---
> > >
> > > We defer actually closing, unbinding and destroying a VMA until next idle
> > > point, or until the object is freed in the meantime. By postponing the
> > > unbind, we allow for the VMA to be reopened by the client, avoiding the
> > > work required to rebind the VMA.
> > >
> > > Starting from commit b0647a5e79b1 ("drm/i915: Avoid live-lock with
> > > i915_vma_parked()"), we assume that as long as a GT is held
Re: [PATCH 08/11] drm/i915: Use drm_fbdev_helper_client_unregister()
On Tue, May 07, 2024 at 01:58:29PM +0200, Thomas Zimmermann wrote:
> Implement struct drm_client_funcs.unregister with the helpers
> drm_fbdev_helper_client_unregister() and remove the custom code
> from the driver. The generic helper is equivalent in functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c | 21 ++---
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index bda702c2cab8e..f1b4543bffc02 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -38,7 +38,6 @@
> #include
>
> #include
> -#include
> #include
> #include
> #include
> @@ -580,25 +579,9 @@ static int intel_fbdev_restore_mode(struct
> drm_i915_private *dev_priv)
> }
>
> /*
> - * Fbdev client and struct drm_client_funcs
> + * struct drm_client_funcs
> */
>
> -static void intel_fbdev_client_unregister(struct drm_client_dev *client)
> -{
> - struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
> - struct drm_device *dev = fb_helper->dev;
> - struct pci_dev *pdev = to_pci_dev(dev->dev);
> -
> - if (fb_helper->info) {
> - vga_switcheroo_client_fb_set(pdev, NULL);
> - drm_fb_helper_unregister_info(fb_helper);
> - } else {
> - drm_fb_helper_unprepare(fb_helper);
> - drm_client_release(_helper->client);
The only real difference is that these 2 calls are inverted in the new
drm_fbdev_helper_client_unregister.
I feel that the releasing after the unprepare sounds more logical,
but if there's no actual issue with that and it is working for
everybody, let's do that.
Reviewed-by: Rodrigo Vivi
Acked-by: Rodrigo Vivi
(to get through drm-misc with everything else if you prefer)
> - kfree(fb_helper);
> - }
> -}
> -
> static int intel_fbdev_client_restore(struct drm_client_dev *client)
> {
> struct drm_i915_private *dev_priv = to_i915(client->dev);
> @@ -644,7 +627,7 @@ static int intel_fbdev_client_hotplug(struct
> drm_client_dev *client)
>
> static const struct drm_client_funcs intel_fbdev_client_funcs = {
> .owner = THIS_MODULE,
> - .unregister = intel_fbdev_client_unregister,
> + .unregister = drm_fbdev_helper_client_unregister,
> .restore= intel_fbdev_client_restore,
> .hotplug= intel_fbdev_client_hotplug,
> };
> --
> 2.44.0
>
Re: [PATCH v2 03/12] drm/i915: Make I2C terminology more inclusive
On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote: > On 5/3/2024 12:34 PM, Rodrigo Vivi wrote: > > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote: > >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced > >> "master/slave" > >> with more appropriate terms. Inspired by and following on to Wolfram's > >> series to fix drivers/i2c/[1], fix the terminology for users of > >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > >> in the specification. > >> > >> Compile tested, no functionality changes intended > >> > >> [1]: > >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > >> > >> Reviewed-by: Rodrigo Vivi > >> Acked-by: Rodrigo Vivi > > > > It looks like the ack is not needed since we are merging this through > > drm-intel-next. But I'm planing to merge this only after seeing the > > main drivers/i2c accepting the new terminology. So we don't have a > > risk of that getting push back and new names there and we having > > to rename it once again. > > Just to be explicit, did you want me to remove the Acked-by in v3, or will > you when you pull > the patch into drm-intel-next? > > > > > (more below) > > > >> Acked-by: Zhi Wang > >> Signed-off-by: Easwar Hariharan > > > > Cc: Jani Nikula > > > > Jani, what bits were you concerned that were not necessarily i2c? > > I believe although not necessarily/directly i2c, I believe they > > are related and could benefit from the massive single shot renable. > > or do you have any better split to suggest here? > > > > (more below) > > > >> --- > >> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - > >> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- > >> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- > >> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- > >> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > >> .../gpu/drm/i915/display/intel_display_core.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- > >> drivers/gpu/drm/i915/display/intel_dvo.c | 14 - > >> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- > >> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- > >> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- > >> drivers/gpu/drm/i915/gvt/edid.c | 28 - > >> drivers/gpu/drm/i915/gvt/edid.h | 4 +-- > >> drivers/gpu/drm/i915/gvt/opregion.c | 2 +- > >> 19 files changed, 119 insertions(+), 119 deletions(-) > >> > > > > >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > >> b/drivers/gpu/drm/i915/display/intel_ddi.c > >> index c17462b4c2ac..64db211148a8 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c > >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > >> @@ -4332,7 +4332,7 @@ static int intel_ddi_compute_config_late(struct > >> intel_encoder *encoder, > >> > >> connector->tile_group->id); > >> > >>/* > >> - * EDP Transcoders cannot be ensalved > >> + * EDP Transcoders cannot be slaves > > > > ^ here > > perhaps you meant 'targeted' ? > > > >> * make them a master always when present > > > > This is not actually I2C related as far as I could tell when I was making the > change, so this was more of a typo fix. > > If we want to improve this, a quick check with the eDP v1.5a spec suggests > using primary/secondary instead, > though in a global fashion rather than specifically for eDP transcoders. > There is also source/sink terminology > in the spec related to DP encoders. > > Which would be a more acceptable change here? hmmm probably better to split the patches and align with the spec naming where it applies. and with i2c name where it applies. > > Thanks, > Easwar
Re: [PATCH v2 03/12] drm/i915: Make I2C terminology more inclusive
On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Reviewed-by: Rodrigo Vivi
> Acked-by: Rodrigo Vivi
It looks like the ack is not needed since we are merging this through
drm-intel-next. But I'm planing to merge this only after seeing the
main drivers/i2c accepting the new terminology. So we don't have a
risk of that getting push back and new names there and we having
to rename it once again.
(more below)
> Acked-by: Zhi Wang
> Signed-off-by: Easwar Hariharan
Cc: Jani Nikula
Jani, what bits were you concerned that were not necessarily i2c?
I believe although not necessarily/directly i2c, I believe they
are related and could benefit from the massive single shot renable.
or do you have any better split to suggest here?
(more below)
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
> drivers/gpu/drm/i915/gvt/edid.c | 28 -
> drivers/gpu/drm/i915/gvt/edid.h | 4 +--
> drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> 19 files changed, 119 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index d0c3880d7f80..493e730c685b 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo,
> u8 addr, u8 *val)
> {
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = ,
> },
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = val,
> @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> {
> u8 buf[2] = { addr, val };
> struct i2c_msg msg = {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 2,
> .buf = buf,
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> return i2c_transfer(dvo->i2c_bus, , 1) == 1;
> }
>
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/** Probes for a CH7017 on the given bus and target address. */
> static bool ch7017_init(struct intel_dvo_device *dvo,
> struct i2c_adapter *adapter)
> {
> @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
> break;
> default:
> DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
> - "slave %d.\n",
> - val, adapter->name, dvo->slave_addr);
> + "target %d.\n",
> + val, adapter->name, dvo->target_addr);
> goto fail;
> }
>
> DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
> - str, a
Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Signed-off-by: Easwar Hariharan
I'm glad to see this change!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
> drivers/gpu/drm/i915/gvt/edid.c | 28 -
> drivers/gpu/drm/i915/gvt/edid.h | 4 +--
> drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> 19 files changed, 119 insertions(+), 119 deletions(-)
The chances of conflicts are high with this many changes,
but should be easy enough to deal with later, so feel free
to move with this i915 patch on any other tree and we catch-up
later.
Acked-by: Rodrigo Vivi
>
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index d0c3880d7f80..493e730c685b 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo,
> u8 addr, u8 *val)
> {
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = ,
> },
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = val,
> @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> {
> u8 buf[2] = { addr, val };
> struct i2c_msg msg = {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 2,
> .buf = buf,
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> return i2c_transfer(dvo->i2c_bus, , 1) == 1;
> }
>
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/** Probes for a CH7017 on the given bus and target address. */
> static bool ch7017_init(struct intel_dvo_device *dvo,
> struct i2c_adapter *adapter)
> {
> @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
> break;
> default:
> DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
> - "slave %d.\n",
> - val, adapter->name, dvo->slave_addr);
> + "target %d.\n",
> + val, adapter->name, dvo->target_addr);
> goto fail;
> }
>
> DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
> - str, adapter->name, dvo->slave_addr);
> + str, adapter->name, dvo->target_addr);
> return true;
>
> fail:
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> index 2e8e85da5a40..534b8544e0a4 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> +++ b/drivers/gpu/drm/
[PULL] drm-intel-next
Hi Dave and Sima,
Here goes one extra, and really the last one targeting 6.10.
We have decided to do this extra one so we could include the
good clean-up on i915/xe's fbdev work done by Thomas Zimmermann.
And it looks like he has more work on top of that, so it would
be good to propagate this initial one sooner and sync our trees.
Thanks,
Rodrigo.
drm-intel-next-2024-04-30:
Core DRM:
- Export drm_client_dev_unregister (Thomas Zimmermann)
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
The following changes since commit 6068bc209ac8d07a5d04e93f168465195e22a4cc:
drm/i915/dsi: pass display to register macros instead of implicit variable
(2024-04-23 17:00:14 +0300)
are available in the Git repository at:
https://anongit.freedesktop.org/git/drm/drm-intel
tags/drm-intel-next-2024-04-30
for you to fetch changes up to 6f1923f54d77942376f47d05b08cddca19fc397f:
drm/i915/dpio: Extract vlv_dpio_phy_regs.h (2024-04-30 21:20:52 +0300)
Core DRM:
- Export drm_client_dev_unregister (Thomas Zimmermann)
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
Jani Nikula (13):
drm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept base
drm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2
drm/i915/audio: move LPE audio regs to intel_audio_regs.h
drm/i915/color: move palette registers to intel_color_regs.h
drm/i915/display: split out intel_fbc_regs.h from i915_reg.h
drm/i915/display: split out intel_sprite_regs.h from i915_reg.h
drm/i915: pass dev_priv explicitly to PALETTE
drm/i915: pass dev_priv explicitly to PIPE_WGC_C01_C00
drm/i915: pass dev_priv explicitly to PIPE_WGC_C02
drm/i915: pass dev_priv explicitly to PIPE_WGC_C11_C10
drm/i915: pass dev_priv explicitly to PIPE_WGC_C12
drm/i915: pass dev_priv explicitly to PIPE_WGC_C21_C20
drm/i915: pass dev_priv explicitly to PIPE_WGC_C22
Thomas Zimmermann (6):
drm/client: Export drm_client_dev_unregister()
drm/i915: Move fbdev functions
drm/i915: Initialize fbdev DRM client with callback functions
drm/{i915,xe}: Unregister in-kernel clients
drm/{i915,xe}: Implement fbdev client callbacks
drm/{i915, xe}: Implement fbdev emulation as in-kernel client
Ville Syrjälä (14):
drm/i915/dpio: Remove pointless VLV_PCS01_DW8 read
drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/
drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/
drm/i915/dpio: Fix VLV DPIO PLL register dword numbering
drm/i915/dpio: Remove pointless variables from vlv/chv DPLL code
drm/i915/dpio: Rename some variables
drm/i915/dpio: s/port/ch/
drm/i915/dpio: s/pipe/ch/
drm/i915/dpio: Derive the phy from the port rather than pipe in encoder
hooks
drm/i915/dpio: Give VLV DPIO group register a clearer name
drm/i915/dpio: Rename a few CHV DPIO PHY registers
drm/i915/dpio: Clean up VLV/CHV DPIO PHY register defines
drm/i915/dpio: Clean up the vlv/chv PHY register bits
drm/i915/dpio: Extract vlv_dpio_phy_regs.h
drivers/gpu/drm/drm_client.c | 13 +
drivers/gpu/drm/i915/display/intel_audio_regs.h| 16 +
drivers/gpu/drm/i915/display/intel_color.c | 53 +-
drivers/gpu/drm/i915/display/intel_color_regs.h| 42 +-
drivers/gpu/drm/i915/display/intel_display.c |2 +-
.../gpu/drm/i915/display/intel_display_driver.c| 24 +-
.../drm/i915/display/intel_display_power_well.c| 16 +-
.../gpu/drm/i915/display/intel_display_reg_defs.h | 22 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 148 ++-
drivers/gpu/drm/i915/display/intel_dpll.c | 262 +++--
drivers/gpu/drm/i915/display/intel_fbc.c |1 +
drivers/gpu/drm/i915/display/intel_fbc_regs.h | 120 +++
drivers/gpu/drm/i915/display/intel_fbdev.c | 265 ++---
drivers/gpu/drm/i915/display/intel_fbdev.h | 29 +-
drivers/gpu/drm/i915/display/intel_lpe_audio.c |2 +-
drivers/gpu/drm/i915/display/intel_psr_regs.h | 38 +-
drivers/gpu/drm/i915/display/intel_sprite.c|1 +
drivers/gpu/drm/i915/display/intel_sprite_regs.h | 348 ++
drivers/gpu/drm/i915/display/vlv_dpio_phy_regs.h | 309 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c|2 +
drivers/gpu/drm/i915/gvt/cmd_parser.c |1 +
drivers/gpu/drm/i915/gvt/display.c |1 +
drivers/gpu/drm/i915/gvt/fb_decoder.c |5 +-
drivers/gpu/drm/i915/gvt/handlers.c|1 +
Re: [PATCH] MAINTAINERS: Move the drm-intel repo location to fd.o GitLab
On Fri, Apr 26, 2024 at 05:02:54PM +0100, Tvrtko Ursulin wrote: > > > On 26/04/2024 16:47, Lucas De Marchi wrote: > > On Wed, Apr 24, 2024 at 01:41:59PM GMT, Ryszard Knop wrote: > > > The drm-intel repo is moving from the classic fd.o git host to GitLab. > > > Update its location with a URL matching other fd.o GitLab kernel trees. > > > > > > Signed-off-by: Ryszard Knop > > > > Acked-by: Lucas De Marchi > > > > Also Cc'ing maintainers > > Thanks, > > Acked-by: Tvrtko Ursulin Acked-by: Rodrigo Vivi > > Regards, > > Tvrtko > > > > --- > > > MAINTAINERS | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index d6327dc12cb1..fbf7371a0bb0 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -10854,7 +10854,7 @@ W: > > > https://drm.pages.freedesktop.org/intel-docs/ > > > Q: http://patchwork.freedesktop.org/project/intel-gfx/ > > > B: > > > https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html > > > C: irc://irc.oftc.net/intel-gfx > > > -T: git git://anongit.freedesktop.org/drm-intel > > > +T: git https://gitlab.freedesktop.org/drm/i915/kernel.git > > > F: Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > > F: Documentation/gpu/i915.rst > > > F: drivers/gpu/drm/ci/xfails/i915* > > > -- > > > 2.44.0 > > >
Re: [PATCH] drm/i915/gt: Automate CCS Mode setting during engine resets
On Fri, Apr 26, 2024 at 02:07:23AM +0200, Andi Shyti wrote:
> We missed setting the CCS mode during resume and engine resets.
> Create a workaround to be added in the engine's workaround list.
> This workaround sets the XEHP_CCS_MODE value at every reset.
>
> The issue can be reproduced by running:
>
> $ clpeak --kernel-latency
>
> Without resetting the CCS mode, we encounter a fence timeout:
>
> Fence expiration time out i915-:03:00.0:clpeak[2387]:2!
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895
> Fixes: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload")
> Reported-by: Gnattu OC
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
Reviewed-by: Rodrigo Vivi
> ---
> Hi Gnattu,
>
> thanks again for reporting this issue and for your prompt
> replies on the issue. Would you give this patch a chance?
>
> Andi
>
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +++-
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> index 044219c5960a..99b71bb7da0a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> @@ -8,14 +8,14 @@
> #include "intel_gt_ccs_mode.h"
> #include "intel_gt_regs.h"
>
> -void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +unsigned int intel_gt_apply_ccs_mode(struct intel_gt *gt)
> {
> int cslice;
> u32 mode = 0;
> int first_ccs = __ffs(CCS_MASK(gt));
>
> if (!IS_DG2(gt->i915))
> - return;
> + return 0;
>
> /* Build the value for the fixed CCS load balancing */
> for (cslice = 0; cslice < I915_MAX_CCS; cslice++) {
> @@ -35,5 +35,5 @@ void intel_gt_apply_ccs_mode(struct intel_gt *gt)
>XEHP_CCS_MODE_CSLICE_MASK);
> }
>
> - intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
> + return mode;
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> index 9e5549caeb26..55547f2ff426 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> @@ -8,6 +8,6 @@
>
> struct intel_gt;
>
> -void intel_gt_apply_ccs_mode(struct intel_gt *gt);
> +unsigned int intel_gt_apply_ccs_mode(struct intel_gt *gt);
>
> #endif /* __INTEL_GT_CCS_MODE_H__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 68b6aa11bcf7..58693923bf6c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2703,6 +2703,7 @@ add_render_compute_tuning_settings(struct intel_gt *gt,
> static void ccs_engine_wa_mode(struct intel_engine_cs *engine, struct
> i915_wa_list *wal)
> {
> struct intel_gt *gt = engine->gt;
> + u32 mode;
>
> if (!IS_DG2(gt->i915))
> return;
> @@ -2719,7 +2720,8 @@ static void ccs_engine_wa_mode(struct intel_engine_cs
> *engine, struct i915_wa_li
>* After having disabled automatic load balancing we need to
>* assign all slices to a single CCS. We will call it CCS mode 1
>*/
> - intel_gt_apply_ccs_mode(gt);
> + mode = intel_gt_apply_ccs_mode(gt);
> + wa_masked_en(wal, XEHP_CCS_MODE, mode);
> }
>
> /*
> --
> 2.43.0
>
[PULL] drm-intel-next
Hi Sima and Dave,
Here goes our last pull request towards 6.10.
drm-intel-next-2024-04-24:
Core Changes:
- Some DP/DP_MST DRM helpers (Imre)
Driver Changes (i915 Display):
- PLL refactoring (Ville)
- Limit eDP MSO pipe only for display version 20 (Luca)
- More display refactor towards independence from i915 dev_priv (Jani)
- QGV/SAGV related refactor (Stanislav)
- Few MTL/DSC and a UHBR monitor fix (Imre)
- BXT/GLK per-lane vswing and PHY reg cleanup (Ville)
The following changes since commit 700c34019555392a348f8c03237c1ebb5bf53eb4:
drm/i915/display: tie DMC wakelock to DC5/6 state transitions (2024-04-17
11:41:23 +0300)
are available in the Git repository at:
https://anongit.freedesktop.org/git/drm/drm-intel
tags/drm-intel-next-2024-04-24
for you to fetch changes up to 6068bc209ac8d07a5d04e93f168465195e22a4cc:
drm/i915/dsi: pass display to register macros instead of implicit variable
(2024-04-23 17:00:14 +0300)
Core Changes:
- Some DP/DP_MST DRM helpers (Imre)
Driver Changes (i915 Display):
- PLL refactoring (Ville)
- Limit eDP MSO pipe only for display version 20 (Luca)
- More display refactor towards independence from i915 dev_priv (Jani)
- QGV/SAGV related refactor (Stanislav)
- Few MTL/DSC and a UHBR monitor fix (Imre)
- BXT/GLK per-lane vswing and PHY reg cleanup (Ville)
Imre Deak (11):
drm/i915/dp: Fix DSC line buffer depth programming
drm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limit
drm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bpp
drm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp
limit
drm/i915/dp_mst: Account with the DSC DPT bpp limit on MTL
drm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limit
drm/dp: Add drm_dp_128b132b_supported()
drm/dp_mst: Factor out drm_dp_mst_port_is_logical()
drm/dp_mst: Add drm_dp_mst_aux_for_parent()
drm/i915/dp_mst: Make HBLANK expansion quirk work for logical ports
drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates
Jani Nikula (19):
drm/i915: use system include for drm headers
drm/i915/display: add intel_display -> drm_device backpointer
drm/i915/display: add generic to_intel_display() macro
drm/i915: add generic __to_intel_display()
drm/i915/display: accept either i915 or display for feature tests
drm/i915/quirks: convert struct drm_i915_private to struct intel_display
drm/i915/display: rename __intel_wait_for_register_nowl() to indicate
intel_de_
drm/i915/dmc: convert dmc wakelock interface to struct intel_display
drm/i915/de: allow intel_display and drm_i915_private for de functions
drm/i915/dmc: use struct intel_display more
drm/i915/dmc: handle request_firmware() errors separately
drm/i915/dmc: improve firmware parse failure propagation
drm/i915/dmc: split out per-platform firmware path selection
drm/i915/dmc: change how to disable DMC firmware using module param
drm/i915/display: move dmc_firmware_path to display params
drm/i915/dsi: remove unused _MIPIA_AUTOPWG register definition
drm/i915/dsi: add VLV_ prefix to VLV only register macros
drm/i915/dsi: unify connector/encoder type and name usage
drm/i915/dsi: pass display to register macros instead of implicit variable
Luca Coelho (1):
drm/i915: limit eDP MSO pipe only for display version 20 and below
Stanislav Lisovskiy (4):
drm/i915/display: Add meaningful traces for QGV point info error handling
drm/i915/display: Extract code required to calculate max qgv/psf gv point
drm/i915/display: Disable SAGV on bw init, to force QGV point
recalculation
drm/i915/display: handle systems with duplicate psf gv points
Ville Syrjälä (26):
drm/i915: Replace hand rolled PLL state dump with
intel_dpll_dump_hw_state()
drm/i915: Use printer for the rest of PLL debugfs dump
drm/i915: Rename PLL hw_state variables/arguments
drm/i915: Introduce some local PLL state variables
drm/i915: Extract ilk_fb_cb_factor()
drm/i915: Extract ilk_dpll_compute_fp()
drm/i915: Extract i9xx_dpll_get_hw_state()
drm/i915: Pass the PLL hw_state to pll->enable()
drm/i915: Extract i965_dpll_md()
drm/i915: Extract {i9xx,i8xx,ilk,vlv,chv}_dpll()
drm/i915: Inline {i9xx,ilk}_update_pll_dividers()
drm/i915: Modernize i9xx_pll_refclk()
drm/i915: Drop pointless 'crtc' argument from *_crtc_clock_get()
drm/i915: s/pipe_config/crtc_state/ in legacy PLL code
drm/i915: Add local DPLL 'hw_state' variables
drm/i915: Carve up struct intel_dpll_hw_state
drm/i915: Unionize dpll_hw_state
drm/i915: Suck snps/cx0 PLL states into dpll_hw_state
drm/i915/dpio: Clean up bxt/glk PHY registers
drm/i915/dpio: Add
Re: [PATCH v3 1/4] drm: add devm release action
On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote: > On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote: > > On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote: > > > > > > On 23/04/24 02:24, Rodrigo Vivi wrote: > > > > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote: > > > >> In scenarios where drm_dev_put is directly called by driver we want to > > > >> release devm_drm_dev_init_release action associated with struct > > > >> drm_device. > > > >> > > > >> v2: Directly expose the original function, instead of introducing a > > > >> helper (Rodrigo) > > > >> > > > >> v3: add kernel-doc (Maxime Ripard) > > > >> > > > >> Cc: Maxime Ripard > > > >> Cc: Thomas Hellstr_m > > > >> Cc: Rodrigo Vivi > > > >> > > > > please avoid these empty lines here cc, rv-b, sign-offs, links, > > > > etc are all in the same block. > > > ok. > > > > > > > >> Reviewed-by: Rodrigo Vivi > > > >> Signed-off-by: Aravind Iddamsetty > > > >> --- > > > >> drivers/gpu/drm/drm_drv.c | 13 + > > > >> include/drm/drm_drv.h | 2 ++ > > > >> 2 files changed, 15 insertions(+) > > > >> > > > >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > >> index 243cacb3575c..9d0409165f1e 100644 > > > >> --- a/drivers/gpu/drm/drm_drv.c > > > >> +++ b/drivers/gpu/drm/drm_drv.c > > > >> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device > > > >> *parent, > > > >>devm_drm_dev_init_release, dev); > > > >> } > > > >> > > > >> +/** > > > >> + * devm_drm_dev_release_action - Call the final release action of the > > > >> device > > > > Seeing the doc here gave me a second thought > > > > > > > > the original release should be renamed to _devm_drm_dev_release > > > > and this should be called devm_drm_dev_release without the 'action' > > > > word. > > > i believe, was suggested earlier to directly expose the main function, is > > > there any reason to have a __ version ? > > > > No no, just ignore me. Just remove the '_action' and don't change the other. > > > > I don't like exposing the a function with '__'. what would '__' that mean? > > This is what I meant on the first comment. > > > > Now, I believe that we don't need the '_action'. What does the 'action' > > mean? > > > > the devm_drm_dev_release should be enough. But then I got confused and > > I thought it would conflict with the original released function name. > > But I misread it. > > I don't think devm_drm_dev_release is a good name either. Just like any > other devm_* function that cancels what a previous one has been doing > (devm_kfree, devm_backlight_device_unregister, devm_nvmem_device_put, > etc.) it should be called devm_drm_dev_put or something similar. I see what you mean, but I don't believe the 'put' is the best option, for 2 reasons: - in general, we have put paired with gets and this has not get equivalent - this bypass the regular get/put mechanism and forces the releases that would be done only after all drm_dev_put() taking ref to zero. > > Maxime
Re: [PATCH v3 1/4] drm: add devm release action
On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
>
> On 23/04/24 02:24, Rodrigo Vivi wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> release devm_drm_dev_init_release action associated with struct
> >> drm_device.
> >>
> >> v2: Directly expose the original function, instead of introducing a
> >> helper (Rodrigo)
> >>
> >> v3: add kernel-doc (Maxime Ripard)
> >>
> >> Cc: Maxime Ripard
> >> Cc: Thomas Hellstr_m
> >> Cc: Rodrigo Vivi
> >>
> > please avoid these empty lines here cc, rv-b, sign-offs, links,
> > etc are all in the same block.
> ok.
> >
> >> Reviewed-by: Rodrigo Vivi
> >> Signed-off-by: Aravind Iddamsetty
> >> ---
> >> drivers/gpu/drm/drm_drv.c | 13 +
> >> include/drm/drm_drv.h | 2 ++
> >> 2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index 243cacb3575c..9d0409165f1e 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device *parent,
> >>devm_drm_dev_init_release, dev);
> >> }
> >>
> >> +/**
> >> + * devm_drm_dev_release_action - Call the final release action of the
> >> device
> > Seeing the doc here gave me a second thought
> >
> > the original release should be renamed to _devm_drm_dev_release
> > and this should be called devm_drm_dev_release without the 'action' word.
> i believe, was suggested earlier to directly expose the main function, is
> there any reason to have a __ version ?
No no, just ignore me. Just remove the '_action' and don't change the other.
I don't like exposing the a function with '__'. what would '__' that mean?
This is what I meant on the first comment.
Now, I believe that we don't need the '_action'. What does the 'action' mean?
the devm_drm_dev_release should be enough. But then I got confused and
I thought it would conflict with the original released function name.
But I misread it.
This also made me ask myself if we really should use 'devm' prefix there
as well.
> >
> >> + * @dev: DRM device
> >> + *
> >> + * In scenarios where drm_dev_put is directly called by driver we want to
> >> release
> >> + * devm_drm_dev_init_release action associated with struct drm_device.
> > But also, this made me more confusing on why this is needed.
> > Why can't we call put and get back?
> IIUC, the ownership of drm_dev_get is with devm_drm_dev_alloc
> and the release is tied to a devm action hence we needed this.
you are right, but it is just a refcount. you are putting that one
back on behalf of the init path, to force the refcount to 0, and
then grabbing it back on init behalf after the flr. So in the
end it is the same.
Then with this flow we also can check if we are really force the
disconnection of eveybody before we are ready to put the last
ref that would call the release fn.
but well, I'm just brainstorming some thoughts on possibilities
of a clear release without forcing that... it would be good
to run some experiments to see if that is possible. if not,
then let's go with this forced one.
>
> >
> > The next needs to make it clear on why we need to release in these
> > scenarios regarless of the number of counters. But do we really
> > want this?
> in our case post tFLR we need to reprobe the device, but the previousdrm
> instance
> is not destroyed with just calling pci_remove as it is tied to PDEV lifetime
> which is not destroyed hence we need to call the last release action ourself
> so that the final release is called.
> >
> > Can we block the flr if we have users? Perhaps this is the reason
> > that on my side the flr was not that clean? beucase I had display
> > so I had clients connected?
> the display side error is due to power wells, post FLR the power wells are
> already
> disabled while we try to disable them from driver again it is throwing
> warnings.
so we probably need to tell display that we are going to be disabled.
probably the same patch that we need for d3cold:
https://lore.kernel.org/all/20240227183725.505699-3-rodrigo.v...@intel.com/
>
> Thanks,
>
> Aravind.
> >
> >> + */
> >> +void devm_drm_dev_release_action(struct drm_device *dev)
> >> +{
> >> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> >> +
Re: [PATCH v3 1/4] drm: add devm release action
On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead of introducing a
> helper (Rodrigo)
>
> v3: add kernel-doc (Maxime Ripard)
>
> Cc: Maxime Ripard
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
please avoid these empty lines here cc, rv-b, sign-offs, links,
etc are all in the same block.
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 13 +
> include/drm/drm_drv.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..9d0409165f1e 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +/**
> + * devm_drm_dev_release_action - Call the final release action of the device
Seeing the doc here gave me a second thought
the original release should be renamed to _devm_drm_dev_release
and this should be called devm_drm_dev_release without the 'action' word.
> + * @dev: DRM device
> + *
> + * In scenarios where drm_dev_put is directly called by driver we want to
> release
> + * devm_drm_dev_init_release action associated with struct drm_device.
But also, this made me more confusing on why this is needed.
Why can't we call put and get back?
The next needs to make it clear on why we need to release in these
scenarios regarless of the number of counters. But do we really
want this?
Can we block the flr if we have users? Perhaps this is the reason
that on my side the flr was not that clean? beucase I had display
so I had clients connected?
> + */
> +void devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..fa9123684874 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> --
> 2.25.1
>
Re: [PATCH v2 1/4] drm: add devm release action
On Wed, Apr 17, 2024 at 02:11:42PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead of introducing a
> helper (Rodrigo)
>
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
> Reviewed-by: Rodrigo Vivi
Sima, Dave, or drm-misc, ack to get this through drm-xe-next?
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..ba60cbb0725f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,12 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +void devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..fa9123684874 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> --
> 2.25.1
>
[PULL] drm-intel-next
over uncore ones drm/i915: use fine grained -Woverride-init disable drm/i915/display: move dmc_firmware_path to display params Revert "drm/i915/display: move dmc_firmware_path to display params" drm/i915: use IS_JASPERLAKE()/IS_ELKHARTLAKE() instead of IS_PLATFORM() drm/i915/dmc: define firmware URL locally drm/i915: move i915_fixed.h to display/intel_fixed.h drm/xe/display: clean up a lot of cruft from compat i915_drv.h drm/xe/display: remove compat i915_gem.h drm/xe/display: clean up compat i915_vgpu.h drm/i915/gt: drop display clock info from gt debugfs drm/i915: move skl_preferred_vco_freq to display substruct drm/i915: move max_dotclk_freq to display substruct drm/i915: move vblank_enabled to display substruct drm/i915: move display_irqs_enabled to display substruct drm/i915: move de_irq_mask to display substruct drm/i915: move pipestat_irq_mask to display substruct drm/i915: use check_add_overflow() and drop local variants drm/i915/pps: move pps debugfs file to intel_pps.c Janusz Krzysztofik (1): drm/i915/hwmon: Fix locking inversion in sysfs getter Jonathon Hall (1): drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() Joonas Lahtinen (1): drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c José Roberto de Souza (1): drm/i915: Do not print 'pxp init failed with 0' when it succeed Jouni Högander (23): drm/i915/display: Make intel_dp_aux_fw_sync_len available for PSR code drm/i915/psr: Improve fast and IO wake lines calculation drm/i915/psr: Calculate IO wake and fast wake lines for DISPLAY_VER < 12 drm/i915/display: Increase number of fast wake precharge pulses drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage drm/i915/display: Add definition for MCURSOR_MODE_64_2B drm/i915/display: Implement Wa_16021440873 drm/i915/psr: Add missing ALPM AUX-Less register definitions drm/i915/psr: Calculate aux less wake time drm/i915/psr: Silence period and lfps half cycle drm/i915/psr: Enable ALPM on source side for eDP Panel replay drm/i915/psr: Do not write ALPM configuration for PSR1 or DP2.0 Panel Replay drm/i915/psr: Add some documentation of variables used in psr code drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as well drm/i915/psr: Intel_psr_pause/resume needs to support panel replay drm/i915/psr: Do not update phy power state in case of non-eDP panel replay drm/i915/psr: Check possible errors for panel replay as well drm/i915/psr: Do not write registers/bits not applicable for panel replay drm/i915/psr: Unify panel replay enable/disable sink drm/i915/psr: Panel replay has to be enabled before link training drm/i915/psr: Use crtc_state->port_clock instead of intel_dp->link_rate Juha-Pekka Heikkila (1): drm/i915/display: Disable AuxCCS framebuffers if built for Xe Luca Coelho (4): drm/i915/display: add support for DMC wakelocks drm/i915/display: don't allow DMC wakelock on older hardware drm/i915/display: add module parameter to enable DMC wakelock drm/i915/display: tie DMC wakelock to DC5/6 state transitions Lucas De Marchi (7): drm/i915: Drop dead code for xehpsdv drm/i915: Remove XEHP_FWRANGES() drm/i915: Stop inheriting IP_VER(12, 50) drm/i915: Update IP_VER(12, 50) drm/i915: Drop dead code for pvc drm/i915: Remove special handling for !RCS_MASK() drm/i915: Delete stray .rej file Mitul Golani (9): drm/dp: Add support to indicate if sink supports AS SDP drm/dp: Add Adaptive Sync SDP logging drm/i915/display: Add crtc state dump for Adaptive Sync SDP drm/i915/dp: Add Read/Write support for Adaptive Sync SDP drm/i915/dp: Add wrapper function to check AS SDP drm/i915/display: Compute AS SDP parameters drm/i915/display: Add state checker for Adaptive Sync SDP drm/i915/display: Compute vrr_vsync params drm/i915/display: Read/Write Adaptive Sync SDP Nirmoy Das (1): drm/i915: Add missing doc for drm_i915_reset_stats Radhakrishna Sripada (7): drm/i915: Pass size to oprom_get_vbt drm/i915: Pass size to spi_oprom_get_vbt drm/i915: Move vbt read from firmware to intel_bios.c drm/i915: Extract opregion vbt presence check drm/i915: Duplicate opregion vbt memory drm/i915: Show bios vbt when read from firmware/spi/oprom drm/i915: Reuse RPLU cdclk fns for MTL+ Ravi Kumar Vodapalli (1): drm/i915: Add new PCI IDs to DG2 platform in driver Rodrigo Vivi (1): Merge drm/drm-next into drm-intel-next Shekhar Chauhan (1): drm/i915/dp: Increase idle pattern wait timeout to 2ms Stanislav Lis
Re: [PATCH] drm/dp: correct struct member name in documentation
On Thu, Apr 11, 2024 at 12:55:29PM -0400, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Wednesday, April 10, 2024 9:49 PM
> > To: Golani, Mitulkumar Ajitkumar ;
> > tzimmerm...@suse.de; mrip...@kernel.org;
> > maarten.lankho...@linux.intel.com
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> > Nautiyal,
> > Ankit K ; Nikula, Jani ;
> > s...@canb.auug.org.au
> > Subject: Re: [PATCH] drm/dp: correct struct member name in documentation
> >
> > On Fri, Apr 05, 2024 at 12:21:59PM +0530, Mitul Golani wrote:
> > > Correct struct member name to 'mode' instead of 'operation mode'
> > > in 'drm_dp_as_sdp' structure description.
> > >
> > > Fixes: 0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
> >
> > Probably good to avoid this 'Fixes:' tag, and only use that for real code
> > bugs.
>
> Thank you for inputs.. I understood and I will take the future note. Please
> suggest if required to update the change with new revision or we can take
> care while merge.. ?
I can remove it while merging.
I just need an ack from drm or drm-misc maintainers to merge this through
drm-intel-next.
Sima, Dave?
>
> >
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> >
> > drm-misc folks, ack to get this through drm-intel-next, where the original
> > patch
> > is?
> >
> > Thanks,
> > Rodrigo
> >
> > > Cc: Mitul Golani
> > > Cc: Ankit Nautiyal
> > > Cc: Jani Nikula
> > > Signed-off-by: Mitul Golani
> >
> > > ---
> > > include/drm/display/drm_dp_helper.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/drm/display/drm_dp_helper.h
> > > b/include/drm/display/drm_dp_helper.h
> > > index baf9949ff96f..6799f57d635c 100644
> > > --- a/include/drm/display/drm_dp_helper.h
> > > +++ b/include/drm/display/drm_dp_helper.h
> > > @@ -112,7 +112,7 @@ struct drm_dp_vsc_sdp {
> > > * @target_rr: Target Refresh
> > > * @duration_incr_ms: Successive frame duration increase
> > > * @duration_decr_ms: Successive frame duration decrease
> > > - * @operation_mode: Adaptive Sync Operation Mode
> > > + * @mode: Adaptive Sync Operation Mode
> > > */
> > > struct drm_dp_as_sdp {
> > > unsigned char sdp_type;
> > > --
> > > 2.25.1
> > >
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Tue, Apr 16, 2024 at 12:02:10PM -0700, Dixit, Ashutosh wrote:
> On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private
> > > *i915)
> > >
> > > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > > {
> > > - fetch_and_zero(>hwmon);
> > > + struct i915_hwmon *hwmon = fetch_and_zero(>hwmon);
> > > + struct hwm_drvdata *ddat = >ddat;
> > > + struct intel_gt *gt;
> > > + int i;
> > > +
> > > + if (!hwmon)
> > > + return;
> >
> > "that's too late", we are going to hear from static analyzer tools.
> >
> > beter to move ddat = >ddat; after this return.
>
> Yeah, I worried a lot about it :/ But then finally decided (and verified)
> that we are never actually dereferencing the (possibly NULL) pointer.
yeap, another acceptable approach is to simply remove this check entirely.
>
> But not sure about static analyzer tools, maybe you are right, I'll move
> it.
>
> > with that,
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks a lot :)
>
> Ashutosh
>
> >
> > > +
> > > + for_each_gt(gt, i915, i) {
> > > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> > > +
> > > + if (ddat_gt->hwmon_dev) {
> > > + hwmon_device_unregister(ddat_gt->hwmon_dev);
> > > + ddat_gt->hwmon_dev = NULL;
> > > + }
> > > + }
> > > +
> > > + if (ddat->hwmon_dev)
> > > + hwmon_device_unregister(ddat->hwmon_dev);
> > > +
> > > + mutex_destroy(>hwmon_lock);
> > > + kfree(hwmon);
> > > }
> > > --
> > > 2.41.0
> > >
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Mon, Apr 15, 2024 at 03:36:12PM -0700, Ashutosh Dixit wrote:
> When both hwmon and hwmon drvdata (on which hwmon depends) are device
> managed resources, the expectation, on device unbind, is that hwmon will be
> released before drvdata. However, in i915 there are two separate code
> paths, which both release either drvdata or hwmon and either can be
> released before the other. These code paths (for device unbind) are as
> follows (see also the bug referenced below):
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_group+0xb2/0x110
> component_unbind_all+0x8d/0xa0
> component_del+0xa5/0x140
> intel_pxp_tee_component_fini+0x29/0x40 [i915]
> intel_pxp_fini+0x33/0x80 [i915]
> i915_driver_remove+0x4c/0x120 [i915]
> i915_pci_remove+0x19/0x30 [i915]
> pci_device_remove+0x32/0xa0
> device_release_driver_internal+0x19c/0x200
> unbind_store+0x9c/0xb0
>
> and
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_all+0x8a/0xc0
> device_unbind_cleanup+0x9/0x70
> device_release_driver_internal+0x1c1/0x200
> unbind_store+0x9c/0xb0
>
> This means that in i915, if use devm, we cannot gurantee that hwmon will
> always be released before drvdata. Which means that we have a uaf if hwmon
> sysfs is accessed when drvdata has been released but hwmon hasn't.
>
> The only way out of this seems to be do get rid of devm_ and release/free
> everything explicitly during device unbind.
>
> v2: Change commit message and other minor code changes
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 41 +++
> 1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347..46c24b1ee6df 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -792,7 +792,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!IS_DGFX(i915))
> return;
>
> - hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
> + hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
> if (!hwmon)
> return;
>
> @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> hwm_get_preregistration_info(i915);
>
> /* hwmon_dev points to device hwmon */
> - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
> - ddat,
> - _chip_info,
> - hwm_groups);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> + ddat,
> + _chip_info,
> + hwm_groups);
> if (IS_ERR(hwmon_dev)) {
> i915->hwmon = NULL;
> return;
> @@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
> hwmon_energy_input, 0))
> continue;
>
> - hwmon_dev = devm_hwmon_device_register_with_info(dev,
> ddat_gt->name,
> - ddat_gt,
> -
> _gt_chip_info,
> - NULL);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
> + ddat_gt,
> + _gt_chip_info,
> + NULL);
> if (!IS_ERR(hwmon_dev))
> ddat_gt->hwmon_dev = hwmon_dev;
> }
> @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>
> void i915_hwmon_unregister(struct drm_i915_private *i915)
> {
> - fetch_and_zero(>hwmon);
> + struct i915_hwmon *hwmon = fetch_and_zero(>hwmon);
> + struct hwm_drvdata *ddat = >ddat;
> + struct intel_gt *gt;
> + int i;
> +
> + if (!hwmon)
> + return;
"that's too late", we are going to hear from static analyzer tools.
beter to move ddat = >ddat; after this return.
with that,
Reviewed-by: Rodrigo Vivi
> +
> + for_each_gt(gt, i915, i) {
> + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> +
> + if (ddat_gt->hwmon_dev) {
> + hwmon_device_unregister(ddat_gt->hwmon_dev);
> + ddat_gt->hwmon_dev = NULL;
> + }
> + }
> +
> + if (ddat->hwmon_dev)
> + hwmon_device_unregister(ddat->hwmon_dev);
> +
> + mutex_destroy(>hwmon_lock);
> + kfree(hwmon);
> }
> --
> 2.41.0
>
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
On Tue, Apr 16, 2024 at 10:09:46AM +0200, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> On Tuesday, 16 April 2024 03:16:31 CEST Rodrigo Vivi wrote:
> > On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> > > We defer actually closing, unbinding and destroying a VMA until next idle
> > > point, or until the object is freed in the meantime. By postponing the
> > > unbind, we allow for the VMA to be reopened by the client, avoiding the
> > > work required to rebind the VMA.
> > >
> > > It was assumed that as long as a GT is held idle, no VMA would be reopened
> > > while we destroy them. That assumption is no longer true in multi-GT
> > > configurations, where a VMA we reopen may be handled by a GT different
> > > from the one that we already keep active via its engine while we set up
> > > an execbuf request.
> > >
> > > <4> [260.290809] [ cut here ]
> > > <4> [260.290988] list_del corruption. prev->next should be
> > > 888118c5d990, but was 888118c5a510. (prev=888118c5a510)
> > > <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> > > __list_del_entry_valid_or_report+0xb7/0xe0
> > > ..
> > > <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> > > ...
> > > <4> [260.291087] Call Trace:
> > > <4> [260.291089]
> > > <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> > > <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> > > <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> > > <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [260.292301]
> > > ...
> > > <4> [260.292506] ---[ end trace ]---
> > > <4> [260.292782] general protection fault, probably for non-canonical
> > > address 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> > > <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> > > ...
> > > <4> [260.428756] Call Trace:
> > > <4> [260.431192]
> > > <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> > > <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [639.411134]
> > > ...
> > > <4> [639.449979] ---[ end trace ]---
> > >
> > > As soon as we start unbinding and destroying a VMA, marked it as parked,
> > > and also keep it marked as closed for the rest of its life. When a VMA
> > > to be opened occurs closed, reopen it only if not yet parked.
> > >
> > > v3: Fix misplaced brackets.
> > > v2: Since we no longer re-init the VMA closed list link on VMA park so it
> > > looks like still on a list, don't try to delete it from the list again
> > > after the VMA has been marked as parked.
> > >
> > > Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
> >
> > what about reverting that?
>
> I didn't think of that. Why you think that might be a better approach?
well, I thought of that mainly because...
>
> Anyway, that's a 4 years old patch and a few things have changed since then,
> so simple revert won't work. Moreover, I've just checked that patch was
> supposed to fix another patch, 77853186e547 ("drm/i915: Claim vma while under
> closed_lock in i915_vma_parked()"), which in turn was supposed to fix
> aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events"), and that
> one also referenced still another, cb6c3d45f948 ("drm/i915/gem: Avoid parking
> the vma as we unbind") from December 2019, which finally wasn't a fix but an
> improvement.
... because of histories like that ^ and I was afraid of this patch here now
just put us into a different co
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> We defer actually closing, unbinding and destroying a VMA until next idle
> point, or until the object is freed in the meantime. By postponing the
> unbind, we allow for the VMA to be reopened by the client, avoiding the
> work required to rebind the VMA.
>
> It was assumed that as long as a GT is held idle, no VMA would be reopened
> while we destroy them. That assumption is no longer true in multi-GT
> configurations, where a VMA we reopen may be handled by a GT different
> from the one that we already keep active via its engine while we set up
> an execbuf request.
>
> <4> [260.290809] [ cut here ]
> <4> [260.290988] list_del corruption. prev->next should be 888118c5d990,
> but was 888118c5a510. (prev=888118c5a510)
> <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> __list_del_entry_valid_or_report+0xb7/0xe0
> ..
> <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> ...
> <4> [260.291087] Call Trace:
> <4> [260.291089]
> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [260.292301]
> ...
> <4> [260.292506] ---[ end trace ]---
> <4> [260.292782] general protection fault, probably for non-canonical address
> 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> ...
> <4> [260.428756] Call Trace:
> <4> [260.431192]
> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [639.411134]
> ...
> <4> [639.449979] ---[ end trace ]---
>
> As soon as we start unbinding and destroying a VMA, marked it as parked,
> and also keep it marked as closed for the rest of its life. When a VMA
> to be opened occurs closed, reopen it only if not yet parked.
>
> v3: Fix misplaced brackets.
> v2: Since we no longer re-init the VMA closed list link on VMA park so it
> looks like still on a list, don't try to delete it from the list again
> after the VMA has been marked as parked.
>
> Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
what about reverting that?
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: sta...@vger.kernel.org # v6.0+
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 --
> drivers/gpu/drm/i915/i915_vma.c | 32 +++
> drivers/gpu/drm/i915/i915_vma.h | 2 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 3 ++
> 4 files changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 42619fc05de48..97e014f94002e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -847,9 +847,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> if (unlikely(!lut))
> return -ENOMEM;
>
> + if (!i915_vma_open(vma)) {
> + err = -EEXIST; /* let eb_vma_lookup() retry */
> + goto err_lut_free;
> + }
> +
> i915_vma_get(vma);
> - if (!atomic_fetch_inc(>open_count))
> - i915_vma_reopen(vma);
> lut->handle = handle;
> lut->ctx = ctx;
>
> @@ -880,8 +883,9 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> return 0;
>
> err:
> - i915_vma_close(vma);
> i915_vma_put(vma);
> + i915_vma_close(vma);
> +err_lut_free:
> i915_lut_handle_free(lut);
> return err;
> }
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index d2f064d2525cc..4435c76f28c8c 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1735,14 +1735,33 @@ static void __i915_vma_remove_closed(struct i915_vma
> *vma)
> list_del_init(>closed_link);
> }
>
> -void i915_vma_reopen(struct i915_vma *vma)
> +static struct i915_vma *i915_vma_reopen(struct i915_vma *vma)
> +{
> + if (atomic_read(>flags) & I915_VMA_PARKED)
> + return NULL;
> +
>
Re: [PATCH 11/10] MAINTAINERS: update i915 and xe entries for include/drm/intel
On Thu, Apr 11, 2024 at 06:45:03PM +0300, Jani Nikula wrote: > With all the Intel specific drm files under include/drm/intel, update > the i915, xe, and the shared display entries. Do not discriminate based > on file name pattern, just add the entire directory for all three > entries. > > Cc: Joonas Lahtinen > Cc: Lucas De Marchi > Cc: Oded Gabbay > Cc: Rodrigo Vivi > Cc: Thomas Hellström > Cc: Tvrtko Ursulin > Signed-off-by: Jani Nikula > --- > MAINTAINERS | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e7a511b443af..a71254fdbf4c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10841,6 +10841,7 @@ S:Supported > F: drivers/gpu/drm/i915/display/ > F: drivers/gpu/drm/xe/display/ > F: drivers/gpu/drm/xe/compat-i915-headers > +F: include/drm/intel/ > > INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, > Moorestown and derivative) > M: Jani Nikula > @@ -10858,7 +10859,7 @@ F: > Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > F: Documentation/gpu/i915.rst > F: drivers/gpu/drm/ci/xfails/i915* > F: drivers/gpu/drm/i915/ > -F: include/drm/i915* > +F: include/drm/intel/ > F: include/uapi/drm/i915_drm.h Acked-by: Rodrigo Vivi on the whole series > > INTEL DRM XE DRIVER (Lunar Lake and newer) > @@ -10875,7 +10876,7 @@ T:git > https://gitlab.freedesktop.org/drm/xe/kernel.git > F: Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon > F: Documentation/gpu/xe/ > F: drivers/gpu/drm/xe/ > -F: include/drm/xe* > +F: include/drm/intel/ > F: include/uapi/drm/xe_drm.h > > INTEL ETHERNET DRIVERS > -- > 2.39.2 >
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes drm-intel-fixes-2024-04-10: Display fixes: - Couple CDCLK programming fixes (Ville) - HDCP related fix (Suraj) - 4 Bigjoiner related fixes (Ville) Core fix: - Fix for a circular locking around GuC on reset+wedged case (John) Thanks, Rodrigo. The following changes since commit fec50db7033ea478773b159e0e2efb135270e3b7: Linux 6.9-rc3 (2024-04-07 13:22:46 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-04-10 for you to fetch changes up to dcd8992e47f13afb5c11a61e8d9c141c35e23751: drm/i915/vrr: Disable VRR when using bigjoiner (2024-04-08 13:10:10 -0400) Display fixes: - Couple CDCLK programming fixes (Ville) - HDCP related fix (Suraj) - 4 Bigjoiner related fixes (Ville) Core fix: - Fix for a circular locking around GuC on reset+wedged case (John) John Harrison (1): drm/i915/guc: Fix the fix for reset lock confusion Suraj Kandpal (1): drm/i915/hdcp: Fix get remote hdcp capability function Ville Syrjälä (6): drm/i915/cdclk: Fix CDCLK programming order when pipes are active drm/i915/cdclk: Fix voltage_level programming edge case drm/i915/psr: Disable PSR when bigjoiner is used drm/i915: Disable port sync when bigjoiner is used drm/i915: Disable live M/N updates when using bigjoiner drm/i915/vrr: Disable VRR when using bigjoiner drivers/gpu/drm/i915/display/intel_cdclk.c| 42 +-- drivers/gpu/drm/i915/display/intel_cdclk.h| 3 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++ drivers/gpu/drm/i915/display/intel_dp.c | 6 +++- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 5 ++- drivers/gpu/drm/i915/display/intel_psr.c | 11 ++ drivers/gpu/drm/i915/display/intel_vrr.c | 7 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +++ 9 files changed, 79 insertions(+), 27 deletions(-)
Re: [PATCH] drm/dp: correct struct member name in documentation
On Fri, Apr 05, 2024 at 12:21:59PM +0530, Mitul Golani wrote:
> Correct struct member name to 'mode' instead of 'operation mode'
> in 'drm_dp_as_sdp' structure description.
>
> Fixes: 0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
Probably good to avoid this 'Fixes:' tag, and only use that
for real code bugs.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
drm-misc folks, ack to get this through drm-intel-next,
where the original patch is?
Thanks,
Rodrigo
> Cc: Mitul Golani
> Cc: Ankit Nautiyal
> Cc: Jani Nikula
> Signed-off-by: Mitul Golani
> ---
> include/drm/display/drm_dp_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index baf9949ff96f..6799f57d635c 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -112,7 +112,7 @@ struct drm_dp_vsc_sdp {
> * @target_rr: Target Refresh
> * @duration_incr_ms: Successive frame duration increase
> * @duration_decr_ms: Successive frame duration decrease
> - * @operation_mode: Adaptive Sync Operation Mode
> + * @mode: Adaptive Sync Operation Mode
> */
> struct drm_dp_as_sdp {
> unsigned char sdp_type;
> --
> 2.25.1
>
Re: [PATCH v2 0/4] drm/xe: Support PCIe FLR
On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote: > PCI subsystem provides callbacks to inform the driver about a request to > do function level reset by user, initiated by writing to sysfs entry > /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR > without the need to do unbind and rebind as the driver needs to > reinitialize the device afresh post FLR. > > v2: all the patches looks good to me here. feel free to use Reviewed-by: Rodrigo Vivi on them. but I do have some concerns (below) > 1. Directly expose the devm_drm_dev_release_action instead of introducing > a helper (Rodrigo) > 2. separate out gt idle and pci save/restore to a separate patch (Lucas) > 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini On this I also had to fight to get something working on the wedged_mode=2: lore.kernel.org/all/20240403150732.102678-4-rodrigo.v...@intel.com perhaps we can unify things here. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > > dmesg snip showing FLR recovery: things came different at my DG2 here with display working and all: root@rdvivi-desk:/sys/module/xe/drivers/pci:xe/:03:00.0# echo 1 > reset Segmentation fault and many kernel warnings WARNING: CPU: 8 PID: 2389 at drivers/gpu/drm/i915/display/intel_display_power_well.c:281 hsw_wait_for_power_well_enable+0x3e7/0x570 [xe] WARNING: CPU: 9 PID: 1700 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x41/0x60 [ 117.128330] KASAN: null-ptr-deref in range [0x04e8-0x04ef] [ 117.128332] CPU: 13 PID: 2389 Comm: bash Tainted: GW 6.9.0-rc1+ #9 [ 117.135501] ? exc_invalid_op+0x13/0x40 [ 117.143626] Hardware name: iBUYPOWER INTEL/B660 DS3H AC DDR4-Y1, BIOS F5 12/17/2021 [ 117.143627] RIP: 0010:__mutex_lock+0x124/0x14a0 [ 117.143631] Code: d0 7c 08 84 d2 0f 85 62 0f 00 00 8b 0d 85 c8 8f 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 46 0f 00 00 4d 3b 7f 68 0f 85 aa 0e 00 00 bf 01 [ 117.150630] ? asm_exc_invalid_op+0x16/0x20 [ 117.156401] RSP: 0018:c90005a37690 EFLAGS: 00010202 [ 117.156403] RAX: dc00 RBX: RCX: [ 117.163571] ? drm_buddy_fini+0x181/0x220 and more issues. so it looks like we are still missing some parts of the puzzle here... > > [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) > [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, > 0x0020 > [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x2020-202fff00] > [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: > [0x0010-20], io range: > [0x2030-203fff00] > [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, > 0x0020 > [ 590.578594] xe :4d:00.0: [drm] Available VRAM: > 0x2020, 0x001ffe00 > [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on > minor 1 > [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) > [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.957450] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.989863] xe :9a:00.0: [drm] VISIBLE VRAM: 0x20e0, > 0x0020 > [ 590.989888] xe :9a:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989893] xe :9a:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x20e0-20efff00] > [ 590.989918] xe :9a:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989921] xe :9a:00.0
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes drm-intel-fixes-2024-04-04: Display fixes: - A few DisplayPort related fixes (Imre, Arun, Ankit, Ville) - eDP PSR fixes (Jouni) Core/GT fixes: - Remove some VM space restrictions on older platforms (Andi) - Disable automatic load CCS load balancing (Andi) Thanks, Rodrigo. The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f: Linux 6.9-rc2 (2024-03-31 14:32:39 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-04-04 for you to fetch changes up to 99f855082f228cdcecd6ab768d3b8b505e0eb028: drm/i915/mst: Reject FEC+MST on ICL (2024-04-03 14:26:11 -0400) Display fixes: - A few DisplayPort related fixes (Imre, Arun, Ankit, Ville) - eDP PSR fixes (Jouni) Core/GT fixes: - Remove some VM space restrictions on older platforms (Andi) - Disable automatic load CCS load balancing (Andi) Andi Shyti (4): drm/i915/gt: Limit the reserved VM space to only the platforms that need it drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Do not generate the command streamer for all the CCS drm/i915/gt: Enable only one CCS for compute workload Ankit Nautiyal (1): drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13 Arun R Murthy (1): drm/i915/dp: Remove support for UHBR13.5 Imre Deak (1): drm/i915/dp: Fix DSC state HW readout for SST connectors Jouni Högander (3): drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage Ville Syrjälä (2): drm/i915/mst: Limit MST+DSC to TGL+ drm/i915/mst: Reject FEC+MST on ICL drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_display.c | 9 --- .../gpu/drm/i915/display/intel_display_device.h| 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 2 + drivers/gpu/drm/i915/display/intel_dp.c| 11 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 78 -- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 + drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 9 +-- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c| 39 +++ drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h| 13 drivers/gpu/drm/i915/gt/intel_gt_regs.h| 6 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 30 - 15 files changed, 185 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
Re: [PULL] drm-intel-fixes
On Fri, Mar 29, 2024 at 06:23:54AM -0400, Musial, Ewelina wrote: > Hi Rodrigo, > > When I opened dashboard early morning all results were available, so I don't > think there was any issue during night. > It could be long reporting queue - reporting through AWS takes ages but this > is not an issue with reporting, this is how AWS works. I'm sorry for the noise. It was probably just a matter of time. Everything looking good there. Thanks, Rodrigo. > > Regards, > Ewelina > > -Original Message- > From: Intel-gfx On Behalf Of > Rodrigo Vivi > Sent: Friday, March 29, 2024 2:32 AM > To: Dave Airlie ; Daniel Vetter > Cc: Jani Nikula ; Joonas Lahtinen > ; Tvrtko Ursulin ; > Vivi, Rodrigo ; Thomas Zimmermann > ; Maarten Lankhorst ; > Maxime Ripard ; Thomas Hellström > ; Oded Gabbay ; De > Marchi, Lucas ; dri-devel@lists.freedesktop.org; > intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; > dim-to...@lists.freedesktop.org > Subject: [PULL] drm-intel-fixes > > Hi Dave and Sima, > > Here goes our first PR of this round. > > Our CI is not working as I would expect: > https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html? > > Well, at least it caught some build failures on runds 832 and 833. > But after I fixed those, the 834 (with v6.9-rc1) and the 835 (with all these > patches here) didn't show up yet. So I have run manual validation on my > DG2+ADL here. > > Everything looking good here, and it is yet -rc1. I'm confident that we can > move ahead with those while we work to get CI back. > > Thanks, > Rodrigo > > drm-intel-fixes-2024-03-28: > > Core/GT Fixes: > - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) > - Update a MTL workaround (Tejas) > - Fix locking inversion in hwmon's sysfs (Janusz) > - Remove a bogus error message around PXP (Jose) > - Fix UAF on VMA (Janusz) > - Reset queue_priority_hint on parking (Chris) > > Display Fixes: > - Remove duplicated audio enable/disable on SDVO and DP (Ville) > - Disable AuxCCS for Xe driver (Juha-Pekka) > - Revert init order of MIPI DSI (Ville) > - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) > - VRR related fixes (Ville) > - Fix a JSL eDP corruption (Jonathon) > - Fix the cursor physical dma address (Ville) > - BIOS VBT related fix (Ville) > > Thanks, > Rodrigo. > > The following changes since commit 4cece764965020c22cff7665b18a012006359095: > > Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) > > are available in the Git repository at: > > https://anongit.freedesktop.org/git/drm/drm-intel > tags/drm-intel-fixes-2024-03-28 > > for you to fetch changes up to 32e39bab59934bfd3f37097d4dd85ac5eb0fd549: > > drm/i915/bios: Tolerate devdata==NULL in > intel_bios_encoder_supports_dp_dual_mode() (2024-03-28 12:16:17 -0400) > > > Core/GT Fixes: > - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) > - Update a MTL workaround (Tejas) > - Fix locking inversion in hwmon's sysfs (Janusz) > - Remove a bogus error message around PXP (Jose) > - Fix UAF on VMA (Janusz) > - Reset queue_priority_hint on parking (Chris) > > Display Fixes: > - Remove duplicated audio enable/disable on SDVO and DP (Ville) > - Disable AuxCCS for Xe driver (Juha-Pekka) > - Revert init order of MIPI DSI (Ville) > - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) > - VRR related fixes (Ville) > - Fix a JSL eDP corruption (Jonathon) > - Fix the cursor physical dma address (Ville) > - BIOS VBT related fix (Ville) > > > Bhanuprakash Modem (2): > drm/i915/drrs: Refactor CPU transcoder DRRS check > drm/i915/display/debugfs: Fix duplicate checks in i915_drrs_status > > Chris Wilson (1): > drm/i915/gt: Reset queue_priority_hint on parking > > Janusz Krzysztofik (2): > drm/i915/hwmon: Fix locking inversion in sysfs getter > drm/i915/vma: Fix UAF on destroy against retire race > > Jonathon Hall (1): > drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() > > Joonas Lahtinen (1): > drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c > > José Roberto de Souza (1): > drm/i915: Do not print 'pxp init failed with 0' when it succeed > > Juha-Pekka Heikkila (1): > drm/i915/display: Disable AuxCCS framebuffers if built for Xe > > Tejas Upadhyay (1): > drm/i915/mtl: Update workaround 14018575942 > > Ville Syrjälä (6): > drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP > drm/i915/dsi: Go
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes our first PR of this round. Our CI is not working as I would expect: https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html? Well, at least it caught some build failures on runds 832 and 833. But after I fixed those, the 834 (with v6.9-rc1) and the 835 (with all these patches here) didn't show up yet. So I have run manual validation on my DG2+ADL here. Everything looking good here, and it is yet -rc1. I'm confident that we can move ahead with those while we work to get CI back. Thanks, Rodrigo drm-intel-fixes-2024-03-28: Core/GT Fixes: - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) - Update a MTL workaround (Tejas) - Fix locking inversion in hwmon's sysfs (Janusz) - Remove a bogus error message around PXP (Jose) - Fix UAF on VMA (Janusz) - Reset queue_priority_hint on parking (Chris) Display Fixes: - Remove duplicated audio enable/disable on SDVO and DP (Ville) - Disable AuxCCS for Xe driver (Juha-Pekka) - Revert init order of MIPI DSI (Ville) - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) - VRR related fixes (Ville) - Fix a JSL eDP corruption (Jonathon) - Fix the cursor physical dma address (Ville) - BIOS VBT related fix (Ville) Thanks, Rodrigo. The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-03-28 for you to fetch changes up to 32e39bab59934bfd3f37097d4dd85ac5eb0fd549: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() (2024-03-28 12:16:17 -0400) Core/GT Fixes: - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) - Update a MTL workaround (Tejas) - Fix locking inversion in hwmon's sysfs (Janusz) - Remove a bogus error message around PXP (Jose) - Fix UAF on VMA (Janusz) - Reset queue_priority_hint on parking (Chris) Display Fixes: - Remove duplicated audio enable/disable on SDVO and DP (Ville) - Disable AuxCCS for Xe driver (Juha-Pekka) - Revert init order of MIPI DSI (Ville) - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) - VRR related fixes (Ville) - Fix a JSL eDP corruption (Jonathon) - Fix the cursor physical dma address (Ville) - BIOS VBT related fix (Ville) Bhanuprakash Modem (2): drm/i915/drrs: Refactor CPU transcoder DRRS check drm/i915/display/debugfs: Fix duplicate checks in i915_drrs_status Chris Wilson (1): drm/i915/gt: Reset queue_priority_hint on parking Janusz Krzysztofik (2): drm/i915/hwmon: Fix locking inversion in sysfs getter drm/i915/vma: Fix UAF on destroy against retire race Jonathon Hall (1): drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() Joonas Lahtinen (1): drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c José Roberto de Souza (1): drm/i915: Do not print 'pxp init failed with 0' when it succeed Juha-Pekka Heikkila (1): drm/i915/display: Disable AuxCCS framebuffers if built for Xe Tejas Upadhyay (1): drm/i915/mtl: Update workaround 14018575942 Ville Syrjälä (6): drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly drm/i915/vrr: Generate VRR "safe window" for DSB drm/i915/dsb: Fix DSB vblank waits when using VRR drm/i915: Pre-populate the cursor physical dma address drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() drivers/gpu/drm/i915/display/g4x_dp.c | 2 - drivers/gpu/drm/i915/display/icl_dsi.c | 3 +- drivers/gpu/drm/i915/display/intel_bios.c | 46 +--- drivers/gpu/drm/i915/display/intel_cursor.c| 4 +- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c| 12 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- drivers/gpu/drm/i915/display/intel_drrs.c | 14 -- drivers/gpu/drm/i915/display/intel_drrs.h | 3 ++ drivers/gpu/drm/i915/display/intel_dsb.c | 14 ++ drivers/gpu/drm/i915/display/intel_fb_pin.c| 10 + drivers/gpu/drm/i915/display/intel_sdvo.c | 4 -- drivers/gpu/drm/i915/display/intel_vrr.c | 7 +-- drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 -- .../gpu/drm/i915/gt/intel_execlists_submission.c | 3 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 1 + drivers/gpu/drm/i915/i915_driver.c | 2 +- drivers/gpu/drm/i915/i915_hwmon.c | 37 drivers/gpu/drm/i915/i915_memcpy.c | 2 + drivers/gpu/drm/i915/i915_reg.h
Re: [RFC 1/2] drm: add devm release action
On Wed, Mar 20, 2024 at 04:14:25PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> Cc: Thomas Hellstr_m
>
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..b23c5081812b 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,12 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +void __devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(__devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..a1d12cb72088 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void __devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> @@ -477,6 +479,8 @@ void *__devm_drm_dev_alloc(struct device *parent,
> #define devm_drm_dev_alloc(parent, driver, type, member) \
> ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
> offsetof(type, member)))
> +#define devm_drm_release_action(drm_dev) \
> + __devm_drm_dev_release_action(drm_dev)
why not simply renaming the original function?
>
> struct drm_device *drm_dev_alloc(const struct drm_driver *driver,
>struct device *parent);
> --
> 2.25.1
>
Re: [RFC 2/2] drm/xe/FLR: Support PCIe FLR
On Wed, Mar 20, 2024 at 04:14:26PM +0530, Aravind Iddamsetty wrote:
> PCI subsystem provides callbacks to inform the driver about a request to
> do function level reset by user, initiated by writing to sysfs entry
> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
> without the need to do unbind and rebind as the driver needs to
> reinitialize the device afresh post FLR.
>
> Cc: Rodrigo Vivi
> Cc: Lucas De Marchi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_device_types.h | 3 +
> drivers/gpu/drm/xe/xe_gt.c | 31 ++---
> drivers/gpu/drm/xe/xe_gt.h | 1 +
> drivers/gpu/drm/xe/xe_pci.c | 53 ++--
> drivers/gpu/drm/xe/xe_pci.h | 6 +-
> drivers/gpu/drm/xe/xe_pci_err.c | 94
> 7 files changed, 174 insertions(+), 15 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/xe_pci_err.c
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 3c3e67885559..1447712fec65 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
> xe_module.o \
> xe_pat.o \
> xe_pci.o \
> + xe_pci_err.o \
> xe_pcode.o \
> xe_pm.o \
> xe_preempt_fence.o \
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h
> b/drivers/gpu/drm/xe/xe_device_types.h
> index 9785eef2e5a4..e9b8c7cbb428 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -455,6 +455,9 @@ struct xe_device {
> /** @needs_flr_on_fini: requests function-reset on fini */
> bool needs_flr_on_fini;
>
> + /** @pci_state: PCI state of device */
> + struct pci_saved_state *pci_state;
> +
> /* private: */
>
> #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 85408e7a932b..437874a9a5a0 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -629,6 +629,26 @@ static int do_gt_restart(struct xe_gt *gt)
> return 0;
> }
>
> +/* Idle the GT */
> +int xe_idle_gt(struct xe_gt *gt)
> +{
> + int err;
> +
> + xe_gt_sanitize(gt);
> +
> + xe_uc_gucrc_disable(>uc);
> + xe_uc_stop_prepare(>uc);
> + xe_gt_pagefault_reset(gt);
> +
> + err = xe_uc_stop(>uc);
> + if (err)
> + return err;
> +
> + xe_gt_tlb_invalidation_reset(gt);
> +
> + return err;
> +}
> +
> static int gt_reset(struct xe_gt *gt)
> {
> int err;
> @@ -645,21 +665,12 @@ static int gt_reset(struct xe_gt *gt)
> }
>
> xe_pm_runtime_get(gt_to_xe(gt));
> - xe_gt_sanitize(gt);
>
> err = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
> if (err)
> goto err_msg;
>
> - xe_uc_gucrc_disable(>uc);
> - xe_uc_stop_prepare(>uc);
> - xe_gt_pagefault_reset(gt);
> -
> - err = xe_uc_stop(>uc);
> - if (err)
> - goto err_out;
> -
> - xe_gt_tlb_invalidation_reset(gt);
> + xe_idle_gt(gt);
>
> err = do_gt_reset(gt);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
> index ed6ea8057e35..77df919199cc 100644
> --- a/drivers/gpu/drm/xe/xe_gt.h
> +++ b/drivers/gpu/drm/xe/xe_gt.h
> @@ -43,6 +43,7 @@ int xe_gt_resume(struct xe_gt *gt);
> void xe_gt_reset_async(struct xe_gt *gt);
> void xe_gt_sanitize(struct xe_gt *gt);
> void xe_gt_remove(struct xe_gt *gt);
> +int xe_idle_gt(struct xe_gt *gt);
>
> /**
> * xe_gt_any_hw_engine_by_reset_domain - scan the list of engines and return
> the
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index c401d4890386..fcd2a7f66f7b 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -383,6 +383,41 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
>
> #undef INTEL_VGA_DEVICE
>
> +static bool xe_save_pci_state(struct pci_dev *pdev)
> +{
> + struct xe_device *xe = pci_get_drvdata(pdev);
> +
> + if (pci_save_state(pdev))
> + return false;
> +
> + kfree(xe->pci_state);
> +
> + xe->pci_state = pci_store_saved_state(pdev);
> +
> + if (!xe->pci_state) {
> + drm_err(>drm, "Failed to store PCI saved state\n");
> + return false;
> + }
> +
> + return true;
> +}
> +
> +void xe_load_pci_state(struct pci_dev *pdev)
> +{
> + struct xe_device *xe = pci_get_drvdata(pdev);
> +
Re: [PATCH] drm/i915/gt: Reset queue_priority_hint on parking
f 48
> <4>[ 167.304940] RSP: 0018:c959fce0 EFLAGS: 00010246
> <4>[ 167.304942] RAX: 0200 RBX: RCX:
> 0006
> <4>[ 167.304944] RDX: RSI: RDI:
> 0009
> <4>[ 167.304946] RBP: 8881330ca1b0 R08: 0001 R09:
> 0001
> <4>[ 167.304947] R10: 0001 R11: 0001 R12:
> 8881330ca000
> <4>[ 167.304948] R13: 888110f02aa0 R14: 88812d1d0205 R15:
> 88811277d4f0
> <4>[ 167.304950] FS: () GS:88844f78()
> knlGS:
> <4>[ 167.304952] CS: 0010 DS: ES: CR0: 80050033
> <4>[ 167.304953] CR2: 7fc362200c40 CR3: 00013306e003 CR4:
> 00770ef0
> <4>[ 167.304955] PKRU: 5554
> <4>[ 167.304957] Call Trace:
> <4>[ 167.304958]
> <4>[ 167.305573] intel_wakeref_put_last+0x1d/0x80 [i915]
> <4>[ 167.305685] i915_request_retire.part.0+0x34f/0x600 [i915]
> <4>[ 167.305800] retire_requests+0x51/0x80 [i915]
> <4>[ 167.305892] intel_gt_retire_requests_timeout+0x27f/0x700 [i915]
> <4>[ 167.305985] process_scheduled_works+0x2db/0x530
> <4>[ 167.305990] worker_thread+0x18c/0x350
> <4>[ 167.305993] kthread+0xfe/0x130
> <4>[ 167.305997] ret_from_fork+0x2c/0x50
> <4>[ 167.306001] ret_from_fork_asm+0x1b/0x30
> <4>[ 167.306004]
>
> It is necessary for the queue_priority_hint to be lower than the next
> request submission upon waking up, as we rely on the hint to decide when
> to kick the tasklet to submit that first request.
>
> Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/10154
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: # v5.4+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c| 3 ---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 96bdb93a948d1..fb7bff27b45a3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -279,9 +279,6 @@ static int __engine_park(struct intel_wakeref *wf)
> intel_engine_park_heartbeat(engine);
> intel_breadcrumbs_park(engine->breadcrumbs);
>
> - /* Must be reset upon idling, or we may miss the busy wakeup. */
> - GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> -
> if (engine->park)
> engine->park(engine);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 42aade0faf2d1..b061a0a0d6b08 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3272,6 +3272,9 @@ static void execlists_park(struct intel_engine_cs
> *engine)
> {
> cancel_timer(>execlists.timer);
> cancel_timer(>execlists.preempt);
> +
> + /* Reset upon idling, or we may delay the busy wakeup. */
> + WRITE_ONCE(engine->sched_engine->queue_priority_hint, INT_MIN);
maybe better to leave only the scheduler code touching their variables.
but no big blocker and this code seems safe and the mentioned bug,
so,
Reviewed-by: Rodrigo Vivi
> }
>
> static void add_to_engine(struct i915_request *rq)
> --
> 2.43.0
>
Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter
On Mon, Mar 11, 2024 at 07:14:09PM +0100, Janusz Krzysztofik wrote:
> On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> > On 3/11/24 09:58, Rodrigo Vivi wrote:
> > > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> > >> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> > >> rpm wakeref. That results in lock inversion:
> > >>
> > >> <4> [197.079335] ==
> > >> <4> [197.085473] WARNING: possible circular locking dependency detected
> > >> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not
> > >> tainted
> > >> <4> [197.098096] --
> > >> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> > >> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at:
> > >> __kmalloc+0x9a/0x350
> > >> <4> [197.116939]
> > >> but task is already holding lock:
> > >> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at:
> > >> hwm_energy+0x4b/0x100 [i915]
> > >> <4> [197.131543]
> > >> which lock already depends on the new lock.
> > >> ...
> > >> <4> [197.507922] Chain exists of:
> > >>fs_reclaim --> >reset.mutex --> >hwmon_lock
> > >> <4> [197.518528] Possible unsafe locking scenario:
> > >> <4> [197.524411]CPU0CPU1
> > >> <4> [197.528916]
> > >> <4> [197.533418] lock(>hwmon_lock);
> > >> <4> [197.537237]lock(>reset.mutex);
> > >> <4> [197.543376]lock(>hwmon_lock);
> > >> <4> [197.549682] lock(fs_reclaim);
> > >> ...
> > >> <4> [197.632548] Call Trace:
> > >> <4> [197.634990]
> > >> <4> [197.637088] dump_stack_lvl+0x64/0xb0
> > >> <4> [197.640738] check_noncircular+0x15e/0x180
> > >> <4> [197.652968] check_prev_add+0xe9/0xce0
> > >> <4> [197.656705] __lock_acquire+0x179f/0x2300
> > >> <4> [197.660694] lock_acquire+0xd8/0x2d0
> > >> <4> [197.673009] fs_reclaim_acquire+0xa1/0xd0
> > >> <4> [197.680478] __kmalloc+0x9a/0x350
> > >> <4> [197.689063] acpi_ns_internalize_name.part.0+0x4a/0xb0
> > >> <4> [197.694170] acpi_ns_get_node_unlocked+0x60/0xf0
> > >> <4> [197.720608] acpi_ns_get_node+0x3b/0x60
> > >> <4> [197.724428] acpi_get_handle+0x57/0xb0
> > >> <4> [197.728164] acpi_has_method+0x20/0x50
> > >> <4> [197.731896] acpi_pci_set_power_state+0x43/0x120
> > >> <4> [197.736485] pci_power_up+0x24/0x1c0
> > >> <4> [197.740047] pci_pm_default_resume_early+0x9/0x30
> > >> <4> [197.744725] pci_pm_runtime_resume+0x2d/0x90
> > >> <4> [197.753911] __rpm_callback+0x3c/0x110
> > >> <4> [197.762586] rpm_callback+0x58/0x70
> > >> <4> [197.766064] rpm_resume+0x51e/0x730
> > >> <4> [197.769542] rpm_resume+0x267/0x730
> > >> <4> [197.773020] rpm_resume+0x267/0x730
> > >> <4> [197.776498] rpm_resume+0x267/0x730
> > >> <4> [197.779974] __pm_runtime_resume+0x49/0x90
> > >> <4> [197.784055] __intel_runtime_pm_get+0x19/0xa0 [i915]
> > >> <4> [197.789070] hwm_energy+0x55/0x100 [i915]
> > >> <4> [197.793183] hwm_read+0x9a/0x310 [i915]
> > >> <4> [197.797124] hwmon_attr_show+0x36/0x120
> > >> <4> [197.800946] dev_attr_show+0x15/0x60
> > >> <4> [197.804509] sysfs_kf_seq_show+0xb5/0x100
> > >>
> > >> However, the lock is only intended to protect either a hwmon overflow
> > >> counter or rmw hardware operations. There is no need to hold the lock,
> > >> only the wakeref, while reading from hardware.
> > >>
> > >> Acquire the lock after hardware read under rpm wakeref.
> > >>
> > >> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> > >> Signed-off-by: Janusz Krzysztofik
> > >> Cc: # v6.2+
> > >> ---
> > >> drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> > >> 1 file changed,
Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter
On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> rpm wakeref. That results in lock inversion:
>
> <4> [197.079335] ==
> <4> [197.085473] WARNING: possible circular locking dependency detected
> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
> <4> [197.098096] --
> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at:
> __kmalloc+0x9a/0x350
> <4> [197.116939]
> but task is already holding lock:
> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at:
> hwm_energy+0x4b/0x100 [i915]
> <4> [197.131543]
> which lock already depends on the new lock.
> ...
> <4> [197.507922] Chain exists of:
> fs_reclaim --> >reset.mutex --> >hwmon_lock
> <4> [197.518528] Possible unsafe locking scenario:
> <4> [197.524411]CPU0CPU1
> <4> [197.528916]
> <4> [197.533418] lock(>hwmon_lock);
> <4> [197.537237]lock(>reset.mutex);
> <4> [197.543376]lock(>hwmon_lock);
> <4> [197.549682] lock(fs_reclaim);
> ...
> <4> [197.632548] Call Trace:
> <4> [197.634990]
> <4> [197.637088] dump_stack_lvl+0x64/0xb0
> <4> [197.640738] check_noncircular+0x15e/0x180
> <4> [197.652968] check_prev_add+0xe9/0xce0
> <4> [197.656705] __lock_acquire+0x179f/0x2300
> <4> [197.660694] lock_acquire+0xd8/0x2d0
> <4> [197.673009] fs_reclaim_acquire+0xa1/0xd0
> <4> [197.680478] __kmalloc+0x9a/0x350
> <4> [197.689063] acpi_ns_internalize_name.part.0+0x4a/0xb0
> <4> [197.694170] acpi_ns_get_node_unlocked+0x60/0xf0
> <4> [197.720608] acpi_ns_get_node+0x3b/0x60
> <4> [197.724428] acpi_get_handle+0x57/0xb0
> <4> [197.728164] acpi_has_method+0x20/0x50
> <4> [197.731896] acpi_pci_set_power_state+0x43/0x120
> <4> [197.736485] pci_power_up+0x24/0x1c0
> <4> [197.740047] pci_pm_default_resume_early+0x9/0x30
> <4> [197.744725] pci_pm_runtime_resume+0x2d/0x90
> <4> [197.753911] __rpm_callback+0x3c/0x110
> <4> [197.762586] rpm_callback+0x58/0x70
> <4> [197.766064] rpm_resume+0x51e/0x730
> <4> [197.769542] rpm_resume+0x267/0x730
> <4> [197.773020] rpm_resume+0x267/0x730
> <4> [197.776498] rpm_resume+0x267/0x730
> <4> [197.779974] __pm_runtime_resume+0x49/0x90
> <4> [197.784055] __intel_runtime_pm_get+0x19/0xa0 [i915]
> <4> [197.789070] hwm_energy+0x55/0x100 [i915]
> <4> [197.793183] hwm_read+0x9a/0x310 [i915]
> <4> [197.797124] hwmon_attr_show+0x36/0x120
> <4> [197.800946] dev_attr_show+0x15/0x60
> <4> [197.804509] sysfs_kf_seq_show+0xb5/0x100
>
> However, the lock is only intended to protect either a hwmon overflow
> counter or rmw hardware operations. There is no need to hold the lock,
> only the wakeref, while reading from hardware.
>
> Acquire the lock after hardware read under rpm wakeref.
>
> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> Signed-off-by: Janusz Krzysztofik
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347e..faf7670de6e06 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
> else
> rgaddr = hwmon->rg.energy_status_all;
>
> - mutex_lock(>hwmon_lock);
> -
> with_intel_runtime_pm(uncore->rpm, wakeref)
> reg_val = intel_uncore_read(uncore, rgaddr);
>
> + mutex_lock(>hwmon_lock);
> +
This is not enough.
check hwm_locked_with_pm_intel_uncore_rmw()
It looks like we need to rethink this lock entirely here.
struct mutex hwmon_lock;/* counter overflow \
logic and rmw */
do we really need to protect the rmw?
This also shows me that we have other places with intel_uncore_rmw
without the with runtime_pm.
perhaps we need to stop using the with_rpm macro and use explicit
rpm calls before the hwmon_locks before the rmw?
perhaps we need a more granular lock?
notice that I'm just brainstorming/thinking out loud... someone need
to go there an run an deeper analisys on this lock and rpm calls
on hwmon.
> if (reg_val >= ei->reg_val_prev)
> ei->accum_energy += reg_val - ei->reg_val_prev;
> else
> --
> 2.43.0
>
Re: [PATCH 4/5] drm/i915: Drop dead code for pvc
On Mon, Mar 11, 2024 at 10:35:20AM -0500, Lucas De Marchi wrote: > On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote: > > > @@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs > > > *engine, struct i915_wa_list *wal > > > if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE) > > > general_render_compute_wa_init(engine, wal); > > > > > > - if (engine->class == COMPUTE_CLASS) > > > - ccs_engine_wa_init(engine, wal); > > > - else if (engine->class == RENDER_CLASS) > > > > I don't believe we need to remove this chunk since we are not deleting the > > ccs_engine_wa_init. > > If we want to keep that as a placeholder we should also keep the caller as > > well. > > right... I had removed it but brought it back since I noticed the > kernel-doc mentions and forgot to bring back the caller too. I will fix > this in next rev. thanks! with that: Reviewed-by: Rodrigo Vivi > > > thanks > Lucas De Marchi
Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)
On Mon, Mar 11, 2024 at 10:29:45AM -0500, Lucas De Marchi wrote: > On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote: > > On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote: > > > With no platform declaring graphics/media IP_VER(12, 50), > > > > this is not true. > > We still have > > > > #define XE_HPM_FEATURES \ > > .__runtime.media.ip.ver = 12, \ > >.__runtime.media.ip.rel = 50 > > > > > > -#define XE_HPM_FEATURES \ > > > - .__runtime.media.ip.ver = 12, \ > > > - .__runtime.media.ip.rel = 50 > > > - > > ^ being removed here since all the users, like below, are overriding it. > > > > #define DG2_FEATURES \ > > > XE_HP_FEATURES, \ > > > - XE_HPM_FEATURES, \ > > > DGFX_FEATURES, \ > > > + .__runtime.graphics.ip.ver = 12, \ > > > .__runtime.graphics.ip.rel = 55, \ > > > + .__runtime.media.ip.ver = 12, \ > > > .__runtime.media.ip.rel = 55, \ > > ^^ > > After applying until this patch: > > $ git grep -e "rel[[:space:]]*=" -- drivers/gpu/drm/i915/i915_pci.c > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 10, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 55, \ > drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 55, \ > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 60, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 60, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 70, > > should I reword anything in the commit message to make my intent > clearer? doh! sorry.. I read the first line of the commit message and stopped. perhaps we could do that HPM removal in a separate patch before this one? Reviewed-by: Rodrigo Vivi on the final result, whatever you decide to split or to rephrase the msg. > > thanks > Lucas De Marchi
Re: [PATCH 4/5] drm/i915: Drop dead code for pvc
On Wed, Mar 06, 2024 at 11:36:42AM -0800, Lucas De Marchi wrote:
> PCI IDs for PVC were never added and platform always marked with
> force_probe. Drop what's not used and rename some places as needed.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 3 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 33
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 30 +---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 --
> drivers/gpu/drm/i915/gt/intel_mocs.c | 19 ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 9 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 90 +--
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 -
> drivers/gpu/drm/i915/i915_debugfs.c | 12 --
> drivers/gpu/drm/i915/i915_drv.h | 9 --
> drivers/gpu/drm/i915/i915_pci.c | 36 -
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_clock_gating.c | 16 +-
> drivers/gpu/drm/i915/intel_device_info.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> drivers/gpu/drm/i915/intel_step.c | 70 +
> drivers/gpu/drm/i915/intel_uncore.c | 142 --
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 -
> .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 4 -
> 21 files changed, 12 insertions(+), 485 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 0c5cdab278b6..d3300ae3053f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -386,7 +386,7 @@ struct drm_i915_gem_object {
>* and kernel mode driver for caching policy control after GEN12.
>* In the meantime platform specific tables are created to translate
>* i915_cache_level into pat index, for more details check the macros
> - * defined i915/i915_pci.c, e.g. PVC_CACHELEVEL.
> + * defined i915/i915_pci.c, e.g. MTL_CACHELEVEL.
>* For backward compatibility, this field contains values exactly match
>* the entries of enum i915_cache_level for pre-GEN12 platforms (See
>* LEGACY_CACHELEVEL), so that the PTE encode functions for these
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 24d1c28201fa..2e27bcb52e0d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -189,9 +189,6 @@ static bool gen12_needs_ccs_aux_inv(struct
> intel_engine_cs *engine)
> {
> i915_reg_t reg = gen12_get_aux_inv_reg(engine);
>
> - if (IS_PONTEVECCHIO(engine->i915))
> - return false;
> -
> /*
>* So far platforms supported by i915 having flat ccs do not require
>* AUX invalidation. Check also whether the engine requires it.
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 75bde8c1aa5d..396f5fe993c3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -839,38 +839,6 @@ static void engine_mask_apply_compute_fuses(struct
> intel_gt *gt)
> }
> }
>
> -static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
> -{
> - struct drm_i915_private *i915 = gt->i915;
> - struct intel_gt_info *info = >info;
> - unsigned long meml3_mask;
> - unsigned long quad;
> -
> - if (!(GRAPHICS_VER_FULL(i915) >= IP_VER(12, 60) &&
> - GRAPHICS_VER_FULL(i915) < IP_VER(12, 70)))
> - return;
> -
> - meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> - meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
> -
> - /*
> - * Link Copy engines may be fused off according to meml3_mask. Each
> - * bit is a quad that houses 2 Link Copy and two Sub Copy engines.
> - */
> - for_each_clear_bit(quad, _mask, GEN12_MAX_MSLICES) {
> - unsigned int instance = quad * 2 + 1;
> - intel_engine_mask_t mask = GENMASK(_BCS(instance + 1),
> -_BCS(instance));
> -
> - if (mask & info->engine_mask) {
> - gt_dbg(gt, "bcs%u fused off\n", instance);
> - gt_dbg(gt, "bcs%u fused off\n", instance + 1);
> -
> - info->engine_mask &= ~mask;
> - }
> - }
> -}
> -
> /*
> * Determine which engines are fused off in our particular hardware.
> * Note that we have a catch-22 situation where we need to be able to access
> @@ -889,7 +857,6 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
>
>
Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)
On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> With no platform declaring graphics/media IP_VER(12, 50),
this is not true.
We still have
#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
.__runtime.media.ip.rel = 50
replace the
> checks throughout the code with IP_VER(12, 55) so the code makes sense
> by itself with no additional explanation of previous baggage.
>
> The info override for the various _info is then changed so the version
> definition is clearer without pointless overrides.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 4 ++--
> .../gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 8
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 5 ++---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 10 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8
> drivers/gpu/drm/i915/gt/intel_migrate.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_getparam.c | 4 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c| 5 ++---
> drivers/gpu/drm/i915/i915_pci.c | 12
> drivers/gpu/drm/i915/i915_perf.c | 8
> drivers/gpu/drm/i915/i915_query.c| 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 24 files changed, 50 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index 3ff3d8889c6c..edb54903be0a 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -713,7 +713,7 @@ static int igt_ppgtt_huge_fill(void *arg)
> {
> struct drm_i915_private *i915 = arg;
> unsigned int supported = RUNTIME_INFO(i915)->page_sizes;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
> struct i915_address_space *vm;
> struct i915_gem_context *ctx;
> unsigned long max_pages;
> @@ -857,7 +857,7 @@ static int igt_ppgtt_huge_fill(void *arg)
> static int igt_ppgtt_64K(void *arg)
> {
> struct drm_i915_private *i915 = arg;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
> struct drm_i915_gem_object *obj;
> struct i915_address_space *vm;
> struct i915_gem_context *ctx;
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index 10a7847f1b04..bac15196b4d2 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -117,7 +117,7 @@ static bool fastblit_supports_x_tiling(const struct
> drm_i915_private *i915)
> if (gen < 12)
> return true;
>
> - if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
> return false;
>
> return HAS_DISPLAY(i915);
> @@ -166,7 +166,7 @@ static int prepare_blit(const struct tiled_blits *t,
> src_pitch = t->width; /* in dwords */
> if (src->tiling == CLIENT_TILING_Y) {
> src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 55))
> src_4t = XY_FAST_COPY_BLT_D1_SRC_TILE4;
> } else if (src->tiling == CLIENT_TILING_X) {
> src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(TILE_X);
> @@ -177,7 +177,7 @@ static int prepare_blit(const struct tiled_blits *t,
> dst_pitch = t->width; /* in dwords */
> if (dst->tiling == CLIENT_TILING_Y) {
> dst_tiles = XY_FAST_COPY_BLT_D0_DST_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 50))
> +
Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv
On Wed, Mar 06, 2024 at 11:36:40AM -0800, Lucas De Marchi wrote:
> PCI IDs for XEHPSDV were never added and platform always marked with
> force_probe. Drop what's not used and rename some places to either be
> xehp or dg2, depending on the platform/IP checks.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
>
> Potential problem here that needs a deeper look, the changes in
> __gen12_fw_ranges. Some ranges had comments saying they were XEHPSDV so
> I removed them, but it needs to be double checked with spec and CI
> results.
I have checked the specs and your patch looks right because those
bits should be reserved for DG2.
But the main issue I see is that we were using that (wrongly?) for
DG2 so far. So it probably deserves a separate patch anyway.
With this patch only removing the comments and a separate patch
to remove that for DG2 (and standalone CI run on that patch by itself):
Reviewed-by: Rodrigo Vivi
>
> Documentation/gpu/rfc/i915_vm_bind.h | 11 +--
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40
> drivers/gpu/drm/i915/gt/intel_gsc.c | 15 ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 20 +---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 50 --
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 21 ++--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 43 -
> drivers/gpu/drm/i915/gt/intel_migrate.c | 18 ++--
> drivers/gpu/drm/i915/gt/intel_mocs.c | 31 --
> drivers/gpu/drm/i915/gt/intel_rps.c | 2 -
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 95 ---
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
> drivers/gpu/drm/i915/i915_drv.h | 4 -
> drivers/gpu/drm/i915/i915_hwmon.c | 6 --
> drivers/gpu/drm/i915/i915_pci.c | 17
> drivers/gpu/drm/i915/i915_perf.c | 11 +--
> drivers/gpu/drm/i915/i915_reg.h | 3 +-
> drivers/gpu/drm/i915/intel_clock_gating.c | 10 --
> drivers/gpu/drm/i915/intel_device_info.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> drivers/gpu/drm/i915/intel_step.c | 10 --
> drivers/gpu/drm/i915/intel_uncore.c | 15 +--
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 -
> .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 2 -
> 24 files changed, 51 insertions(+), 380 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> b/Documentation/gpu/rfc/i915_vm_bind.h
> index 8a8fcd4fceac..bc26dc126104 100644
> --- a/Documentation/gpu/rfc/i915_vm_bind.h
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence {
> * Multiple VA mappings can be created to the same section of the object
> * (aliasing).
> *
> - * The @start, @offset and @length must be 4K page aligned. However the DG2
> - * and XEHPSDV has 64K page size for device local memory and has compact page
> - * table. On those platforms, for binding device local-memory objects, the
> - * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix
> - * the local memory 64K page and the system memory 4K page bindings in the
> same
> - * 2M range.
> + * The @start, @offset and @length must be 4K page aligned. However the DG2
> has
> + * 64K page size for device local memory and has compact page table. On that
> + * platform, for binding device local-memory objects, the @start, @offset and
> + * @length must be 64K aligned. Also, UMDs should not mix the local memory
> 64K
> + * page and the system memory 4K page bindings in the same 2M range.
> *
> * Error code -EINVAL will be returned if @start, @offset and @length are not
> * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error
> code
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index fa46d2308b0e..1bd0e041e15c 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -500,11 +500,11 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> }
>
> static void
> -xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
> - struct i915_vma_resource *vma_res,
> - struct sgt_dma *iter,
> - unsigned int pat_index,
> - u32 flags)
> +xehp_ppgtt_insert_huge(struct i915_address_space *vm,
> +struct i915_vma_resource *vma_res,
> +struct sgt_dma *iter,
> +unsigned int pat_index,
> +u32 flags)
> {
> const gen8_pte_t pte_encode = vm->pte_encode(
Re: [PATCH v7 1/6] drm/client: Export drm_client_dev_unregister()
On Fri, Mar 01, 2024 at 02:42:54PM +0100, Thomas Zimmermann wrote:
> Export drm_client_dev_unregister() for use by the i915 driver. The
> driver does not use drm_dev_unregister(),
Perhaps we should make i915 to call for the drm_dev_unregister since it calls
for drm_dev_register?
> so it has to clean up the
> in-kernel DRM clients by itself.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_client.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 9403b3f576f7b..3d4f8b77d0789 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -172,6 +172,18 @@ void drm_client_release(struct drm_client_dev *client)
> }
> EXPORT_SYMBOL(drm_client_release);
>
> +/**
> + * drm_client_dev_unregister - Unregister clients
> + * @dev: DRM device
> + *
> + * This function releases all clients by calling each client's
> + * _client_funcs.unregister callback. The callback function
> + * is responsibe for releaseing all resources including the client
> + * itself.
> + *
> + * The helper drm_dev_unregister() calls this function. Drivers
> + * that use it don't need to call this function themselves.
> + */
> void drm_client_dev_unregister(struct drm_device *dev)
> {
> struct drm_client_dev *client, *tmp;
> @@ -191,6 +203,7 @@ void drm_client_dev_unregister(struct drm_device *dev)
> }
> mutex_unlock(>clientlist_mutex);
> }
> +EXPORT_SYMBOL(drm_client_dev_unregister);
>
> /**
> * drm_client_dev_hotplug - Send hotplug event to clients
> --
> 2.43.2
>
Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients
On Wed, Mar 06, 2024 at 04:11:54PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.03.24 um 17:25 schrieb Jani Nikula:
> > On Tue, 05 Mar 2024, Rodrigo Vivi wrote:
> > > On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> > > > Unregister all in-kernel clients before unloading the i915 driver. For
> > > > other drivers, drm_dev_unregister() does this automatically. As i915
> > > > does not use this helper, it has to perform the call by itself. For xe,
> > > > do the same in xe_device_remove()
> > > >
> > > > Note that there are currently no in-kernel clients in i915 or xe. The
> > > > patch prepares the drivers for a related update of their fbdev support.
> > > >
> > > > v7:
> > > > * update xe driver
> > > >
> > > > Signed-off-by: Thomas Zimmermann
> > > > ---
> > > > drivers/gpu/drm/i915/i915_driver.c | 3 +++
> > > > drivers/gpu/drm/xe/xe_device.c | 3 +++
> > > > 2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index 9ee902d5b72c4..97910a85e3917 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -41,6 +41,7 @@
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -852,6 +853,8 @@ void i915_driver_remove(struct drm_i915_private
> > > > *i915)
> > > > {
> > > > intel_wakeref_t wakeref;
> > > > + drm_client_dev_unregister(>drm);
> > > > +
> > > > wakeref = intel_runtime_pm_get(>runtime_pm);
> > > > i915_driver_unregister(i915);
> > > > diff --git a/drivers/gpu/drm/xe/xe_device.c
> > > > b/drivers/gpu/drm/xe/xe_device.c
> > > > index 919ad88f0495a..7f41f0ec819f0 100644
> > > > --- a/drivers/gpu/drm/xe/xe_device.c
> > > > +++ b/drivers/gpu/drm/xe/xe_device.c
> > > probably deserves a separate patch since this is one here is named
> > > 'drm/i915:'
> > Or do this for both in intel_display_driver_unregister()?
>
> Ok, sure. I'll update this. I also have to update i915 and xe in patches 5
> and 6. I don't see how I can change them individually. How would I best log
> against both of them? drm/{i915,xe}? or drm/intel?
hmmm... though one...
drm-intel is the name of the i915 repository
well, perhaps drm/{i915,xe} works
or maybe just drm/i915/display: because since display is shared, that
kind of "tag" would be an indication that xe needs it as well anyway.
>
> Best regards
> Thomas
>
> >
> > BR,
> > Jani.
> >
> >
> > > > @@ -9,6 +9,7 @@
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -614,6 +615,8 @@ void xe_device_remove(struct xe_device *xe)
> > > > struct xe_gt *gt;
> > > > u8 id;
> > > > + drm_client_dev_unregister(>drm);
> > > > +
> > > > xe_device_remove_display(xe);
> > > > xe_display_fini(xe);
> > > > --
> > > > 2.43.2
> > > >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
Re: [PATCH v3] drm/i915/guc: Use context hints for GT frequency
On Mon, Mar 04, 2024 at 03:34:50PM -0800, Vinay Belgaumkar wrote:
> Allow user to provide a low latency context hint. When set, KMD
> sends a hint to GuC which results in special handling for this
> context. SLPC will ramp the GT frequency aggressively every time
> it switches to this context. The down freq threshold will also be
> lower so GuC will ramp down the GT freq for this context more slowly.
> We also disable waitboost for this context as that will interfere with
> the strategy.
>
> We need to enable the use of SLPC Compute strategy during init, but
> it will apply only to contexts that set this bit during context
> creation.
>
> Userland can check whether this feature is supported using a new param-
> I915_PARAM_HAS_CONTEXT_FREQ_HINTS. This flag is true for all guc submission
> enabled platforms as they use SLPC for frequency management.
>
> The Mesa usage model for this flag is here -
> https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
>
> v2: Rename flags as per review suggestions (Rodrigo, Tvrtko).
> Also, use flag bits in intel_context as it allows finer control for
> toggling per engine if needed (Tvrtko).
>
> v3: Minor review comments (Tvrtko)
>
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Sushma Venkatesh Reddy
> Acked-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 --
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_rps.c | 4
> .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++
> drivers/gpu/drm/i915/i915_getparam.c | 6 ++
> include/uapi/drm/i915_drm.h | 15 +
> 10 files changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..81f65cab1330 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> struct i915_gem_proto_context *pc,
> struct drm_i915_gem_context_param *args)
> {
> + struct drm_i915_private *i915 = fpriv->i915;
> int ret = 0;
>
> switch (args->param) {
> @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> break;
>
> + case I915_CONTEXT_PARAM_LOW_LATENCY:
> + if (intel_uc_uses_guc_submission(_gt(i915)->uc))
> + pc->user_flags |= BIT(UCONTEXT_LOW_LATENCY);
> + else
> + ret = -EINVAL;
> + break;
> +
> case I915_CONTEXT_PARAM_RECOVERABLE:
> if (args->size)
> ret = -EINVAL;
> @@ -992,6 +1000,9 @@ static int intel_context_set_gem(struct intel_context
> *ce,
> if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
> ret = intel_context_reconfigure_sseu(ce, sseu);
>
> + if (test_bit(UCONTEXT_LOW_LATENCY, >user_flags))
> + __set_bit(CONTEXT_LOW_LATENCY, >flags);
> +
> return ret;
> }
>
> @@ -1630,6 +1641,9 @@ i915_gem_create_context(struct drm_i915_private *i915,
> if (vm)
> ctx->vm = vm;
>
> + /* Assign early so intel_context_set_gem can access these flags */
> + ctx->user_flags = pc->user_flags;
> +
> mutex_init(>engines_mutex);
> if (pc->num_user_engines >= 0) {
> i915_gem_context_set_user_engines(ctx);
> @@ -1652,8 +1666,6 @@ i915_gem_create_context(struct drm_i915_private *i915,
>* is no remap info, it will be a NOP. */
> ctx->remap_slice = ALL_L3_SLICES(i915);
>
> - ctx->user_flags = pc->user_flags;
> -
> for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
> ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 03bc7f9d191b..b6d97da63d1f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/d
Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients
On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver. For
> other drivers, drm_dev_unregister() does this automatically. As i915
> does not use this helper, it has to perform the call by itself. For xe,
> do the same in xe_device_remove()
>
> Note that there are currently no in-kernel clients in i915 or xe. The
> patch prepares the drivers for a related update of their fbdev support.
>
> v7:
> * update xe driver
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/i915_driver.c | 3 +++
> drivers/gpu/drm/xe/xe_device.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 9ee902d5b72c4..97910a85e3917 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -41,6 +41,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -852,6 +853,8 @@ void i915_driver_remove(struct drm_i915_private *i915)
> {
> intel_wakeref_t wakeref;
>
> + drm_client_dev_unregister(>drm);
> +
> wakeref = intel_runtime_pm_get(>runtime_pm);
>
> i915_driver_unregister(i915);
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 919ad88f0495a..7f41f0ec819f0 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
probably deserves a separate patch since this is one here is named 'drm/i915:'
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -614,6 +615,8 @@ void xe_device_remove(struct xe_device *xe)
> struct xe_gt *gt;
> u8 id;
>
> + drm_client_dev_unregister(>drm);
> +
> xe_device_remove_display(xe);
>
> xe_display_fini(xe);
> --
> 2.43.2
>
Re: [PATCH v2] drm/i915/guc: Use context hints for GT freq
On Wed, Feb 28, 2024 at 11:58:06AM -0800, Belgaumkar, Vinay wrote:
>
> On 2/28/2024 4:54 AM, Tvrtko Ursulin wrote:
> >
> > On 27/02/2024 23:51, Vinay Belgaumkar wrote:
> > > Allow user to provide a low latency context hint. When set, KMD
> > > sends a hint to GuC which results in special handling for this
> > > context. SLPC will ramp the GT frequency aggressively every time
> > > it switches to this context. The down freq threshold will also be
> > > lower so GuC will ramp down the GT freq for this context more slowly.
> > > We also disable waitboost for this context as that will interfere with
> > > the strategy.
> > >
> > > We need to enable the use of SLPC Compute strategy during init, but
> > > it will apply only to contexts that set this bit during context
> > > creation.
> > >
> > > Userland can check whether this feature is supported using a new param-
> > > I915_PARAM_HAS_CONTEXT_FREQ_HINTS. This flag is true for all guc
> > > submission
> > > enabled platforms as they use SLPC for frequency management.
> > >
> > > The Mesa usage model for this flag is here -
> > > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
> > >
> > > v2: Rename flags as per review suggestions (Rodrigo, Tvrtko).
> > > Also, use flag bits in intel_context as it allows finer control for
> > > toggling per engine if needed (Tvrtko).
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Tvrtko Ursulin
> > > Cc: Sushma Venkatesh Reddy
> > > Signed-off-by: Vinay Belgaumkar
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +++--
> > > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> > > drivers/gpu/drm/i915/gt/intel_rps.c | 5 +
> > > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++
> > > drivers/gpu/drm/i915/i915_getparam.c | 12 +++
> > > include/uapi/drm/i915_drm.h | 15 +
> > > 10 files changed, 92 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > index dcbfe32fd30c..0799cb0b2803 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> > > drm_i915_file_private *fpriv,
> > > struct i915_gem_proto_context *pc,
> > > struct drm_i915_gem_context_param *args)
> > > {
> > > + struct drm_i915_private *i915 = fpriv->i915;
> > > int ret = 0;
> > > switch (args->param) {
> > > @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> > > drm_i915_file_private *fpriv,
> > > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > > break;
> > > + case I915_CONTEXT_PARAM_LOW_LATENCY:
> > > + if (intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > + pc->user_flags |= BIT(UCONTEXT_LOW_LATENCY);
> > > + else
> > > + ret = -EINVAL;
> > > + break;
> > > +
> > > case I915_CONTEXT_PARAM_RECOVERABLE:
> > > if (args->size)
> > > ret = -EINVAL;
> > > @@ -992,6 +1000,9 @@ static int intel_context_set_gem(struct
> > > intel_context *ce,
> > > if (sseu.slice_mask && !WARN_ON(ce->engine->class !=
> > > RENDER_CLASS))
> > > ret = intel_context_reconfigure_sseu(ce, sseu);
> > > + if (test_bit(UCONTEXT_LOW_LATENCY, >user_flags))
> > > + set_bit(CONTEXT_LOW_LATENCY, >flags);
> >
> > Does not need to be atomic so can use __set_bit as higher up in the
> > function.
> ok.
> >
> > > +
> > > return ret;
> > > }
> > > @@ -1630,6 +1641,8 @@ i915_gem_create_context(struct
> > > drm_i915_private *i915,
> > > if (vm)
> > > ctx->vm = vm;
> > > + ctx->user_flags = pc->user_flags;
> > > +
&
Re: [PATCH] MAINTAINERS: Update email address for Tvrtko Ursulin
On Wed, Feb 28, 2024 at 02:22:40PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > I will lose access to my @.*intel.com e-mail addresses soon so let me > adjust the maintainers entry and update the mailmap too. > > While at it consolidate a few other of my old emails to point to the > main one. > > Signed-off-by: Tvrtko Ursulin > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi Acked-by: Rodrigo Vivi > --- > .mailmap| 5 + > MAINTAINERS | 2 +- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index b99a238ee3bd..d67e351bce8e 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -608,6 +608,11 @@ TripleX Chung > TripleX Chung > Tsuneo Yoshioka > Tudor Ambarus > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > Tycho Andersen > Tzung-Bi Shih > Uwe Kleine-König > diff --git a/MAINTAINERS b/MAINTAINERS > index 19f6f8014f94..b940bfe2a692 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10734,7 +10734,7 @@ INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older > excluding Poulsbo, Moorestown > M: Jani Nikula > M: Joonas Lahtinen > M: Rodrigo Vivi > -M: Tvrtko Ursulin > +M: Tvrtko Ursulin > L: intel-...@lists.freedesktop.org > S: Supported > W: https://drm.pages.freedesktop.org/intel-docs/ > -- > 2.40.1 >
Re: i915 build error on drm-misc-next
On Fri, Feb 23, 2024 at 09:47:11AM -0800, Abhinav Kumar wrote:
> CC Dmitry
>
> Hi Rodrigo
>
> On 2/23/2024 9:00 AM, Rodrigo Vivi wrote:
> > On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> > > With the x86_64_defconfig I see the following when building drm-misc-next:
> > >
> > >CC drivers/gpu/drm/i915/display/intel_crt.o
> > >CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> > >CC drivers/gpu/drm/i915/display/intel_ddi.o
> > >CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> > >CC drivers/gpu/drm/i915/display/intel_display_device.o
> > >CC drivers/gpu/drm/i915/display/intel_display_trace.o
> > >CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> > >CC drivers/gpu/drm/i915/display/intel_dp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> > >CC drivers/gpu/drm/i915/display/intel_dvo.o
> > >CC drivers/gpu/drm/i915/display/intel_gmbus.o
> > >CC drivers/gpu/drm/i915/display/intel_hdmi.o
> > >CC drivers/gpu/drm/i915/display/intel_lspcon.o
> > >CC drivers/gpu/drm/i915/display/intel_lvds.o
> > >CC drivers/gpu/drm/i915/display/intel_panel.o
> > >CC drivers/gpu/drm/i915/display/intel_pps.o
> > > drivers/gpu/drm/i915/display/intel_dp.c: In function
> > > ‘intel_write_dp_vsc_sdp’:
> > > drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit
> > > declaration
> > > of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> > > [-Werror=implicit-function-declaration]
> > > 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> > >| ^
> > >| drm_dp_vsc_sdp_pack
> > >
> > > Is this a known issue?
> >
> > o.O - what a mistery!
> >
> > it looks that drm-misc-next has only part of the patch:
> > 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
> >
> > without the patch itself...
> >
> > I couldn't even trace back to understand how the declaration is
> > gone from the drm-misc-next...
> >
>
> Looks like the issue here is that the below patch which landed in
> drm-misc-next
>
> https://patchwork.freedesktop.org/patch/579128/?series=130145=1
>
> was based on top of drm-tip because the intel CI runs on drm-tip and not
> drm-misc-next.
>
> But, https://patchwork.freedesktop.org/patch/572622/ is not present in
> drm-misc-next.
>
> Hence this broke the compilation.
>
> How would you prefer to fix this? We revert
> https://patchwork.freedesktop.org/series/130145/ from drm-misc and land it
> through i915 tree and can you provide us a tag from the i915 tree to rebase
> our msm-next tree on?
The revert from drm-misc is a possibility, then you squash
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
in and merge it again.
or if drm-misc and drm maintainers are okay we can simply add
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
on top of drm-misc-next
and on any conflict later the resolution is simply deleting this line
anyway.
>
> > >
> > > -Jeff
Re: [PATCH] drm/i915/guc: Add Compute context hint
On Fri, Feb 23, 2024 at 10:31:41AM -0800, Belgaumkar, Vinay wrote: > > On 2/23/2024 12:51 AM, Tvrtko Ursulin wrote: > > > > On 22/02/2024 23:31, Belgaumkar, Vinay wrote: > > > > > > On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote: > > > > > > > > On 21/02/2024 21:28, Rodrigo Vivi wrote: > > > > > On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote: > > > > > > > > > > > > On 21/02/2024 00:14, Vinay Belgaumkar wrote: > > > > > > > Allow user to provide a context hint. When this is set, KMD will > > > > > > > send a hint to GuC which results in special handling for this > > > > > > > context. SLPC will ramp the GT frequency aggressively every time > > > > > > > it switches to this context. The down freq threshold will also be > > > > > > > lower so GuC will ramp down the GT freq for this > > > > > > > context more slowly. > > > > > > > We also disable waitboost for this context as that > > > > > > > will interfere with > > > > > > > the strategy. > > > > > > > > > > > > > > We need to enable the use of Compute strategy during SLPC init, > > > > > > > but > > > > > > > it will apply only to contexts that set this bit during context > > > > > > > creation. > > > > > > > > > > > > > > Userland can check whether this feature is supported > > > > > > > using a new param- > > > > > > > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true > > > > > > > for all guc submission > > > > > > > enabled platforms since they use SLPC for freq management. > > > > > > > > > > > > > > The Mesa usage model for this flag is here - > > > > > > > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint > > > > > > > > > > > > This allows for setting it for the whole application, > > > > > > correct? Upsides, > > > > > > downsides? Are there any plans for per context? > > > > > > > > > > Currently there's no extension on a high level API > > > > > (Vulkan/OpenGL/OpenCL/etc) > > > > > that would allow the application to hint for > > > > > power/freq/latency. So Mesa cannot > > > > > decide when to hint. So their solution was to use .drirc and > > > > > make per-application > > > > > decision. > > > > > > > > > > I would prefer a high level extension for a more granular > > > > > and informative > > > > > decision. We need to work with that goal, but for now I don't see any > > > > > cons on this approach. > > > > > > > > In principle yeah I doesn't harm to have the option. I am just > > > > not sure how useful this intermediate step this is with its lack > > > > of intra-process granularity. > > > > > > > > > > > Cc: Rodrigo Vivi > > > > > > > Signed-off-by: Vinay Belgaumkar > > > > > > > --- > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++ > > > > > > > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + > > > > > > > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++ > > > > > > > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | > > > > > > > 21 +++ > > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | > > > > > > > 17 +++ > > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 + > > > > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++ > > > > > > > drivers/gpu/drm/i915/i915_getparam.c | 11 ++ > > > > > > > include/uapi/drm/i915_drm.h | 15 > > > > > > > + > > > > > > > 9 files changed, 89 insertions(+) > > > > > > > > > > > > > > diff --git > > > > > > > a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > > > >
[PATCH] drm/i915: convert remaining intel_dp_vsc_sdp_pack
Commit 47f419e07111 ("drm/dp: move intel_dp_vsc_sdp_pack() to generic helper")
and commit b55b88d86fec ("drm/dp: drop the size parameter from
drm_dp_vsc_sdp_pack()")
were based on top of a tree containing the
commit 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation") but
landed in a tree where this commit didn't exist, leaving behind a spurious
case calling for a removed function: intel_dp_vsc_sdp_pack()
Let's convert the remaining case here so we can port this patch to
any tree that doesn't contain
commit 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
In in kind of merge where this commit does exist, this line here will
be gone anyway and not needed any longer.
Fixes: 47f419e07111 ("drm/dp: move intel_dp_vsc_sdp_pack() to generic helper")
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Maxime Ripard
Cc: Maarten Lankhorst
Cc: Thomas Zimmermann
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 756c15791a3c..c2e73ba5b2b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4229,7 +4229,7 @@ void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
struct dp_sdp sdp = {};
ssize_t len;
- len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
+ len = drm_dp_vsc_sdp_pack(vsc, );
if (drm_WARN_ON(_priv->drm, len < 0))
return;
--
2.43.2
Re: i915 build error on drm-misc-next
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> With the x86_64_defconfig I see the following when building drm-misc-next:
>
> CC drivers/gpu/drm/i915/display/intel_crt.o
> CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> CC drivers/gpu/drm/i915/display/intel_ddi.o
> CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> CC drivers/gpu/drm/i915/display/intel_display_device.o
> CC drivers/gpu/drm/i915/display/intel_display_trace.o
> CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> CC drivers/gpu/drm/i915/display/intel_dp.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> CC drivers/gpu/drm/i915/display/intel_dsi.o
> CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> CC drivers/gpu/drm/i915/display/intel_dvo.o
> CC drivers/gpu/drm/i915/display/intel_gmbus.o
> CC drivers/gpu/drm/i915/display/intel_hdmi.o
> CC drivers/gpu/drm/i915/display/intel_lspcon.o
> CC drivers/gpu/drm/i915/display/intel_lvds.o
> CC drivers/gpu/drm/i915/display/intel_panel.o
> CC drivers/gpu/drm/i915/display/intel_pps.o
> drivers/gpu/drm/i915/display/intel_dp.c: In function
> ‘intel_write_dp_vsc_sdp’:
> drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit declaration
> of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> [-Werror=implicit-function-declaration]
> 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> | ^
> | drm_dp_vsc_sdp_pack
>
> Is this a known issue?
o.O - what a mistery!
it looks that drm-misc-next has only part of the patch:
31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
without the patch itself...
I couldn't even trace back to understand how the declaration is
gone from the drm-misc-next...
>
> -Jeff
Re: [PATCH 2/2] drm/i915: Support replaying GPU hangs with captured context image
On Wed, Feb 21, 2024 at 02:22:45PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When debugging GPU hangs Mesa developers are finding it useful to replay
> the captured error state against the simulator. But due various simulator
> limitations which prevent replicating all hangs, one step further is being
> able to replay against a real GPU.
>
> This is almost doable today with the missing part being able to upload the
> captured context image into the driver state prior to executing the
> uploaded hanging batch and all the buffers.
>
> To enable this last part we add a new context parameter called
> I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
> configuration pattern of being able to select which context to apply
> against, paired with the actual image and its size.
>
> Since this is adding a new concept of debug only uapi, we hide it behind
> a new kconfig option and also require activation with a module parameter.
> Together with a warning banner printed at driver load, all those combined
> should be sufficient to guard against inadvertently enabling the feature.
>
> In terms of implementation we allow the legacy context set param to be
> used since that removes the need to record the per context data in the
> proto context, while still allowing flexibility of specifying context
> images for any context.
>
> Mesa MR using the uapi can be seen at:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
>
> v2:
> * Fix whitespace alignment as per checkpatch.
> * Added warning on userspace misuse.
> * Rebase for extracting ce->default_state shadowing.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel Landwerlin
> Cc: Carlos Santa
> Cc: Rodrigo Vivi
> Reviewed-by: Rodrigo Vivi # v1
still valid for v2. Thanks for splitting the patch.
> ---
> drivers/gpu/drm/i915/Kconfig.debug| 17 +++
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 113 ++
> drivers/gpu/drm/i915/gt/intel_context.c | 2 +
> drivers/gpu/drm/i915/gt/intel_context.h | 22
> drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
> drivers/gpu/drm/i915/i915_params.c| 5 +
> drivers/gpu/drm/i915/i915_params.h| 3 +-
> include/uapi/drm/i915_drm.h | 27 +
> 10 files changed, 193 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 5b7162076850..32e9f70e91ed 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -16,6 +16,23 @@ config DRM_I915_WERROR
>
> If in doubt, say "N".
>
> +config DRM_I915_REPLAY_GPU_HANGS_API
> + bool "Enable GPU hang replay userspace API"
> + depends on DRM_I915
> + depends on EXPERT
> + default n
> + help
> + Choose this option if you want to enable special and unstable
> + userspace API used for replaying GPU hangs on a running system.
> +
> + This API is intended to be used by userspace graphics stack developers
> + and provides no stability guarantees.
> +
> + The API needs to be activated at boot time using the
> + enable_debug_only_api module parameter.
> +
> + If in doubt, say "N".
> +
> config DRM_I915_DEBUG
> bool "Enable additional driver debugging"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..481aacbc1772 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -78,6 +78,7 @@
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_ring.h"
> +#include "gt/shmem_utils.h"
>
> #include "pxp/intel_pxp.h"
>
> @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> case I915_CONTEXT_PARAM_NO_ZEROMAP:
> case I915_CONTEXT_PARAM_BAN_PERIOD:
> case I915_CONTEXT_PARAM_RINGSIZE:
> + case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
> default:
> ret = -EINVAL;
> break;
> @@ -2092,6 +2094,95 @@ static int get_protected(struct i915_gem_context *ctx,
> return 0;
> }
>
> +static int set_context_image(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + struct i915_gem_context_pa
Re: [PATCH 1/2] drm/i915: Shadow default engine context image in the context
On Wed, Feb 21, 2024 at 02:22:44PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To enable adding override of the default engine context image let us start
> shadowing the per engine state in the context.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel Landwerlin
> Cc: Carlos Santa
> Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
> drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 ---
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index 7eccbd70d89f..b179178680a5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -99,6 +99,8 @@ struct intel_context {
> struct i915_address_space *vm;
> struct i915_gem_context __rcu *gem_context;
>
> + struct file *default_state;
> +
> /*
>* @signal_lock protects the list of requests that need signaling,
>* @signals. While there are any requests that need signaling,
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 7c367ba8d9dc..d4eb822d20ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1060,9 +1060,8 @@ void lrc_init_state(struct intel_context *ce,
>
> set_redzone(state, engine);
>
> - if (engine->default_state) {
> - shmem_read(engine->default_state, 0,
> -state, engine->context_size);
> + if (ce->default_state) {
> + shmem_read(ce->default_state, 0, state, engine->context_size);
> __set_bit(CONTEXT_VALID_BIT, >flags);
> inhibit = false;
> }
> @@ -1174,6 +1173,8 @@ int lrc_alloc(struct intel_context *ce, struct
> intel_engine_cs *engine)
>
> GEM_BUG_ON(ce->state);
>
> + ce->default_state = engine->default_state;
> +
> vma = __lrc_alloc_state(ce, engine);
> if (IS_ERR(vma))
> return PTR_ERR(vma);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 92085ffd23de..8625e88e785f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -474,8 +474,7 @@ static int ring_context_init_default_state(struct
> intel_context *ce,
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
> - shmem_read(ce->engine->default_state, 0,
> -vaddr, ce->engine->context_size);
> + shmem_read(ce->default_state, 0, vaddr, ce->engine->context_size);
>
> i915_gem_object_flush_map(obj);
> __i915_gem_object_release_map(obj);
> @@ -491,7 +490,7 @@ static int ring_context_pre_pin(struct intel_context *ce,
> struct i915_address_space *vm;
> int err = 0;
>
> - if (ce->engine->default_state &&
> + if (ce->default_state &&
> !test_bit(CONTEXT_VALID_BIT, >flags)) {
> err = ring_context_init_default_state(ce, ww);
> if (err)
> @@ -570,6 +569,8 @@ static int ring_context_alloc(struct intel_context *ce)
> {
> struct intel_engine_cs *engine = ce->engine;
>
> + ce->default_state = engine->default_state;
> +
> /* One ringbuffer to rule them all */
> GEM_BUG_ON(!engine->legacy.ring);
> ce->ring = engine->legacy.ring;
> --
> 2.40.1
>
Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
it looks indeed an unecessary check.
you can convert my ack to a
Reviewed-by: Rodrigo Vivi
and the ack to take this through drm-misc if needed
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
> include/drm/display/drm_dp_helper.h | 3 +--
> 3 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 6c91f400ecb1..10ee82e34de7 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> * @vsc: vsc sdp initialized according to its purpose as defined in
> * table 2-118 - table 2-120 in DP 1.4a specification
> * @sdp: valid handle to the generic dp_sdp which will be packed
> - * @size: valid size of the passed sdp handle
> *
> * Returns length of sdp on success and error code on failure
> */
> ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size)
> + struct dp_sdp *sdp)
> {
> size_t length = sizeof(struct dp_sdp);
>
> - if (size < length)
> - return -ENOSPC;
> -
> - memset(sdp, 0, size);
> + memset(sdp, 0, sizeof(struct dp_sdp));
>
> /*
>* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a9458df475e2..e13121dc3a03 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder
> *encoder,
>
> switch (type) {
> case DP_SDP_VSC:
> - len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
> - sizeof(sdp));
> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
> break;
> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 8474504d4c88..1f41994796d3 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int bpp_x16, unsigned long flags);
> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
>
> -ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size);
> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp
> *sdp);
>
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.34.1
>
Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
Acked-by: Rodrigo Vivi
> include/drm/display/drm_dp_helper.h | 3 +--
> 3 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 6c91f400ecb1..10ee82e34de7 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> * @vsc: vsc sdp initialized according to its purpose as defined in
> * table 2-118 - table 2-120 in DP 1.4a specification
> * @sdp: valid handle to the generic dp_sdp which will be packed
> - * @size: valid size of the passed sdp handle
> *
> * Returns length of sdp on success and error code on failure
> */
> ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size)
> + struct dp_sdp *sdp)
> {
> size_t length = sizeof(struct dp_sdp);
>
> - if (size < length)
> - return -ENOSPC;
> -
> - memset(sdp, 0, size);
> + memset(sdp, 0, sizeof(struct dp_sdp));
>
> /*
>* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a9458df475e2..e13121dc3a03 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder
> *encoder,
>
> switch (type) {
> case DP_SDP_VSC:
> - len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
> - sizeof(sdp));
> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
> break;
> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 8474504d4c88..1f41994796d3 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int bpp_x16, unsigned long flags);
> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
>
> -ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size);
> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp
> *sdp);
>
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.34.1
>
Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code
On Thu, Feb 22, 2024 at 01:43:49PM -0500, Steven Rostedt wrote:
> On Thu, 22 Feb 2024 13:30:57 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > I'm working on improving the __assign_str() and __string() macros to be
> > more efficient, and removed some unneeded semicolons. This triggered a bug
> > in the build as some of the __assign_str() macros in intel_display_trace
> > was missing a terminating semicolon.
> >
> > Fixes: 2ceea5d88048b ("drm/i915: Print plane name in fbc tracepoints")
> > Signed-off-by: Steven Rostedt (Google)
> > ---
>
> Note, I have patches that depend on this fix, so if one of the maintainers
> would like to just give me an "Acked-by", I'll take it through my tree. I
> doubt it will have any conflicts, unless you are planning on changing the
> given effected events.
since it is not breaking builds on our side and the conflicts, if any, would
be minimal, feel free to take this trough your tree
Acked-by: Rodrigo Vivi
>
> -- Steve
Re: [PATCH] drm/i915/guc: Add Compute context hint
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
>
> On 21/02/2024 00:14, Vinay Belgaumkar wrote:
> > Allow user to provide a context hint. When this is set, KMD will
> > send a hint to GuC which results in special handling for this
> > context. SLPC will ramp the GT frequency aggressively every time
> > it switches to this context. The down freq threshold will also be
> > lower so GuC will ramp down the GT freq for this context more slowly.
> > We also disable waitboost for this context as that will interfere with
> > the strategy.
> >
> > We need to enable the use of Compute strategy during SLPC init, but
> > it will apply only to contexts that set this bit during context
> > creation.
> >
> > Userland can check whether this feature is supported using a new param-
> > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
> > enabled platforms since they use SLPC for freq management.
> >
> > The Mesa usage model for this flag is here -
> > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
>
> This allows for setting it for the whole application, correct? Upsides,
> downsides? Are there any plans for per context?
Currently there's no extension on a high level API (Vulkan/OpenGL/OpenCL/etc)
that would allow the application to hint for power/freq/latency. So Mesa cannot
decide when to hint. So their solution was to use .drirc and make
per-application
decision.
I would prefer a high level extension for a more granular and informative
decision. We need to work with that goal, but for now I don't see any
cons on this approach.
>
> > Cc: Rodrigo Vivi
> > Signed-off-by: Vinay Belgaumkar
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
> > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
> > drivers/gpu/drm/i915/i915_getparam.c | 11 ++
> > include/uapi/drm/i915_drm.h | 15 +
> > 9 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index dcbfe32fd30c..ceab7dbe9b47 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> >struct i915_gem_proto_context *pc,
> >struct drm_i915_gem_context_param *args)
> > {
> > + struct drm_i915_private *i915 = fpriv->i915;
> > int ret = 0;
> > switch (args->param) {
> > @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > break;
> > + case I915_CONTEXT_PARAM_IS_COMPUTE:
> > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > + ret = -EINVAL;
> > + else
> > + pc->user_flags |= BIT(UCONTEXT_COMPUTE);
> > + break;
> > +
> > case I915_CONTEXT_PARAM_RECOVERABLE:
> > if (args->size)
> > ret = -EINVAL;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index 03bc7f9d191b..db86d6f6245f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -338,6 +338,7 @@ struct i915_gem_context {
> > #define UCONTEXT_BANNABLE 2
> > #define UCONTEXT_RECOVERABLE 3
> > #define UCONTEXT_PERSISTENCE 4
> > +#define UCONTEXT_COMPUTE 5
>
> What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set for
> non-compute engines? Wondering if per intel_context is what we want instead.
> (Which could then be the i915_context_param_engines extension to mark
> individual contexts as compute strategy.)
Perhaps we should rename this? This is a freq-decision-strategy inside
GuC that is there mostly targeting compute workloads that needs lower
latency with short burst execution. But the engine itself doesn't matter.
It can
Re: [RFC] drm/i915: Support replaying GPU hangs with captured context image
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > When debugging GPU hangs Mesa developers are finding it useful to replay > the captured error state against the simulator. But due various simulator > limitations which prevent replicating all hangs, one step further is being > able to replay against a real GPU. > > This is almost doable today with the missing part being able to upload the > captured context image into the driver state prior to executing the > uploaded hanging batch and all the buffers. > > To enable this last part we add a new context parameter called > I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU > configuration pattern of being able to select which context to apply > against, paired with the actual image and its size. > > Since this is adding a new concept of debug only uapi, we hide it behind > a new kconfig option and also require activation with a module parameter. > Together with a warning banner printed at driver load, all those combined > should be sufficient to guard against inadvertently enabling the feature. > > In terms of implementation the only trivial change is shadowing of the > default state from engine to context. We also allow the legacy context > set param to be used since that removes the need to record the per context > data in the proto context, while still allowing flexibility of specifying > context images for any context. > > Mesa MR using the uapi can be seen at: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594 I just wonder if it would be better to split the default_state in a separate patch but from what I could see it looks correct. Also, I have to say that this approach is nice, clean and well protected. And much simpler then I imagined when I saw the idea around. Feel free to use: Reviewed-by: Rodrigo Vivi > > Signed-off-by: Tvrtko Ursulin > Cc: Lionel Landwerlin > Cc: Carlos Santa > --- > drivers/gpu/drm/i915/Kconfig.debug| 17 +++ > drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++ > drivers/gpu/drm/i915/gt/intel_context.c | 2 + > drivers/gpu/drm/i915/gt/intel_context.h | 22 > drivers/gpu/drm/i915/gt/intel_context_types.h | 3 + > drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 8 +- > drivers/gpu/drm/i915/i915_params.c| 5 + > drivers/gpu/drm/i915/i915_params.h| 3 +- > include/uapi/drm/i915_drm.h | 27 + > 10 files changed, 194 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 5b7162076850..32e9f70e91ed 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -16,6 +16,23 @@ config DRM_I915_WERROR > > If in doubt, say "N". > > +config DRM_I915_REPLAY_GPU_HANGS_API > + bool "Enable GPU hang replay userspace API" > + depends on DRM_I915 > + depends on EXPERT > + default n > + help > + Choose this option if you want to enable special and unstable > + userspace API used for replaying GPU hangs on a running system. > + > + This API is intended to be used by userspace graphics stack developers > + and provides no stability guarantees. > + > + The API needs to be activated at boot time using the > + enable_debug_only_api module parameter. > + > + If in doubt, say "N". > + > config DRM_I915_DEBUG > bool "Enable additional driver debugging" > depends on DRM_I915 > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > index dcbfe32fd30c..1cfd624bd978 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > @@ -78,6 +78,7 @@ > #include "gt/intel_engine_user.h" > #include "gt/intel_gpu_commands.h" > #include "gt/intel_ring.h" > +#include "gt/shmem_utils.h" > > #include "pxp/intel_pxp.h" > > @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct > drm_i915_file_private *fpriv, > case I915_CONTEXT_PARAM_NO_ZEROMAP: > case I915_CONTEXT_PARAM_BAN_PERIOD: > case I915_CONTEXT_PARAM_RINGSIZE: > + case I915_CONTEXT_PARAM_CONTEXT_IMAGE: > default: > ret = -EINVAL; > break; > @@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx, > return 0; > } > > +static int set_context_image(struct i915_gem_context *ctx, &g
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
On Tue, Feb 20, 2024 at 11:52:04AM -0800, John Harrison wrote:
> On 2/19/2024 12:28, Rodrigo Vivi wrote:
> > On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The above w/a is required for every platform that the i915 driver
> > > supports. It is fixed on the latest platforms but they are only
> > > supported by Xe instead of i915. So just remove the platform check
> > > completely and keep the code simple.
> > Well, I was going to say that I would prefer a GMD version greater-than
> > check to be future proof. However if this code gets used in some other
> > new platform a new specific guc support would likely need to be added
> > as well right?
> There is no future for i915. That's the point. The only platforms that have
> the hardware fix are all ones that will only ever be supported by the Xe
> driver. So if such a platform were to be backported to i915 then there would
> be a lot more work than just adding a new GuC firmware platform.
>
> And going backwards, the bug affects all platforms that have a GuC. So if
> any GuC code is being executed at all, then this w/a is applicable.
>
> >
> > Perhaps at least adding a comment in the code?
> Such as this?
> /*
> * Wa_14018913170: Applicable to all platforms supported by i915.
I believe only this first line would be enough. but up to you and feel free
to put my rv-b with whatever version you get.
so
> * don't bother testing for all X/Y/Z platforms explicitly.
> */
>
> John.
>
>
> >
> > with that
> > Reviewed-by: Rodrigo Vivi
> >
> >
> > > Signed-off-by: John Harrison
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > index 2b450c43bbd7f..a3662edb42032 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
> > > /* Wa_14018913170 */
> > > if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> > > - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> > > IS_PONTEVECCHIO(gt->i915))
> > > - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > }
> > > return flags;
> > > --
> > > 2.43.0
> > >
>
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 08:06:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > > to update all the users of the struct drm_tv_connector_state mode field,
> > > > which resulted in a build failure in i915.
> > > >
> > > > However, a subsequent commit in the same series reintroduced a mode
> > > > field in that structure, with a different semantic but the same type,
> > > > with the assumption that all previous users were updated.
> > > >
> > > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > > accesses to the legacy_mode field and the newer mode field, but with the
> > > > previous semantics.
> > > >
> > > > This obviously doesn't work very well, so we need to update the accesses
> > > > that weren't in the legacy renaming commit.
> > > >
> > > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > > Reported-by: Ville Syrjälä
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > index 825638702ac1..5f9e748adc89 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > > > intel_sdvo *intel_sdvo,
> > > > struct intel_sdvo_tv_format format;
> > > > u32 format_map;
> > > >
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memset(, 0, sizeof(format));
> > > > memcpy(, _map, min(sizeof(format),
> > > > sizeof(format_map)));
> > > >
> > > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > > > drm_connector *connector)
> > > > * Read the list of supported input resolutions for the
> > > > selected TV
> > > > * format.
> > > > */
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memcpy(_res, _map,
> > > >min(sizeof(format_map), sizeof(struct
> > > > intel_sdvo_sdtv_resolution_request)));
> > > >
> > > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > > > drm_connector *connector,
> > > > int i;
> > > >
> > > > for (i = 0; i <
> > > > intel_sdvo_connector->format_supported_num; i++)
> > > > - if (state->tv.mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > + if (state->tv.legacy_mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > *val = i;
> > > >
> > > > return 0;
> > > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > > > drm_connector *connector,
> > > > struct intel_sdvo_connector_state *sdvo_state =
> > > > to_intel_sdvo_connector_state(state);
> > > >
> > > > if (property == intel_sdvo_connector->tv_format) {
> > > > - state->tv.mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > > + state->tv.legacy_mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > >
> > > > if (state->crtc) {
> > > > struct drm_crtc_state *crtc_state =
> > > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struc
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > to update all the users of the struct drm_tv_connector_state mode field,
> > which resulted in a build failure in i915.
> >
> > However, a subsequent commit in the same series reintroduced a mode
> > field in that structure, with a different semantic but the same type,
> > with the assumption that all previous users were updated.
> >
> > Since that didn't happen, the i915 driver now compiles, but mixes
> > accesses to the legacy_mode field and the newer mode field, but with the
> > previous semantics.
> >
> > This obviously doesn't work very well, so we need to update the accesses
> > that weren't in the legacy renaming commit.
> >
> > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > Reported-by: Ville Syrjälä
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > 2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index 825638702ac1..5f9e748adc89 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > intel_sdvo *intel_sdvo,
> > struct intel_sdvo_tv_format format;
> > u32 format_map;
> >
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memset(, 0, sizeof(format));
> > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> >
> > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > drm_connector *connector)
> > * Read the list of supported input resolutions for the selected TV
> > * format.
> > */
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memcpy(_res, _map,
> >min(sizeof(format_map), sizeof(struct
> > intel_sdvo_sdtv_resolution_request)));
> >
> > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > drm_connector *connector,
> > int i;
> >
> > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > - if (state->tv.mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > + if (state->tv.legacy_mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > *val = i;
> >
> > return 0;
> > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > drm_connector *connector,
> > struct intel_sdvo_connector_state *sdvo_state =
> > to_intel_sdvo_connector_state(state);
> >
> > if (property == intel_sdvo_connector->tv_format) {
> > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > + state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[val];
> >
> > if (state->crtc) {
> > struct drm_crtc_state *crtc_state =
> > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > intel_sdvo *intel_sdvo,
> > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> >
> > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> >
> > - intel_sdvo_connector->base.base.state->tv.mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > drm_object_attach_property(_sdvo_connector->base.base.base,
> >intel_sdvo_connector->tv_format, 0);
> > return true;
>
> Hmm. I didn't realize we are using this in the SDVO code as well.
> I don't *think* that one is actually broken since it has its own
> .{set,get}_property() hooks. But I suppose doing the rename
> there as well is a good idea anyway.
>
> Can you split the SDVO vs. TV into separate patches? We need to
> backport at least the TV part, and a smaller patch means less
> chance of conflicts. Or if you prefer I can chunk it up while
> pushing.
hmm ouch... I shouldn't had rushed with it, I'm sorry.
But I already merged this as is.
>
> Both parts are
> Reviewed-by: Ville Syrjälä
>
> Thanks.
>
> > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> > b/drivers/gpu/drm/i915/display/intel_tv.c
> > index a96bcfcf90a3..2b77d399f1a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> > @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
> >
> > static const struct tv_mode *intel_tv_mode_find(const struct
> >
Re: [PATCH] drm/i915/tv: Fix TV mode
On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> to update all the users of the struct drm_tv_connector_state mode field,
> which resulted in a build failure in i915.
>
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
just for the record, commit 7d63cd8526f1 ("drm/connector: Add TV standard
property")
>
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
>
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
>
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä
> Signed-off-by: Maxime Ripard
Reviewed-by: Rodrigo Vivi
and pushing to drm-intel-next soon...
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo
> *intel_sdvo,
> struct intel_sdvo_tv_format format;
> u32 format_map;
>
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memset(, 0, sizeof(format));
> memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memcpy(_res, _map,
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> drm_connector *connector,
> int i;
>
> for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> *val = i;
>
> return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> drm_connector *connector,
> struct intel_sdvo_connector_state *sdvo_state =
> to_intel_sdvo_connector_state(state);
>
> if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[val];
>
> if (state->crtc) {
> struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> intel_sdvo *intel_sdvo,
> drm_property_add_enum(intel_sdvo_connector->tv_format, i,
>
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> - intel_sdvo_connector->base.base.state->tv.mode =
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[0];
> drm_object_attach_property(_sdvo_connector->base.base.base,
> intel_sdvo_connector->tv_format, 0);
> return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>
> static const struct tv_mode *intel_tv_mode_find(const struct
> drm_connector_state *conn_state)
> {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>
> return _modes[format];
> }
> @@ -1705,7 +1705,7 @@ static
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The above w/a is required for every platform that the i915 driver
> supports. It is fixed on the latest platforms but they are only
> supported by Xe instead of i915. So just remove the platform check
> completely and keep the code simple.
Well, I was going to say that I would prefer a GMD version greater-than
check to be future proof. However if this code gets used in some other
new platform a new specific guc support would likely need to be added
as well right?
Perhaps at least adding a comment in the code?
with that
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 2b450c43bbd7f..a3662edb42032 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>
> /* Wa_14018913170 */
> if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> IS_PONTEVECCHIO(gt->i915))
> - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> }
>
> return flags;
> --
> 2.43.0
>
Re: [PATCH] drm/i915: check before removing mm notifier
On Mon, Feb 19, 2024 at 01:50:47PM +0100, Nirmoy Das wrote:
> Error in mmu_interval_notifier_insert() can leave a NULL
> notifier.mm pointer. Catch that and return early.
>
> Cc: Andi Shyti
> Cc: Shawn Lee
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 0e21ce9d3e5a..61abfb505766 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -349,6 +349,9 @@ i915_gem_userptr_release(struct drm_i915_gem_object *obj)
> {
> GEM_WARN_ON(obj->userptr.page_ref);
>
> + if (!obj->userptr.notifier.mm)
> + return;
> +
hmmm... right, it looks that we need this protection. But...
I mean, feel free to use
Reviewed-by: Rodrigo Vivi
for this patch,
but I believe that if this mmu insert failed we might have other
deeper problems like when checking i915_gem_object_is_userptr() ?
No?!
> mmu_interval_notifier_remove(>userptr.notifier);
> obj->userptr.notifier.mm = NULL;
> }
> --
> 2.42.0
>
Re: [PATCH] drm/i915: Fix possible null pointer dereference after drm_dbg_printer conversion
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Request can be NULL if no guilty request was identified so simply use
> engine->i915 instead.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: d50892a9554c ("drm/i915: switch from drm_debug_printer() to device
> specific drm_dbg_printer()")
> Reported-by: Dan Carpenter
> Cc: Jani Nikula
> Cc: Luca Coelho
> Cc: Maxime Ripard
> Cc: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 5f8d86e25993..8d4bb95f8424 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -96,8 +96,8 @@ static void heartbeat_commit(struct i915_request *rq,
> static void show_heartbeat(const struct i915_request *rq,
> struct intel_engine_cs *engine)
> {
> - struct drm_printer p = drm_dbg_printer(>i915->drm, DRM_UT_DRIVER,
> -"heartbeat");
> + struct drm_printer p =
> + drm_dbg_printer(>i915->drm, DRM_UT_DRIVER, "heartbeat");
>
> if (!rq) {
> intel_engine_dump(engine, ,
> --
> 2.40.1
>
Re: linux-next: build warning after merge of the drm tree
On Wed, Feb 07, 2024 at 05:17:19PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
> nonexisting document 'gpu/rfc/xe'
>
> Introduced by commit
>
> d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
It should be fixed by commit 70a46e1fda3b ("drm/doc/rfc: Removing missing
reference to xe.rst")
that is part of drm-misc/drm-misc-next and drm-misc/for-linux-next
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On Mon, Feb 05, 2024 at 09:44:56AM +0100, Christian König wrote:
> Am 02.02.24 um 22:58 schrieb Rodrigo Vivi:
> > On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> > > Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > > > Rather then loop over entities until one with a ready job is found,
> > > > re-queue the run job worker when drm_sched_entity_pop_job() returns
> > > > NULL.
> > > >
> > > > Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > > > worker")
> > First of all there's a small typo in this Fixes tag that needs to be fixed.
> > The correct one is:
> >
> > Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
Cc: Dave Airlie
> >
> > But I couldn't apply this right now in any of our drm-tip trees because it
> > is not clear where this is coming from originally.
> >
> > likely amd tree?!
>
> No, this comes from Matthews work on the DRM scheduler.
>
> Matthews patches were most likely merged through drm-misc.
the original is not there in drm-misc-next.
it looks like Dave had taken that one directly to drm-next.
So we either need the drm-misc maintainers to have a backmerge or
Dave to take this through the drm-fixes directly.
>
> Regards,
> Christian.
>
> >
> > > > Signed-off-by: Matthew Brost
> > > Reviewed-by: Christian König
> > Christian, if this came from the amd, could you please apply it there and
> > propagate through your fixes flow?
> >
> > Thanks,
> > Rodrigo.
> >
> > > > ---
> > > >drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> > > >1 file changed, 9 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > > > b/drivers/gpu/drm/scheduler/sched_main.c
> > > > index 8acbef7ae53d..7e90c9f95611 100644
> > > > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > > > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > > > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > > > work_struct *w)
> > > > struct drm_sched_entity *entity;
> > > > struct dma_fence *fence;
> > > > struct drm_sched_fence *s_fence;
> > > > - struct drm_sched_job *sched_job = NULL;
> > > > + struct drm_sched_job *sched_job;
> > > > int r;
> > > > if (READ_ONCE(sched->pause_submit))
> > > > return;
> > > > /* Find entity with a ready job */
> > > > - while (!sched_job && (entity = drm_sched_select_entity(sched)))
> > > > {
> > > > - sched_job = drm_sched_entity_pop_job(entity);
> > > > - if (!sched_job)
> > > > - complete_all(>entity_idle);
> > > > - }
> > > > + entity = drm_sched_select_entity(sched);
> > > > if (!entity)
> > > > return; /* No more work */
> > > > + sched_job = drm_sched_entity_pop_job(entity);
> > > > + if (!sched_job) {
> > > > + complete_all(>entity_idle);
> > > > + drm_sched_run_job_queue(sched);
> > > > + return;
> > > > + }
> > > > +
> > > > s_fence = sched_job->s_fence;
> > > > atomic_add(sched_job->credits, >credit_count);
>
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > Rather then loop over entities until one with a ready job is found,
> > re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
> >
> > Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
First of all there's a small typo in this Fixes tag that needs to be fixed.
The correct one is:
Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
worker")
But I couldn't apply this right now in any of our drm-tip trees because it
is not clear where this is coming from originally.
likely amd tree?!
> > Signed-off-by: Matthew Brost
>
> Reviewed-by: Christian König
Christian, if this came from the amd, could you please apply it there and
propagate through your fixes flow?
Thanks,
Rodrigo.
>
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 8acbef7ae53d..7e90c9f95611 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > work_struct *w)
> > struct drm_sched_entity *entity;
> > struct dma_fence *fence;
> > struct drm_sched_fence *s_fence;
> > - struct drm_sched_job *sched_job = NULL;
> > + struct drm_sched_job *sched_job;
> > int r;
> > if (READ_ONCE(sched->pause_submit))
> > return;
> > /* Find entity with a ready job */
> > - while (!sched_job && (entity = drm_sched_select_entity(sched))) {
> > - sched_job = drm_sched_entity_pop_job(entity);
> > - if (!sched_job)
> > - complete_all(>entity_idle);
> > - }
> > + entity = drm_sched_select_entity(sched);
> > if (!entity)
> > return; /* No more work */
> > + sched_job = drm_sched_entity_pop_job(entity);
> > + if (!sched_job) {
> > + complete_all(>entity_idle);
> > + drm_sched_run_job_queue(sched);
> > + return;
> > + }
> > +
> > s_fence = sched_job->s_fence;
> > atomic_add(sched_job->credits, >credit_count);
>
Re: [PATCH v4 1/3] drm/i915/vma: Fix UAF on destroy against retire race
On Tue, Jan 23, 2024 at 11:51:15AM +0100, Janusz Krzysztofik wrote: > Hi Rodrigo, > > Thank you for review. > > On Monday, 22 January 2024 22:09:38 CET Rodrigo Vivi wrote: > > On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote: > > > Object debugging tools were sporadically reporting illegal attempts to > > > free a still active i915 VMA object when parking a GPU tile believed to be > > > idle. > > > > > > [161.359441] ODEBUG: free active (active state 0) object: > > > 88811643b958 object type: i915_active hint: > > > __i915_vma_active+0x0/0x50 [i915] > > > [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 > > > debug_print_object+0x80/0xb0 > > > ... > > > [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted > > > 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 > > > [161.360314] Hardware name: Intel Corporation Rocket Lake Client > > > Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 > > > 04/21/2022 > > > [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] > > > [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 > > > ... > > > [161.361347] debug_object_free+0xeb/0x110 > > > [161.361362] i915_active_fini+0x14/0x130 [i915] > > > [161.361866] release_references+0xfe/0x1f0 [i915] > > > [161.362543] i915_vma_parked+0x1db/0x380 [i915] > > > [161.363129] __gt_park+0x121/0x230 [i915] > > > [161.363515] intel_wakeref_put_last+0x1f/0x70 [i915] > > > > > > That has been tracked down to be happening when another thread is > > > deactivating the VMA inside __active_retire() helper, after the VMA's > > > active counter has been already decremented to 0, but before deactivation > > > of the VMA's object is reported to the object debugging tool. > > > > > > We could prevent from that race by serializing i915_active_fini() with > > > __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from > > > being used, e.g. from __i915_vma_retire() called at the end of > > > __active_retire(), after that VMA has been already freed by a concurrent > > > i915_vma_destroy() on return from the i915_active_fini(). Then, we should > > > rather fix the issue at the VMA level, not in i915_active. > > > > > > Since __i915_vma_parked() is called from __gt_park() on last put of the > > > GT's wakeref, the issue could be addressed by holding the GT wakeref long > > > enough for __active_retire() to complete before that wakeref is released > > > and the GT parked. > > > > > > A VMA associated with a request doesn't acquire a GT wakeref by itself. > > > Instead, it depends on a wakeref held directly by the request's active > > > intel_context for a GT associated with its VM, and indirectly on that > > > intel_context's engine wakeref if the engine belongs to the same GT as the > > > VMA's VM. In case of single-tile platforms, at least one of those > > > wakerefs is usually held long enough for the request's VMA to be > > > deactivated on time, before it is destroyed on last put of its VM GT > > > wakeref. However, on multi-tile platforms, a request may use a VMA from a > > > tile other than the one that hosts the request's engine, then it is > > > protected only with the intel_context's VM GT wakeref. > > > > > > There was an attempt to fix this issue on 2-tile Meteor Lake by acquiring > > > > please do not confuse the terminology here. MTL is 1-tile platform, > > with multiple GTs (1 for Render/Compute and 1 for Media). > > I didn't realize that "tile" is not the same as "GT". I can review the whole > description and replace all occurrences of "tile" with "GT". yeap, in i915 it is a 1-1 map... a tile is implemented within the intel_gt. In Xe there's a good split and a good doc picture is here: https://dri.freedesktop.org/docs/drm/gpu/driver-uapi.html#drm-xe-uapi > > > > > Also you could probably avoid mentioning the other case here when > > you are actively trying to resolve the RKL's single GT case. > > OK, but let me keep that part of commit description in the cover letter then, > because: > - historically, the issue was more frequently reproduced in CI on MTL than on > other platforms, and that was the initial scope I started working on, > - the full description as is better reflects phases of my process of > reproduction and root cause analysis of the issue, > - the MTL case was specif
Re: [PATCH v4 2/3] Manually revert "drm/i915: Fix a VMA UAF for multi-gt platform"
On Mon, Jan 22, 2024 at 03:04:43PM +0100, Janusz Krzysztofik wrote:
> This reverts changes introduced by commit f56fe3e91787, obsoleted by
> "drm/i915/vma: Fix UAF on destroy against retire race".
I believe the good chunk of the first commit message should be moved
here instead.
But why did you do a 'manually revert'? revert itself didn't apply?
maybe you could avoid the word 'revert' and use something like
Remove extra multi-gt pm-references... or something like that.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d3a771afb083e..cedca8fd8754d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2686,7 +2686,6 @@ static int
> eb_select_engine(struct i915_execbuffer *eb)
> {
> struct intel_context *ce, *child;
> - struct intel_gt *gt;
> unsigned int idx;
> int err;
>
> @@ -2710,17 +2709,10 @@ eb_select_engine(struct i915_execbuffer *eb)
> }
> }
> eb->num_batches = ce->parallel.number_children + 1;
> - gt = ce->engine->gt;
>
> for_each_child(ce, child)
> intel_context_get(child);
> eb->wakeref = intel_gt_pm_get(ce->engine->gt);
> - /*
> - * Keep GT0 active on MTL so that i915_vma_parked() doesn't
> - * free VMAs while execbuf ioctl is validating VMAs.
> - */
> - if (gt->info.id)
> - eb->wakeref_gt0 = intel_gt_pm_get(to_gt(gt->i915));
>
> if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
> err = intel_context_alloc_state(ce);
> @@ -2759,9 +2751,6 @@ eb_select_engine(struct i915_execbuffer *eb)
> return err;
>
> err:
> - if (gt->info.id)
> - intel_gt_pm_put(to_gt(gt->i915), eb->wakeref_gt0);
> -
> intel_gt_pm_put(ce->engine->gt, eb->wakeref);
> for_each_child(ce, child)
> intel_context_put(child);
> @@ -2775,12 +2764,6 @@ eb_put_engine(struct i915_execbuffer *eb)
> struct intel_context *child;
>
> i915_vm_put(eb->context->vm);
> - /*
> - * This works in conjunction with eb_select_engine() to prevent
> - * i915_vma_parked() from interfering while execbuf validates vmas.
> - */
> - if (eb->gt->info.id)
> - intel_gt_pm_put(to_gt(eb->gt->i915), eb->wakeref_gt0);
> intel_gt_pm_put(eb->context->engine->gt, eb->wakeref);
> for_each_child(eb->context, child)
> intel_context_put(child);
> --
> 2.43.0
>
Re: [PATCH v4 1/3] drm/i915/vma: Fix UAF on destroy against retire race
On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> Object debugging tools were sporadically reporting illegal attempts to
> free a still active i915 VMA object when parking a GPU tile believed to be
> idle.
>
> [161.359441] ODEBUG: free active (active state 0) object: 88811643b958
> object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
> [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514
> debug_print_object+0x80/0xb0
> ...
> [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted
> 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1
> [161.360314] Hardware name: Intel Corporation Rocket Lake Client
> Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138
> 04/21/2022
> [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]
> [161.360592] RIP: 0010:debug_print_object+0x80/0xb0
> ...
> [161.361347] debug_object_free+0xeb/0x110
> [161.361362] i915_active_fini+0x14/0x130 [i915]
> [161.361866] release_references+0xfe/0x1f0 [i915]
> [161.362543] i915_vma_parked+0x1db/0x380 [i915]
> [161.363129] __gt_park+0x121/0x230 [i915]
> [161.363515] intel_wakeref_put_last+0x1f/0x70 [i915]
>
> That has been tracked down to be happening when another thread is
> deactivating the VMA inside __active_retire() helper, after the VMA's
> active counter has been already decremented to 0, but before deactivation
> of the VMA's object is reported to the object debugging tool.
>
> We could prevent from that race by serializing i915_active_fini() with
> __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from
> being used, e.g. from __i915_vma_retire() called at the end of
> __active_retire(), after that VMA has been already freed by a concurrent
> i915_vma_destroy() on return from the i915_active_fini(). Then, we should
> rather fix the issue at the VMA level, not in i915_active.
>
> Since __i915_vma_parked() is called from __gt_park() on last put of the
> GT's wakeref, the issue could be addressed by holding the GT wakeref long
> enough for __active_retire() to complete before that wakeref is released
> and the GT parked.
>
> A VMA associated with a request doesn't acquire a GT wakeref by itself.
> Instead, it depends on a wakeref held directly by the request's active
> intel_context for a GT associated with its VM, and indirectly on that
> intel_context's engine wakeref if the engine belongs to the same GT as the
> VMA's VM. In case of single-tile platforms, at least one of those
> wakerefs is usually held long enough for the request's VMA to be
> deactivated on time, before it is destroyed on last put of its VM GT
> wakeref. However, on multi-tile platforms, a request may use a VMA from a
> tile other than the one that hosts the request's engine, then it is
> protected only with the intel_context's VM GT wakeref.
>
> There was an attempt to fix this issue on 2-tile Meteor Lake by acquiring
please do not confuse the terminology here. MTL is 1-tile platform,
with multiple GTs (1 for Render/Compute and 1 for Media).
Also you could probably avoid mentioning the other case here when
you are actively trying to resolve the RKL's single GT case.
> an extra wakeref for a Primary GT from i915_gem_do_execbuffer() -- see
> commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform").
> However, it occurred insufficient -- the issue was still reported by CI.
> That wakeref was released on exit from i915_gem_do_execbuffer(), then
> potentially before completion of the request and deactivation of its
> associated VMAs.
>
> OTOH, CI reports indicate that single-tile platforms also suffer
> sporadically from the same race.
>
> I believe the issue was introduced by commit d93939730347 ("drm/i915:
> Remove the vma refcount") which moved a call to i915_active_fini() from
> a dropped i915_vma_release(), called on last put of the removed VMA kref,
> to i915_vma_parked() processing path called on last put of a GT wakeref.
> However, its visibility to the object debugging tool was suppressed by a
> bug in i915_active that was fixed two weeks later with commit e92eb246feb9
> ("drm/i915/active: Fix missing debug object activation").
>
> Fix the issue by getting a wakeref for the VMA's tile when activating it,
> and putting that wakeref only after the VMA is deactivated. However,
> exclude global GTT from that processing path, otherwise the GPU never goes
> idle. Since __i915_vma_retire() may be called from atomic contexts, use
> async variant of wakeref put.
okay, this explains the first block of the patch below, but I'm afraid
that it doesn't explain why:
- if (flags & PIN_GLOBAL)
>
> v4: Refresh on top of commit 5e4e06e4087e ("drm/i915: Track gt pm
> wakerefs") (Andi),
> - for more easy backporting, split out removal of former insufficient
> workarounds and move them to separate patches (Nirmoy).
> - clean up commit message and description a bit.
> v3: Identify root cause more precisely, and a commit to blame,
Re: [PATCH] drm/doc/rfc: Removing missing reference to xe.rst
On Fri, Jan 19, 2024 at 04:29:50PM +, Matthew Auld wrote:
> On 19/01/2024 16:25, Rodrigo Vivi wrote:
> > On Tue, Jan 16, 2024 at 05:03:31PM -0500, Rodrigo Vivi wrote:
> > > The file has already been deleted as the tasks were completed.
> > > However the index reference was missed behind.
> >
> > Gentle ping on this one.
> > I should have mentioned here that this fixes a doc build warning:
> >
> > Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
> > nonexisting document 'gpu/rfc/xe'
> >
> > >
> > > Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
> > > Cc: Lucas De Marchi
> > > Signed-off-by: Rodrigo Vivi
> Reviewed-by: Matthew Auld
Thank you for the prompt request.
pushed to drm-misc-next
Re: [PATCH] drm/doc/rfc: Removing missing reference to xe.rst
On Tue, Jan 16, 2024 at 05:03:31PM -0500, Rodrigo Vivi wrote:
> The file has already been deleted as the tasks were completed.
> However the index reference was missed behind.
Gentle ping on this one.
I should have mentioned here that this fixes a doc build warning:
Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
nonexisting document 'gpu/rfc/xe'
>
> Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
> Cc: Lucas De Marchi
> Signed-off-by: Rodrigo Vivi
> ---
> Documentation/gpu/rfc/index.rst | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
> index e4f7b005138d..476719771eef 100644
> --- a/Documentation/gpu/rfc/index.rst
> +++ b/Documentation/gpu/rfc/index.rst
> @@ -31,7 +31,3 @@ host such documentation:
> .. toctree::
>
> i915_vm_bind.rst
> -
> -.. toctree::
> -
> - xe.rst
> --
> 2.43.0
>
[PATCH] drm/doc/rfc: Removing missing reference to xe.rst
The file has already been deleted as the tasks were completed.
However the index reference was missed behind.
Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/index.rst | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index e4f7b005138d..476719771eef 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -31,7 +31,3 @@ host such documentation:
.. toctree::
i915_vm_bind.rst
-
-.. toctree::
-
- xe.rst
--
2.43.0
Re: [PATCH] drm/doc/rfc: Remove Xe's pre-merge plan
On Wed, Jan 10, 2024 at 02:07:38PM -0600, Lucas De Marchi wrote: > On Wed, Jan 10, 2024 at 02:04:27PM -0500, Rodrigo Vivi wrote: > > The last TODO item here that was not marked as done was > > the display portion, which came along with the pull-request. > > > > So, now that Xe is part of drm-next and it includes the > > display portion, let's entirely kill this RFC here. > > > > Cc: Lucas De Marchi > > Cc: Thomas Hellström > > Cc: Oded Gabbay > > Signed-off-by: Rodrigo Vivi > > > Acked-by: Lucas De Marchi Thanks, pushed to drm-misc-next. > > thanks > Lucas De Marchi > > > --- > > Documentation/gpu/rfc/xe.rst | 234 --- > > 1 file changed, 234 deletions(-) > > delete mode 100644 Documentation/gpu/rfc/xe.rst > > > > diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst > > deleted file mode 100644 > > index 97cf87578f97.. > > --- a/Documentation/gpu/rfc/xe.rst > > +++ /dev/null > > @@ -1,234 +0,0 @@ > > -== > > -Xe – Merge Acceptance Plan > > -== > > -Xe is a new driver for Intel GPUs that supports both integrated and > > -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). > > - > > -This document aims to establish a merge plan for the Xe, by writing down > > clear > > -pre-merge goals, in order to avoid unnecessary delays. > > - > > -Xe – Overview > > -= > > -The main motivation of Xe is to have a fresh base to work from that is > > -unencumbered by older platforms, whilst also taking the opportunity to > > -rearchitect our driver to increase sharing across the drm subsystem, both > > -leveraging and allowing us to contribute more towards other shared > > components > > -like TTM and drm/scheduler. > > - > > -This is also an opportunity to start from the beginning with a clean uAPI > > that is > > -extensible by design and already aligned with the modern userspace needs. > > For > > -this reason, the memory model is solely based on GPU Virtual Address space > > -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only > > supporting > > -explicit synchronization. With persistent mapping across the execution, the > > -userspace does not need to provide a list of all required mappings during > > each > > -submission. > > - > > -The new driver leverages a lot from i915. As for display, the intent is to > > share > > -the display code with the i915 driver so that there is maximum reuse there. > > - > > -As for the power management area, the goal is to have a much-simplified > > support > > -for the system suspend states (S-states), PCI device suspend states > > (D-states), > > -GPU/Render suspend states (R-states) and frequency management. It should > > leverage > > -as much as possible all the existent PCI-subsystem infrastructure (pm and > > -runtime_pm) and underlying firmware components such PCODE and GuC for the > > power > > -states and frequency decisions. > > - > > -Repository: > > - > > -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) > > - > > -Xe – Platforms > > -== > > -Currently, Xe is already functional and has experimental support for > > multiple > > -platforms starting from Tiger Lake, with initial support in userspace > > implemented > > -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in > > NEO > > -(for OpenCL and Level0). > > - > > -During a transition period, platforms will be supported by both Xe and > > i915. > > -However, the force_probe mechanism existent in both drivers will allow > > only one > > -official and by-default probe at a given time. > > - > > -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead > > of > > -i915, the following set of parameters need to be used: > > - > > -``` > > -i915.force_probe=!5690 xe.force_probe=5690 > > -``` > > - > > -In both drivers, the ‘.require_force_probe’ protection forces the user to > > use the > > -force_probe parameter while the driver is under development. This > > protection is > > -only removed when the support for the platform and the uAPI are stable. > > Stability > > -which needs to be demonstrated by CI results. > > - > > -In order to avoid user space regressions, i915 will continue to support > > all the > > -cur
[PATCH] drm/doc/rfc: Remove Xe's pre-merge plan
The last TODO item here that was not marked as done was the display portion, which came along with the pull-request. So, now that Xe is part of drm-next and it includes the display portion, let's entirely kill this RFC here. Cc: Lucas De Marchi Cc: Thomas Hellström Cc: Oded Gabbay Signed-off-by: Rodrigo Vivi --- Documentation/gpu/rfc/xe.rst | 234 --- 1 file changed, 234 deletions(-) delete mode 100644 Documentation/gpu/rfc/xe.rst diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst deleted file mode 100644 index 97cf87578f97.. --- a/Documentation/gpu/rfc/xe.rst +++ /dev/null @@ -1,234 +0,0 @@ -== -Xe – Merge Acceptance Plan -== -Xe is a new driver for Intel GPUs that supports both integrated and -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). - -This document aims to establish a merge plan for the Xe, by writing down clear -pre-merge goals, in order to avoid unnecessary delays. - -Xe – Overview -= -The main motivation of Xe is to have a fresh base to work from that is -unencumbered by older platforms, whilst also taking the opportunity to -rearchitect our driver to increase sharing across the drm subsystem, both -leveraging and allowing us to contribute more towards other shared components -like TTM and drm/scheduler. - -This is also an opportunity to start from the beginning with a clean uAPI that is -extensible by design and already aligned with the modern userspace needs. For -this reason, the memory model is solely based on GPU Virtual Address space -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting -explicit synchronization. With persistent mapping across the execution, the -userspace does not need to provide a list of all required mappings during each -submission. - -The new driver leverages a lot from i915. As for display, the intent is to share -the display code with the i915 driver so that there is maximum reuse there. - -As for the power management area, the goal is to have a much-simplified support -for the system suspend states (S-states), PCI device suspend states (D-states), -GPU/Render suspend states (R-states) and frequency management. It should leverage -as much as possible all the existent PCI-subsystem infrastructure (pm and -runtime_pm) and underlying firmware components such PCODE and GuC for the power -states and frequency decisions. - -Repository: - -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) - -Xe – Platforms -== -Currently, Xe is already functional and has experimental support for multiple -platforms starting from Tiger Lake, with initial support in userspace implemented -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO -(for OpenCL and Level0). - -During a transition period, platforms will be supported by both Xe and i915. -However, the force_probe mechanism existent in both drivers will allow only one -official and by-default probe at a given time. - -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of -i915, the following set of parameters need to be used: - -``` -i915.force_probe=!5690 xe.force_probe=5690 -``` - -In both drivers, the ‘.require_force_probe’ protection forces the user to use the -force_probe parameter while the driver is under development. This protection is -only removed when the support for the platform and the uAPI are stable. Stability -which needs to be demonstrated by CI results. - -In order to avoid user space regressions, i915 will continue to support all the -current platforms that are already out of this protection. Xe support will be -forever experimental and dependent on the usage of force_probe for these -platforms. - -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. - -Xe – Pre-Merge Goals - Work-in-Progress -=== - -Display integration with i915 -- -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -Xe – uAPI high level overview -= - -...Warning: To be done in follow
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote: > On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote: > > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: > > > Add the xe repo to drm-tip and the dim tools. > > > For now use the sha1 of the first drm-xe-next pull request for drm- > > > tip, > > > since that branch tip is currently adapted for our CI testing. > > > > > > Cc: Rodrigo Vivi > > > Cc: Lucas De Marchi > > > Cc: Oded Gabbay > > > Cc: daniel.vet...@ffwll.ch > > > Cc: Maarten Lankhorst > > > Cc: dim-to...@lists.freedesktop.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: intel-...@lists.freedesktop.org > > > Signed-off-by: Thomas Hellström > > > --- > > > nightly.conf | 7 +++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/nightly.conf b/nightly.conf > > > index 24126b61b797..accd3ff2cc39 100644 > > > --- a/nightly.conf > > > +++ b/nightly.conf > > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > > > https://anongit.freedesktop.org/git/drm/drm-tip > > > https://anongit.freedesktop.org/git/drm/drm-tip.git > > > " > > > +drm_tip_repos[drm-xe]=" > > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > > > +https://gitlab.freedesktop.org/drm/xe/kernel.git > > > +" > > > drm_tip_repos[drm-intel]=" > > > ssh://git.freedesktop.org/git/drm/drm-intel > > > ssh://git.freedesktop.org/git/drm-intel > > > @@ -65,14 +69,17 @@ drm_tip_config=( > > > "drmdrm-fixes" > > > "drm-misc drm-misc-fixes" > > > "drm-intel drm-intel-fixes" > > > + "drm-xe drm-xe-fixes" > > > > > > "drmdrm-next" > > > "drm-misc drm-misc-next-fixes" > > > "drm-intel drm-intel-next-fixes" > > > + "drm-xe drm-xe-next-fixes" > > > > > > "drm-misc drm-misc-next" > > > "drm-intel drm-intel-next" > > > "drm-intel drm-intel-gt-next" > > > + "drm-xe drm-xe-next b6e1b7081768" > > > > yeap, up to this commit nothing else should change, but > > then we will need an extra rebase of the rest on top of drm/drm-next. > > > > But then we need to decide where these following patches will live: > > 880277f31cc69 drm/xe/guc: define LNL FW > > 2cfc5ae1b8267 drm/xe/guc: define PVC FW > > 52383b58eb8cf mei/hdcp: Also enable for XE > > bea27d7369855 mei: gsc: add support for auxiliary device created by > > Xe driver > > fcb3410197f05 fault-inject: Include linux/types.h by default. > > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs > > > > > > Will it be the topic/core-for-CI? > > or topic/xe-extras? > > or what? > > This sounds to me like topic/core-for-CI? Or is there any drawback with > that? > > > > > Anyway, for the inclusion like this, after our CI is ready: > > Could we merge this patch already at this point, considering it will, > at least for now, only update drm-tip with our fixes? yeap, likely a good idea. Acked-by: Rodrigo Vivi But we just move the final drm-xe-next after figuring out the topic branches and the final rebases fixing the tags and the commiter's s-o-b and the fixes tags. > > Thanks, > > /Thomas > > > > > > Acked-by: Rodrigo Vivi > > > > > > > > "drm-intel topic/core-for-CI" > > > "drm-misc topic/i915-ttm" > > > -- > > > 2.42.0 > > > >
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Wed, Jan 03, 2024 at 11:59:16PM -0600, Lucas De Marchi wrote: > On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote: > > On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote: > > > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: > > > > Add the xe repo to drm-tip and the dim tools. > > > > For now use the sha1 of the first drm-xe-next pull request for drm- > > > > tip, > > > > since that branch tip is currently adapted for our CI testing. > > > > > > > > Cc: Rodrigo Vivi > > > > Cc: Lucas De Marchi > > > > Cc: Oded Gabbay > > > > Cc: daniel.vet...@ffwll.ch > > > > Cc: Maarten Lankhorst > > > > Cc: dim-to...@lists.freedesktop.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: intel-...@lists.freedesktop.org > > > > Signed-off-by: Thomas Hellström > > > > --- > > > > nightly.conf | 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/nightly.conf b/nightly.conf > > > > index 24126b61b797..accd3ff2cc39 100644 > > > > --- a/nightly.conf > > > > +++ b/nightly.conf > > > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > > > > https://anongit.freedesktop.org/git/drm/drm-tip > > > > https://anongit.freedesktop.org/git/drm/drm-tip.git > > > > " > > > > +drm_tip_repos[drm-xe]=" > > > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > > > > +https://gitlab.freedesktop.org/drm/xe/kernel.git > > > > +" > > > > drm_tip_repos[drm-intel]=" > > > > ssh://git.freedesktop.org/git/drm/drm-intel > > > > ssh://git.freedesktop.org/git/drm-intel > > > > @@ -65,14 +69,17 @@ drm_tip_config=( > > > > "drmdrm-fixes" > > > > "drm-misc drm-misc-fixes" > > > > "drm-intel drm-intel-fixes" > > > > + "drm-xe drm-xe-fixes" > > > > > > > > "drmdrm-next" > > > > "drm-misc drm-misc-next-fixes" > > > > "drm-intel drm-intel-next-fixes" > > > > + "drm-xe drm-xe-next-fixes" > > > > > > > > "drm-misc drm-misc-next" > > > > "drm-intel drm-intel-next" > > > > "drm-intel drm-intel-gt-next" > > > > + "drm-xe drm-xe-next b6e1b7081768" > > > > > > yeap, up to this commit nothing else should change, but > > > then we will need an extra rebase of the rest on top of drm/drm-next. > > > > > > But then we need to decide where these following patches will live: > > > 880277f31cc69 drm/xe/guc: define LNL FW > > > 2cfc5ae1b8267 drm/xe/guc: define PVC FW > > > 52383b58eb8cf mei/hdcp: Also enable for XE > > > bea27d7369855 mei: gsc: add support for auxiliary device created by > > > Xe driver > > > fcb3410197f05 fault-inject: Include linux/types.h by default. > > > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs > > > > > > > > > Will it be the topic/core-for-CI? > > > or topic/xe-extras? > > > or what? > > > > This sounds to me like topic/core-for-CI? Or is there any drawback with > > that? > > I think some of them are not really a "for CI". It's more like the > workflow we are adopting e.g. with guc/huc, not sending it to linux-firmware > until we are confident on what version we will start officially > supporting. yeap, I kind of agree here, but at the same time it is our way to run our CI with the firmware blobs that we need while not final, and also this was already used for i915's MTL firmware. > > This one can't go to topic/core-for-CI neither: > fcb3410197f05 fault-inject: Include linux/types.h by default. > > what it would do would be that we would not see the build error anymore, > but everyone else would (and it's not a CI-only configuration). > Unless it's merged to another branch, we shouldn't merge it. yeap. it is sad that we were ignored there. let's just drop this then. our driver is workarounding this bug anyway already. > > "52383b58eb8cf mei/hdcp: Also enable for XE" could be material for > topic/core-for-CI and "8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs" > could either be on that branch or another xe-specific one. yeap. For the MEI we probably need to ping Greg on the original submission and ask his ack so we can put that in the final drm-xe-next for good and not even include in a topic branch. for the PVC IDs, the topic branch could be okay as well. But if we end up with an exclusive branch for xe, then it is better there. > > > > > > > > > Anyway, for the inclusion like this, after our CI is ready: > > > > Could we merge this patch already at this point, considering it will, > > at least for now, only update drm-tip with our fixes? > > ack > > Lucas De Marchi > > > > > Thanks, > > > > /Thomas > > > > > > > > > > Acked-by: Rodrigo Vivi > > > > > > > > > > > "drm-intel topic/core-for-CI" > > > > "drm-misc topic/i915-ttm" > > > > -- > > > > 2.42.0 > > > > > >
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote: > Add the xe repo to drm-tip and the dim tools. > For now use the sha1 of the first drm-xe-next pull request for drm-tip, > since that branch tip is currently adapted for our CI testing. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > Cc: Oded Gabbay > Cc: daniel.vet...@ffwll.ch > Cc: Maarten Lankhorst > Cc: dim-to...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Thomas Hellström > --- > nightly.conf | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/nightly.conf b/nightly.conf > index 24126b61b797..accd3ff2cc39 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip.git > " > +drm_tip_repos[drm-xe]=" > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > +https://gitlab.freedesktop.org/drm/xe/kernel.git > +" > drm_tip_repos[drm-intel]=" > ssh://git.freedesktop.org/git/drm/drm-intel > ssh://git.freedesktop.org/git/drm-intel > @@ -65,14 +69,17 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > + "drm-xe drm-xe-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > + "drm-xe drm-xe-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > + "drm-xe drm-xe-next b6e1b7081768" yeap, up to this commit nothing else should change, but then we will need an extra rebase of the rest on top of drm/drm-next. But then we need to decide where these following patches will live: 880277f31cc69 drm/xe/guc: define LNL FW 2cfc5ae1b8267 drm/xe/guc: define PVC FW 52383b58eb8cf mei/hdcp: Also enable for XE bea27d7369855 mei: gsc: add support for auxiliary device created by Xe driver fcb3410197f05 fault-inject: Include linux/types.h by default. 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs Will it be the topic/core-for-CI? or topic/xe-extras? or what? Anyway, for the inclusion like this, after our CI is ready: Acked-by: Rodrigo Vivi > > "drm-intel topic/core-for-CI" > "drm-misc topic/i915-ttm" > -- > 2.42.0 >
[PULL] drm-xe-next-fixes
Hi Dave and Sima, Here goes the fixes that I had promised last week. With these in place we should be good now with the all yes config W=1 and different compilers. Thanks for already include that one that disables the 32-bit. I had just noticed when I was trying to cherry-pick it to the -next-fixes branch. Thanks, Rodrigo. The following changes since commit 92242716ee92d2aa3c38c736b53d8910d443566d: Merge tag 'drm-habanalabs-next-2023-12-19' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next (2023-12-22 14:52:04 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-fixes-2023-12-26 for you to fetch changes up to 315acff5196f4e2f84a2a2d093000e0c6b0b4d1c: drm/xe: Fix warning on impossible condition (2023-12-26 12:53:26 -0500) - Fix couple unfined behavior cases to calm UBSAN and clang (Matt Brost, Lucas) Lucas De Marchi (1): drm/xe: Fix warning on impossible condition Matthew Brost (1): drm/xe: Fix UBSAN splat in add_preempt_fences() drivers/gpu/drm/xe/xe_vm.c | 3 +++ drivers/gpu/drm/xe/xe_wait_user_fence.c | 1 + 2 files changed, 4 insertions(+)
Re: [PATCH 4/4] drm/i915/perf: reconcile Excess struct member kernel-doc warnings
On Wed, Dec 20, 2023 at 07:20:29PM -0800, Randy Dunlap wrote:
> Document nested struct members with full names as described in
> Documentation/doc-guide/kernel-doc.rst.
>
> i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description
> in 'i915_perf_stream'
> i915_perf_types.h:341: warning: Excess struct member 'head' description in
> 'i915_perf_stream'
> i915_perf_types.h:341: warning: Excess struct member 'tail' description in
> 'i915_perf_stream'
> 3 warnings as Errors
>
> Signed-off-by: Randy Dunlap
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: intel-...@lists.freedesktop.org
> Cc: Jonathan Corbet
> Cc: dri-devel@lists.freedesktop.org
for the series:
Reviewed-by: Rodrigo Vivi
I'm afraid patchwork was down when you sent this out.
Could you please rebase and resend? Just to ensure
our CI doesn't complain and then we push it.
Thanks,
Rodrigo.
> ---
> drivers/gpu/drm/i915/i915_perf_types.h |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff -- a/drivers/gpu/drm/i915/i915_perf_types.h
> b/drivers/gpu/drm/i915/i915_perf_types.h
> --- a/drivers/gpu/drm/i915/i915_perf_types.h
> +++ b/drivers/gpu/drm/i915/i915_perf_types.h
> @@ -291,7 +291,8 @@ struct i915_perf_stream {
> int size_exponent;
>
> /**
> - * @ptr_lock: Locks reads and writes to all head/tail state
> + * @oa_buffer.ptr_lock: Locks reads and writes to all
> + * head/tail state
>*
>* Consider: the head and tail pointer state needs to be read
>* consistently from a hrtimer callback (atomic context) and
> @@ -313,7 +314,8 @@ struct i915_perf_stream {
> spinlock_t ptr_lock;
>
> /**
> - * @head: Although we can always read back the head pointer
> register,
> + * @oa_buffer.head: Although we can always read back
> + * the head pointer register,
>* we prefer to avoid trusting the HW state, just to avoid any
>* risk that some hardware condition could * somehow bump the
>* head pointer unpredictably and cause us to forward the wrong
> @@ -322,7 +324,8 @@ struct i915_perf_stream {
> u32 head;
>
> /**
> - * @tail: The last verified tail that can be read by userspace.
> + * @oa_buffer.tail: The last verified tail that can be
> + * read by userspace.
>*/
> u32 tail;
> } oa_buffer;
Re: [PATCH v8 2/2] drm/i915/guc: Close deregister-context race against CT-loss
On Wed, Dec 20, 2023 at 11:08:59PM +, Teres Alexis, Alan Previn wrote: > On Wed, 2023-12-13 at 16:23 -0500, Vivi, Rodrigo wrote: > > On Tue, Dec 12, 2023 at 08:57:16AM -0800, Alan Previn wrote: > > > If we are at the end of suspend or very early in resume > > > its possible an async fence signal (via rcu_call) is triggered > > > to free_engines which could lead us to the execution of > > > the context destruction worker (after a prior worker flush). > alan:snip > > > > > Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_- > > > contexts if guc_lrc_desc_unpin fails due to CT send falure. > > > When unrolling, keep the context in the GuC's destroy-list so > > > it can get picked up on the next destroy worker invocation > > > (if suspend aborted) or get fully purged as part of a GuC > > > sanitization (end of suspend) or a reset flow. > > > > > > Signed-off-by: Alan Previn > > > Signed-off-by: Anshuman Gupta > > > Tested-by: Mousumi Jana > > > Acked-by: Daniele Ceraolo Spurio > > > > Thanks for all the explanations, patience and great work! > > > > Reviewed-by: Rodrigo Vivi > > alan: Thanks Rodrigo for the RB last week, just quick update: > > I've cant reproduce the BAT failures that seem to be intermittent > on platform and test - however, a noticable number of failures > do keep occuring on i915_selftest @live @requests where the > last test leaked a wakeref and the failing test hangs waiting > for gt to idle before starting its test. > > i have to debug this further although from code inspection > is unrelated to the patches in this series. > Hopefully its a different issue. Yeap, likely not related. Anyway, I'm sorry for not merging this sooner. Could you please send a rebased version? This on is not applying cleanly anymore.
Re: [PATCH 1/6] drm/xe: Disable 32bits build
On Thu, Dec 21, 2023 at 02:28:04PM -0800, Lucas De Marchi wrote: > Add a dependency on CONFIG_64BIT since currently the xe driver doesn't > build on 32bits. It may be enabled again after all the issues are fixed. > > Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/xe/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig > index 5b3da06e7ba3..a53b0fdc15a7 100644 > --- a/drivers/gpu/drm/xe/Kconfig > +++ b/drivers/gpu/drm/xe/Kconfig > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > config DRM_XE > tristate "Intel Xe Graphics" > - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) > + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT > select INTERVAL_TREE > # we need shmfs for the swappable backing store, and in particular > # the shmem_readpage() which depends upon tmpfs > -- > 2.40.1 >
[PULL] drm-xe-next v4
rly and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity Riana Tauro (5): drm/xe: Fix overflow in vram manager drm/xe/guc_pc: Reorder forcewake and xe_pm_runtime calls drm/xe: Fix GT looping for standalone media drm/xe: add a new sysfs directory for gtidle properties drm/xe: remove gucrc disable from suspend path Rodrigo Vivi (66): drm/xe: Implement a local xe_mmio_wait32 drm/xe: Stop using i915's range_overflows_t macro. drm/xe: Let's return last value read on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_CONFIG_FLAGS_USE_GUC drm/xe: Invert guc vs execlists parameters and info. drm/xe: Fix an invalid locking wait context bug drm/xe: Inv
[PULL] drm-xe-next v3
drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity Riana Tauro (5): drm/xe: Fix overflow in vram manager drm/xe/guc_pc: Reorder forcewake and xe_pm_runtime calls drm/xe: Fix GT looping for standalone media drm/xe: add a new sysfs directory for gtidle properties drm/xe: remove gucrc disable from suspend path Rodrigo Vivi (66): drm/xe: Implement a local xe_mmio_wait32 drm/xe: Stop using i915's range_overflows_t macro. drm/xe: Let's return last value read on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_CONFIG_FLAGS_USE_GUC drm/xe: Invert guc vs execlists parameters and info. drm/xe: Fix an invalid locking wait context bug drm/xe: Invert mask and val in xe_mmio_wait32. drm/xe: Only set PCI d3cold_allowed when we are really allowing. drm/xe: Move d3cold_allowed decision all together.
[PULL] drm-xe-next v2
tside of MMIO setup drm/xe: Move xe_mmio_probe_tiles outside of MMIO setup drm/xe: Split xe_info_init drm/xe: Introduce xe_tile_init_early and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity Riana Tauro (5): drm/xe: Fix overflow in vram manager drm/xe/guc_pc: Reorder forcewake and xe_pm_runtime calls drm/xe: Fix GT looping for standalone media drm/xe: add a new sysfs directory for gtidle properties drm/xe: remove gucrc disable from suspend path Rodrigo Vivi (66): drm/xe: Implement a local xe_mmio_wait32 drm/xe: Stop using i915's range_overflows_t macro. drm/xe: Let's return last value read on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_C
[PULL] drm-intel-next
Hi Dave and Sima, Here goes our latest drm-intel-next pull-request towards 6.8. drm-intel-next-2023-12-18: - Drop pointless null checks and fix a scaler bug (Ville) - Meteor Lake display fixes and clean-ups (RK, Jani, Andrzej, Mika, Imre) - Clean-up around flip done IRQ (Ville) - Fix eDP Meteor Lake bug (Jani) - Bigjoiner fixes (Ankit, Ville) - Cdclk/voltage_level cleanups and fixes (Ville) - DMC event stuff (Ville) - Remove dead code around intel_atomic_helper->free_list (Jouni) Thanks, Rodrigo. The following changes since commit 10690b8a49bceafb1badf0ad91842a359e796d8b: drm/i915/display: Add intel_fb_bo_framebuffer_fini (2023-12-07 17:31:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-12-18 for you to fetch changes up to 716c3cf21784479a1934b670ec67f320cbb5d308: drm/i915/display: Remove dead code around intel_atomic_helper->free_list (2023-12-18 13:37:01 +0200) - Drop pointless null checks and fix a scaler bug (Ville) - Meteor Lake display fixes and clean-ups (RK, Jani, Andrzej, Mika, Imre) - Clean-up around flip done IRQ (Ville) - Fix eDP Meteor Lake bug (Jani) - Bigjoiner fixes (Ankit, Ville) - Cdclk/voltage_level cleanups and fixes (Ville) - DMC event stuff (Ville) - Remove dead code around intel_atomic_helper->free_list (Jouni) Andrzej Hajda (1): drm/i915/display: do not use cursor size reduction on MTL Ankit Nautiyal (1): drm/i915/display: Get bigjoiner config before dsc config during readout Imre Deak (1): drm/i915/mtl: Fix HDMI/DP PLL clock selection Jani Nikula (1): drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select Jouni Högander (1): drm/i915/display: Remove dead code around intel_atomic_helper->free_list Mika Kahola (1): drm/i915/display: Wait for PHY readiness not needed for disabling sequence Radhakrishna Sripada (3): drm/i915/mtl: Use port clock compatible numbers for C20 phy drm/i915/mtl: Remove misleading "clock" field from C20 pll_state drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state Ville Syrjälä (24): drm/i915: Fix remapped stride with CCS on ADL+ drm/i915: Fix intel_atomic_setup_scalers() plane_state handling drm/i915: Streamline intel_dsc_pps_read() drm/i915: Drop redundant NULL check drm/i915: Drop crtc NULL check from intel_crtc_active() drm/i915: Drop NULL fb check from intel_fb_uses_dpt() drm/i915: Drop redunant null check from intel_get_frame_time_us() drm/i915: s/cstate/crtc_state/ in intel_get_frame_time_us() drm/i915/tv: Drop redundant null checks drm/i915: Stop accessing crtc->state from the flip done irq drm/i915: Drop irqsave/restore for flip_done_handler() drm/i915: Reject async flips with bigjoiner drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values drm/i915/cdclk: Give the squash waveform length a name drm/i915/cdclk: Remove the assumption that cdclk divider==2 when using squashing drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables drm/i915/mtl: Fix voltage_level for cdclk==480MHz drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants drm/i915/mtl: Calculate the correct voltage level from port_clock drm/i915: Simplify intel_ddi_compute_min_voltage_level() drm/i915/dmc: Don't enable any pipe DMC events drm/i915/dmc: Also disable the flip queue event on TGL main DMC drm/i915/dmc: Also disable HRR event on TGL/ADLS main DMC drm/i915/dmc: Print out the DMC mmio register list at fw load time drivers/gpu/drm/i915/display/i9xx_wm.c | 2 +- drivers/gpu/drm/i915/display/intel_bios.c | 3 +- drivers/gpu/drm/i915/display/intel_cdclk.c | 111 ++-- drivers/gpu/drm/i915/display/intel_crtc.c | 9 +- drivers/gpu/drm/i915/display/intel_cx0_phy.c | 82 +--- drivers/gpu/drm/i915/display/intel_ddi.c | 48 +-- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 33 ++--- drivers/gpu/drm/i915/display/intel_display_core.h | 6 - .../gpu/drm/i915/display/intel_display_device.h| 2 +- .../gpu/drm/i915/display/intel_display_driver.c| 7 - drivers/gpu/drm/i915/display/intel_display_irq.c | 15 +-- drivers/gpu/drm/i915/display/intel_display_types.h | 6 +- drivers/gpu/drm/i915/display/intel_dmc.c | 147 ++--- drivers/gpu/drm/i915/display/intel_dmc_regs.h | 1 + .../gpu/drm/i915/display/intel_dp_link_training.c | 31 +++-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_fb.c| 18 ++- drivers/gpu/drm/i915/display/intel_psr.c |
[PULL] drm-xe-next
nfig drm/xe: Introduce SR-IOV logging macros drm/xe/pf: Introduce Local Memory Translation Table drm/xe/kunit: Enable CONFIG_PCI_IOV in .kunitconfig drm/xe/kunit: Add test for LMTT operations Michał Winiarski (21): drm/xe: Fix uninitialized variables drm/xe: Fix check for platform without geometry pipeline drm/xe: Fix header guard warning drm/xe: Skip calling drm_dev_put on probe error drm/xe: Use managed pci_enable_device drm/xe/irq: Don't call pci_free_irq_vectors drm/xe: Move xe_set_dma_info outside of MMIO setup drm/xe: Move xe_mmio_probe_tiles outside of MMIO setup drm/xe: Split xe_info_init drm/xe: Introduce xe_tile_init_early and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity Riana Tauro (5): drm/xe: Fix overflow in vram manager drm/xe/guc_pc: Reorder forcewake and xe_pm_runtime calls drm/xe: Fix GT looping for standalone media drm/xe: add a new sysfs directory for gtidle properties drm/xe: remove gucrc disable from suspend path Rodrigo Vivi (65): drm/xe: Implement a local xe_mmio_wait32 drm/xe: Stop using i915's range_overflows_t macro. drm/xe: Let's return last value read on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB
Re: [PATCH topic/core-for-CI] perf: Fix perf_event_validate_size() lockdep splat
On Fri, Dec 15, 2023 at 08:22:17AM -0800, Lucas De Marchi wrote:
> From: Mark Rutland
>
> When lockdep is enabled, the for_each_sibling_event(sibling, event)
> macro checks that event->ctx->mutex is held. When creating a new group
> leader event, we call perf_event_validate_size() on a partially
> initialized event where event->ctx is NULL, and so when
> for_each_sibling_event() attempts to check event->ctx->mutex, we get a
> splat, as reported by Lucas De Marchi:
>
> WARNING: CPU: 8 PID: 1471 at kernel/events/core.c:1950
> __do_sys_perf_event_open+0xf37/0x1080
>
> This only happens for a new event which is its own group_leader, and in
> this case there cannot be any sibling events. Thus it's safe to skip the
> check for siblings, which avoids having to make invasive and ugly
> changes to for_each_sibling_event().
>
> Avoid the splat by bailing out early when the new event is its own
> group_leader.
>
> Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")
> Closes:
> https://lore.kernel.org/lkml/20231214000620.3081018-1-lucas.demar...@intel.com/
> Closes: https://lore.kernel.org/lkml/zxpm6gq%2fd59jg...@xpf.sh.intel.com/
> Reported-by: Lucas De Marchi
> Reported-by: Pengfei Xu
> Signed-off-by: Mark Rutland
> Signed-off-by: Peter Zijlstra (Intel)
> Link: https://lkml.kernel.org/r/20231215112450.3972309-1-mark.rutl...@arm.com
> [ cherry pick from tip/urgent heading to 6.7-rc6 ]
> Signed-off-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
> ---
> kernel/events/core.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index acfc5a569818..a64165af45c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1947,6 +1947,16 @@ static bool perf_event_validate_size(struct perf_event
> *event)
> group_leader->nr_siblings + 1) > 16*1024)
> return false;
>
> + /*
> + * When creating a new group leader, group_leader->ctx is initialized
> + * after the size has been validated, but we cannot safely use
> + * for_each_sibling_event() until group_leader->ctx is set. A new group
> + * leader cannot have any siblings yet, so we can safely skip checking
> + * the non-existent siblings.
> + */
> + if (event == group_leader)
> + return true;
> +
> for_each_sibling_event(sibling, group_leader) {
> if (__perf_event_read_size(sibling->attr.read_format,
> group_leader->nr_siblings + 1) >
> 16*1024)
> --
> 2.40.1
>
Re: [PATCH v8 2/2] drm/i915/guc: Close deregister-context race against CT-loss
On Tue, Dec 12, 2023 at 08:57:16AM -0800, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal (via rcu_call) is triggered
> to free_engines which could lead us to the execution of
> the context destruction worker (after a prior worker flush).
>
> Thus, when suspending, insert rcu_barriers at the start
> of i915_gem_suspend (part of driver's suspend prepare) and
> again in i915_gem_suspend_late so that all such cases have
> completed and context destruction list isn't missing anything.
>
> In destroyed_worker_func, close the race against CT-loss
> by checking that CT is enabled before calling into
> deregister_destroyed_contexts.
>
> Based on testing, guc_lrc_desc_unpin may still race and fail
> as we traverse the GuC's context-destroy list because the
> CT could be disabled right before calling GuC's CT send function.
>
> We've witnessed this race condition once every ~6000-8000
> suspend-resume cycles while ensuring workloads that render
> something onscreen is continuously started just before
> we suspend (and the workload is small enough to complete
> and trigger the queued engine/context free-up either very
> late in suspend or very early in resume).
>
> In such a case, we need to unroll the entire process because
> guc-lrc-unpin takes a gt wakeref which only gets released in
> the G2H IRQ reply that never comes through in this corner
> case. Without the unroll, the taken wakeref is leaked and will
> cascade into a kernel hang later at the tail end of suspend in
> this function:
>
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
>
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
> contexts if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so
> it can get picked up on the next destroy worker invocation
> (if suspend aborted) or get fully purged as part of a GuC
> sanitization (end of suspend) or a reset flow.
>
> Signed-off-by: Alan Previn
> Signed-off-by: Anshuman Gupta
> Tested-by: Mousumi Jana
> Acked-by: Daniele Ceraolo Spurio
Thanks for all the explanations, patience and great work!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 73 +--
> 2 files changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
> GEM_TRACE("%s\n", dev_name(i915->drm.dev));
>
> intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> + * On rare occasions, we've observed the fence completion triggers
> + * free_engines asynchronously via rcu_call. Ensure those are done.
> + * This path is only called on suspend, so it's an acceptable cost.
> + */
> + rcu_barrier();
> +
> flush_workqueue(i915->wq);
>
> /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
>* machine in an unusable condition.
>*/
>
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
> for_each_gt(gt, i915, i)
> intel_gt_suspend_late(gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 9c64ae0766cc..cae637fc3ead 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -236,6 +236,13 @@ set_context_destroyed(struct intel_context *ce)
> ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
> }
>
> +static inline void
> +clr_context_destroyed(struct intel_context *ce)
> +{
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
> +}
> +
> static inline bool context_pending_disable(struct intel_context *ce)
> {
> return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
> @@ -613,6 +620,8 @@ static int guc_submission_send_busy_loop(struct intel_guc
> *guc,
>u32 g2h_len_dw,
>bool loop)
> {
> + int ret;
> +
> /*
>* We always loop when a send requires a
[PATCH] MAINTAINERS: Updates to Intel DRM
Introduce the Maintainers of the new drm/xe driver for upcoming Intel GPUs. Since it has a shared display with drm/i915, let's also create a dedicated block to group display related files. But without any substantial change to the i915 side. The display patches will continue to flow through i915 from drm-intel-next branches for now. Acked-by: Jani Nikula Acked-by: Joonas Lahtinen Acked-by: Tvrtko Ursulin Acked-by: Lucas De Marchi Acked-by: Oded Gabbay Acked-by: Thomas Hellström Signed-off-by: Rodrigo Vivi --- MAINTAINERS | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4b46b3db022..8b5e3c27bca6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10640,7 +10640,17 @@ L: linux-ker...@vger.kernel.org S: Supported F: arch/x86/include/asm/intel-family.h -INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) +INTEL DRM DISPLAY FOR XE AND I915 DRIVERS +M: Jani Nikula +M: Rodrigo Vivi +L: intel-...@lists.freedesktop.org +L: intel...@lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/i915/display/ +F: drivers/gpu/drm/xe/display/ +F: drivers/gpu/drm/xe/compat-i915-headers + +INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, Moorestown and derivative) M: Jani Nikula M: Joonas Lahtinen M: Rodrigo Vivi @@ -10659,6 +10669,23 @@ F: drivers/gpu/drm/i915/ F: include/drm/i915* F: include/uapi/drm/i915_drm.h +INTEL DRM XE DRIVER (Lunar Lake and newer) +M: Lucas De Marchi +M: Oded Gabbay +M: Thomas Hellström +L: intel...@lists.freedesktop.org +S: Supported +W: https://drm.pages.freedesktop.org/intel-docs/ +Q: http://patchwork.freedesktop.org/project/intel-xe/ +B: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues +C: irc://irc.oftc.net/xe +T: git https://gitlab.freedesktop.org/drm/xe/kernel.git +F: Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon +F: Documentation/gpu/xe/ +F: drivers/gpu/drm/xe/ +F: include/drm/xe* +F: include/uapi/drm/xe_drm.h + INTEL ETHERNET DRIVERS M: Jesse Brandeburg M: Tony Nguyen -- 2.43.0
[PATCH 11/13] drm/sched: Reverse run-queue priority enumeration
From: Luben Tuikov
Reverse run-queue priority enumeration such that the higest priority is now 0,
and for each consecutive integer the prioirty diminishes.
Run-queues correspond to priorities. To an external observer a scheduler
created with a single run-queue, and another created with
DRM_SCHED_PRIORITY_COUNT number of run-queues, should always schedule
sched->sched_rq[0] with the same "priority", as that index run-queue exists in
both schedulers, i.e. a scheduler with one run-queue or many. This patch makes
it so.
In other words, the "priority" of sched->sched_rq[n], n >= 0, is the same for
any scheduler created with any allowable number of run-queues (priorities), 0
to DRM_SCHED_PRIORITY_COUNT.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20231124052752.6915-6-ltuiko...@gmail.com
(cherry picked from commit 38f922a563aac3148ac73e73689805917f034cb5)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 5 +++--
drivers/gpu/drm/scheduler/sched_main.c | 15 +++
include/drm/gpu_scheduler.h | 6 +++---
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 1a25931607c5..71a5cf37b472 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index eb0c97433e5f..2bfcb222e353 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_LOW -
DRM_SCHED_PRIORITY_HIGH)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index dd2b8f777f51..3c4f5a392b06 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -82,13 +82,14 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
pr_warn("%s: called with uninitialized scheduler\n", __func__);
} else if (num_sched_list) {
/* The "priority" of an entity cannot exceed the number of
run-queues of a
-* scheduler. Protect against num_rqs being 0, by converting to
signed.
+* scheduler. Protect against num_rqs being 0, by converting to
signed. Choose
+* the lowest priority available.
*/
if (entity->priority >= sched_list[0]->num_rqs) {
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_LOW);
+(s32)
DRM_SCHED_PRIORITY_KERNEL);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b6d7bc49ff6e..682aebe96db7 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1051,8 +1051,9 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
struct drm_sched_entity *entity;
int i;
- /* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ /* Start with the highest priority.
+*/
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
