Re: FYI: drm-intel repo moved to fd.o GitLab
Cc'ing drm and drm-intel maintainers too. And a few more details below. On Tue, May 21, 2024 at 02:56:22PM GMT, Knop, Ryszard wrote: Hello, As of today, we've moved the drm-intel repository (upstream for drivers/gpu/drm/i915) to a new location: Previously: https://cgit.freedesktop.org/drm-intel Moved to: https://gitlab.freedesktop.org/drm/i915/kernel For those using dim, it should ask you to migrate your remote automatically on your next branch update. By default it will use the ssh protocol. If you don't have your ssh key in gitlab already, you can follow https://docs.gitlab.com/ee/user/ssh.html#add-an-ssh-key-to-your-gitlab-account to add it. New server has no git:// protocol, so anyone using it is advised to move to https:// instead. The old repo is now a read-only mirror of the GitLab-hosted one. Relevant documentation and links were updated. Thanks to bentiss, mripard and demarchi for help with the move! and thank you for preparing all the patches to the different repos. Lucas De Marchi Ryszard
Re: [PATCH] nightly.conf: Update drm-intel URLs, add missing bare ssh drm-xe URL
On Wed, Apr 24, 2024 at 01:32:19PM GMT, Ryszard Knop wrote: - Switch drm-intel URLs to the new GitLab location. - Add a short SSH link for drm-xe for completeness with other blocks. - Add a missing tab in drm_tip_config for column alignment. Signed-off-by: Ryszard Knop Applied, thanks Lucas De Marchi
Re: [PATCH 1/2] drm/xe/display: remove unused xe->enabled_irq_mask
On Mon, May 13, 2024 at 03:10:29PM GMT, Jani Nikula wrote:
On Fri, 10 May 2024, Jani Nikula wrote:
The xe->enabled_irq_mask member has never been used for anything.
Signed-off-by: Jani Nikula
Lucas, ack for merging these two via drm-intel-next? Even though these
touch struct xe_device, I presume any further cleanups touching the
surrounding context would have a bigger footprint in drm-intel-next.
Acked-by: Lucas De Marchi
for both patches
thanks,
Lucas De Marchi
BR,
Jani.
---
drivers/gpu/drm/xe/display/xe_display.c | 1 -
drivers/gpu/drm/xe/xe_device_types.h| 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index 0de0566e5b39..fbe2c2eddea9 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -97,7 +97,6 @@ int xe_display_create(struct xe_device *xe)
xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
drmm_mutex_init(>drm, >sb_lock);
- xe->enabled_irq_mask = ~0;
return drmm_add_action_or_reset(>drm, display_destroy, NULL);
}
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index 906b98fb973b..b78223e3baab 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -517,8 +517,6 @@ struct xe_device {
/* only to allow build, not used functionally */
u32 irq_mask;
- u32 enabled_irq_mask;
-
struct intel_uncore {
spinlock_t lock;
} uncore;
--
Jani Nikula, Intel
Re: [PATCH 0/9] drm/i915: Plane fb refactoring
On Fri, May 10, 2024 at 07:55:15PM GMT, Ville Syrjälä wrote: On Mon, May 06, 2024 at 03:57:09PM +0300, Ville Syrjala wrote: From: Ville Syrjälä A bit of cleanup/refactoring around plane fb stuff. This is mainly prep work for a slightly bigger rework of alignment handling. Ville Syrjälä (9): drm/i915: Split gen2 vs. gen3 .max_stride() drm/i915: Clean up skl+ plane stride limits drm/i915: Drop 'uses_fence' parameter from intel_pin_fb_obj_dpt() drm/i915: Extract intel_plane_needs_physical() drm/i915: Polish types in fb calculations Pushed up to here. Thanks for the review. drm/i915: Constify 'fb' in during pinning drm/i915: Change intel_fbdev_fb_alloc() reuturn type drm/i915: Cleanup fbdev fb setup drm/i915: Rename the fb pinning functions to indicate the address space Some of the rest touch xe as well. Lucas, can you toss me an ack to merge via drm-intel-next? Acked-by: Lucas De Marchi thanks Lucas De Marchi
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9. thanks Lucas De Marchi drm-xe-fixes-2024-05-09: - Fix use zero-length element array - Move more from system wq to ordered private wq - Do not ignore return for drmm_mutex_init 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://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-05-09 for you to fetch changes up to c002bfe644a29ba600c571f2abba13a155a12dcd: drm/xe: Use ordered WQ for G2H handler (2024-05-09 09:41:27 -0500) - Fix use zero-length element array - Move more from system wq to ordered private wq - Do not ignore return for drmm_mutex_init Daniele Ceraolo Spurio (1): drm/xe/guc: Check error code when initializing the CT mutex Lucas De Marchi (1): drm/xe/ads: Use flexible-array Matthew Brost (1): drm/xe: Use ordered WQ for G2H handler drivers/gpu/drm/xe/xe_guc_ads.c | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 10 +- drivers/gpu/drm/xe/xe_guc_ct.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct_types.h | 2 ++ 4 files changed, 13 insertions(+), 3 deletions(-)
Re: [PATCH] drm/xe: Nuke xe's copy of intel_fbdev_fb.h
On Wed, May 08, 2024 at 10:52:54PM GMT, Ville Syrjälä wrote: On Tue, May 07, 2024 at 11:53:40AM +0300, Jani Nikula wrote: On Mon, 06 May 2024, Ville Syrjala wrote: > From: Ville Syrjälä > > For some reason xe and i915 each have an identical (fortunately) > copy of intel_fbdev_fb.h. The xe copy actually only gets included > by xe's intel_fbdev_fb.c, and the i915 copy by everyone else, > include intel_fbdev.c which is the actual caller of the > functions declared in the header. > > This means the xe and i915 headers are free to define/declare > completely incompatible things and the build would still succeed > as long as the symbol names match. > > That is not a good thing, so let's nuke xe's copy of the header > so that everyone will use the same header, and be forced to > agree on the same API/ABI. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula Thanks. I was going to push this to drm-xe-next, but I should actually push it to drm-intel-next since I'll be massaging this stuff there. xe maintainers, ack for merging via drm-intel-next? Acked-by: Lucas De Marchi Lucas De Marchi
Re: [PATCH v3 17/19] drm/xe/device: implement transient flush
On Tue, Apr 30, 2024 at 10:28:48AM GMT, Radhakrishna Sripada wrote:
From: Nirmoy Das
Display surfaces can be tagged as transient by mapping it using one of
the various L3:XD PAT index modes on Xe2. The expectation is that KMD
needs to request transient data flush at the start of flip sequence to
ensure all transient data in L3 cache is flushed to memory. Add a
routine for this which we can then call from the display code.
v2: rebase(RK)
Signed-off-by: Nirmoy Das
Co-developed-by: Matthew Auld
Signed-off-by: Matthew Auld
Signed-off-by: Balasubramani Vivekanandan
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
Acked-by: Lucas De Marchi
for merging this through drm-intel-next.
Lucas De Marchi
---
drivers/gpu/drm/xe/regs/xe_gt_regs.h | 3 ++
drivers/gpu/drm/xe/xe_device.c | 49
drivers/gpu/drm/xe/xe_device.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
index 83847f2da72a..b4f1a3264e8c 100644
--- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
+++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
@@ -334,6 +334,9 @@
#define XE2LPM_L3SQCREG5XE_REG_MCR(0xb658)
+#define XE2_TDF_CTRL XE_REG(0xb418)
+#define TRANSIENT_FLUSH_REQUEST REG_BIT(0)
+
#define XEHP_MERT_MOD_CTRL XE_REG_MCR(0xcf28)
#define RENDER_MOD_CTRL XE_REG_MCR(0xcf2c)
#define COMP_MOD_CTRL XE_REG_MCR(0xcf30)
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index b61f8356e23e..05c28314b748 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -719,6 +719,55 @@ void xe_device_wmb(struct xe_device *xe)
xe_mmio_write32(gt, SOFTWARE_FLAGS_SPR33, 0);
}
+/**
+ * xe_device_td_flush() - Flush transient L3 cache entries
+ * @xe: The device
+ *
+ * Display engine has direct access to memory and is never coherent with L3/L4
+ * caches (or CPU caches), however KMD is responsible for specifically flushing
+ * transient L3 GPU cache entries prior to the flip sequence to ensure scanout
+ * can happen from such a surface without seeing corruption.
+ *
+ * Display surfaces can be tagged as transient by mapping it using one of the
+ * various L3:XD PAT index modes on Xe2.
+ *
+ * Note: On non-discrete xe2 platforms, like LNL, the entire L3 cache is
flushed
+ * at the end of each submission via PIPE_CONTROL for compute/render, since SA
+ * Media is not coherent with L3 and we want to support render-vs-media
+ * usescases. For other engines like copy/blt the HW internally forces uncached
+ * behaviour, hence why we can skip the TDF on such platforms.
+ */
+void xe_device_td_flush(struct xe_device *xe)
+{
+ struct xe_gt *gt;
+ u8 id;
+
+ if (!IS_DGFX(xe) || GRAPHICS_VER(xe) < 20)
+ return;
+
+ for_each_gt(gt, xe, id) {
+ if (xe_gt_is_media_type(gt))
+ continue;
+
+ if (xe_force_wake_get(gt_to_fw(gt), XE_FW_GT))
+ return;
+
+ xe_mmio_write32(gt, XE2_TDF_CTRL, TRANSIENT_FLUSH_REQUEST);
+ /*
+* FIXME: We can likely do better here with our choice of
+* timeout. Currently we just assume the worst case, i.e. 150us,
+* which is believed to be sufficient to cover the worst case
+* scenario on current platforms if all cache entries are
+* transient and need to be flushed..
+*/
+ if (xe_mmio_wait32(gt, XE2_TDF_CTRL, TRANSIENT_FLUSH_REQUEST, 0,
+ 150, NULL, false))
+ xe_gt_err_once(gt, "TD flush timeout\n");
+
+ xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
+ }
+}
+
u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size)
{
return xe_device_has_flat_ccs(xe) ?
diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
index 82317580f4bf..f2a78b6a9bff 100644
--- a/drivers/gpu/drm/xe/xe_device.h
+++ b/drivers/gpu/drm/xe/xe_device.h
@@ -173,5 +173,6 @@ static inline bool xe_device_wedged(struct xe_device *xe)
}
void xe_device_declare_wedged(struct xe_device *xe);
+void xe_device_td_flush(struct xe_device *xe);
#endif
--
2.34.1
Re: [PATCH v3 16/19] drm/xe/gt_print: add xe_gt_err_once()
On Tue, Apr 30, 2024 at 10:28:47AM GMT, Radhakrishna Sripada wrote: From: Matthew Auld Needed in an upcoming patch, where we want GT level print, but only which to trigger once to avoid flooding dmesg. Signed-off-by: Matthew Auld Signed-off-by: Balasubramani Vivekanandan Reviewed-by: Nirmoy Das Signed-off-by: Radhakrishna Sripada Acked-by: Lucas De Marchi for merging this through drm-intel-next since right now only display needs it. Lucas De Marchi --- drivers/gpu/drm/xe/xe_gt_printk.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_gt_printk.h b/drivers/gpu/drm/xe/xe_gt_printk.h index c2b004d3f48e..d6228baaff1e 100644 --- a/drivers/gpu/drm/xe/xe_gt_printk.h +++ b/drivers/gpu/drm/xe/xe_gt_printk.h @@ -13,6 +13,9 @@ #define xe_gt_printk(_gt, _level, _fmt, ...) \ drm_##_level(_to_xe(_gt)->drm, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__) +#define xe_gt_err_once(_gt, _fmt, ...) \ + xe_gt_printk((_gt), err_once, _fmt, ##__VA_ARGS__) + #define xe_gt_err(_gt, _fmt, ...) \ xe_gt_printk((_gt), err, _fmt, ##__VA_ARGS__) -- 2.34.1
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc7. Two important fixes: one avoiding a use-after-free in the rebind worker and the other to make display work in ADL-N. thanks Lucas De Marchi drm-xe-fixes-2024-05-02: - Fix UAF on rebind worker - Fix ADL-N display integration The following changes since commit e67572cd2204894179d89bd7b984072f19313b03: Linux 6.9-rc6 (2024-04-28 13:47:24 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-05-02 for you to fetch changes up to df04b152fca2d46e75fbb74ed79299bc420bc9e6: drm/xe/display: Fix ADL-N detection (2024-05-02 11:11:01 -0500) - Fix UAF on rebind worker - Fix ADL-N display integration Lucas De Marchi (1): drm/xe/display: Fix ADL-N detection Matthew Auld (1): drm/xe/vm: prevent UAF in rebind_work_func() drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h | 3 ++- drivers/gpu/drm/xe/xe_vm.c| 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-)
Re: [PATCH v3 18/19] drm/i915/display: perform transient flush
+Jani
On Tue, Apr 30, 2024 at 10:28:49AM GMT, Radhakrishna Sripada wrote:
From: Matthew Auld
Perform manual transient cache flush prior to flip and at the end of
frontbuffer_flush. This is needed to ensure display engine doesn't see
garbage if the surface is L3:XD dirty.
Testcase: igt@xe-pat@display-vs-wb-transient
Signed-off-by: Matthew Auld
Signed-off-by: Balasubramani Vivekanandan
Acked-by: Nirmoy Das
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
.../gpu/drm/i915/display/intel_frontbuffer.c | 2 ++
drivers/gpu/drm/i915/display/intel_tdf.h | 25 +++
drivers/gpu/drm/xe/Makefile | 3 ++-
drivers/gpu/drm/xe/display/xe_tdf.c | 13 ++
5 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_tdf.h
create mode 100644 drivers/gpu/drm/xe/display/xe_tdf.c
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 00e583fc2a8c..294539b4ca99 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -109,6 +109,7 @@
#include "intel_sdvo.h"
#include "intel_snps_phy.h"
#include "intel_tc.h"
+#include "intel_tdf.h"
#include "intel_tv.h"
#include "intel_vblank.h"
#include "intel_vdsc.h"
@@ -7225,6 +7226,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_atomic_commit_fence_wait(state);
+ intel_td_flush(dev_priv);
+
drm_atomic_helper_wait_for_dependencies(>base);
drm_dp_mst_atomic_wait_for_dependencies(>base);
intel_atomic_global_state_wait_for_dependencies(state);
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 2ea37c0414a9..4923c340a0b6 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -65,6 +65,7 @@
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
#include "intel_psr.h"
+#include "intel_tdf.h"
/**
* frontbuffer_flush - flush frontbuffer
@@ -93,6 +94,7 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
trace_intel_frontbuffer_flush(i915, frontbuffer_bits, origin);
might_sleep();
+ intel_td_flush(i915);
intel_drrs_flush(i915, frontbuffer_bits);
intel_psr_flush(i915, frontbuffer_bits, origin);
intel_fbc_flush(i915, frontbuffer_bits, origin);
diff --git a/drivers/gpu/drm/i915/display/intel_tdf.h
b/drivers/gpu/drm/i915/display/intel_tdf.h
new file mode 100644
index ..353cde21f6c2
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_tdf.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2024 Intel Corporation
+ */
+
+#ifndef __INTEL_TDF_H__
+#define __INTEL_TDF_H__
+
+/*
+ * TDF (Transient-Data-Flush) is needed for Xe2+ where special L3:XD caching
can
+ * be enabled through various PAT index modes. Idea is to use this caching mode
+ * when for example rendering onto the display surface, with the promise that
+ * KMD will ensure transient cache entries are always flushed by the time we do
+ * the display flip, since display engine is never coherent with CPU/GPU
caches.
+ */
+
+struct drm_i915_private;
+
+#ifdef I915
+static inline void intel_td_flush(struct drm_i915_private *i915) {}
+#else
+void intel_td_flush(struct drm_i915_private *i915);
+#endif
+
+#endif
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index a67977edff5b..b620389761d5 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -206,7 +206,8 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
display/xe_dsb_buffer.o \
display/xe_fb_pin.o \
display/xe_hdcp_gsc.o \
- display/xe_plane_initial.o
+ display/xe_plane_initial.o \
+ display/xe_tdf.o
# SOC code shared with i915
xe-$(CONFIG_DRM_XE_DISPLAY) += \
diff --git a/drivers/gpu/drm/xe/display/xe_tdf.c
b/drivers/gpu/drm/xe/display/xe_tdf.c
new file mode 100644
index ..2c0d4e144e09
--- /dev/null
+++ b/drivers/gpu/drm/xe/display/xe_tdf.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2024 Intel Corporation
+ */
+
+#include "xe_device.h"
+#include "intel_display_types.h"
+#include "intel_tdf.h"
+
+void intel_td_flush(struct drm_i915_private *i915)
+{
+ xe_device_td_flush(i915);
this would be the display side "calling back onto xe". I think it's ok
given the current status quo, but Cc'ing Jani.
This also needs the previous 2 patches, which I'm ok with merging
through drm-intel-next if this user here is the correct way to
implement.
Lucas De Marchi
+}
--
2.34.1
Re: [PATCH v3 19/19] drm/xe/bmg: Enable the display support
On Tue, Apr 30, 2024 at 10:28:50AM GMT, Radhakrishna Sripada wrote:
From: Balasubramani Vivekanandan
Enable the display support for Battlemage
Signed-off-by: Balasubramani Vivekanandan
Reviewed-by: Shekhar Chauhan
Signed-off-by: Radhakrishna Sripada
Acked-by: Lucas De Marchi
to merge this through drm-intel-next once we confirm it's passing CI
(and tested on BMG).
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index a0cf5dd803c2..b01b1d30976a 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -342,6 +342,7 @@ static const struct xe_device_desc lnl_desc = {
static const struct xe_device_desc bmg_desc __maybe_unused = {
DGFX_FEATURES,
PLATFORM(XE_BATTLEMAGE),
+ .has_display = true,
.require_force_probe = true,
};
--
2.34.1
Re: [PATCH] drm/xe/display: Fix ADL-N detection
On Thu, Apr 25, 2024 at 11:22:30AM GMT, Matt Roper wrote: On Thu, Apr 25, 2024 at 11:16:09AM -0700, Lucas De Marchi wrote: Contrary to i915, in xe ADL-N is kept as a different platform, not a subplatform of ADL-P. Since the display side doesn't need to differentiate between P and N, i.e. IS_ALDERLAKE_P_N() is never called, just fixup the compat header to check for both P and N. Moving ADL-N to be a subplatform would be more complex as the firmware loading in xe only handles platforms, not subplatforms, as going forward the direction is to check on IP version rather than platforms/subplatforms. Fix warning when initializing display: xe :00:02.0: [drm:intel_pch_type [xe]] Found Alder Lake PCH [ cut here ] xe :00:02.0: drm_WARN_ON(!((dev_priv)->info.platform == XE_ALDERLAKE_S) && !((dev_priv)->info.platform == XE_ALDERLAKE_P)) And wrong paths being taken on the display side. Signed-off-by: Lucas De Marchi ADL-N uses exactly the same display IP as ADL-P (unlike on the GT side where they differ), so Reviewed-by: Matt Roper applied, thanks Lucas De Marchi
Re: [PATCH] MAINTAINERS: Move the drm-intel repo location to fd.o GitLab
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 --- 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
[PULL] drm-xe-fixes
Hi Dave and Sima Please pull the drm-xe-fixes for this week targeting v6.9-rc6. Simple fixes not really visible to end users: 2 around error paths on drm managed allocations and 1 on PF/VF relay messages that are not enabled by default. thanks Lucas De Marchi drm-xe-fixes-2024-04-25: - Fix error paths on managed allocations - Fix PF/VF relay messages The following changes since commit ed30a4a51bb196781c8058073ea720133a65596f: Linux 6.9-rc5 (2024-04-21 12:35:54 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-04-25 for you to fetch changes up to e3e989522ac9a6b7960c75b762e1e9568717b31e: drm/xe/guc: Fix arguments passed to relay G2H handlers (2024-04-24 10:20:00 -0500) - Fix error paths on managed allocations - Fix PF/VF relay messages Himal Prasad Ghimiray (2): drm/xe: Remove sysfs only once on action add failure drm/xe: call free_gsc_pkt only once on action add failure Michal Wajdeczko (1): drm/xe/guc: Fix arguments passed to relay G2H handlers drivers/gpu/drm/xe/xe_gt.c | 4 +++- drivers/gpu/drm/xe/xe_gt_ccs_mode.c | 19 +++ drivers/gpu/drm/xe/xe_gt_ccs_mode.h | 2 +- drivers/gpu/drm/xe/xe_guc_ct.c | 4 ++-- drivers/gpu/drm/xe/xe_huc.c | 9 + 5 files changed, 14 insertions(+), 24 deletions(-)
[PATCH] drm/xe/display: Fix ADL-N detection
Contrary to i915, in xe ADL-N is kept as a different platform, not a subplatform of ADL-P. Since the display side doesn't need to differentiate between P and N, i.e. IS_ALDERLAKE_P_N() is never called, just fixup the compat header to check for both P and N. Moving ADL-N to be a subplatform would be more complex as the firmware loading in xe only handles platforms, not subplatforms, as going forward the direction is to check on IP version rather than platforms/subplatforms. Fix warning when initializing display: xe :00:02.0: [drm:intel_pch_type [xe]] Found Alder Lake PCH [ cut here ] xe :00:02.0: drm_WARN_ON(!((dev_priv)->info.platform == XE_ALDERLAKE_S) && !((dev_priv)->info.platform == XE_ALDERLAKE_P)) And wrong paths being taken on the display side. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h index ffaa4d2f1eed..cd4632276141 100644 --- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h +++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h @@ -78,7 +78,8 @@ static inline struct drm_i915_private *kdev_to_i915(struct device *kdev) #define IS_ROCKETLAKE(dev_priv)IS_PLATFORM(dev_priv, XE_ROCKETLAKE) #define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, XE_DG1) #define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, XE_ALDERLAKE_S) -#define IS_ALDERLAKE_P(dev_priv) IS_PLATFORM(dev_priv, XE_ALDERLAKE_P) +#define IS_ALDERLAKE_P(dev_priv) (IS_PLATFORM(dev_priv, XE_ALDERLAKE_P) || \ + IS_PLATFORM(dev_priv, XE_ALDERLAKE_N)) #define IS_DG2(dev_priv) IS_PLATFORM(dev_priv, XE_DG2) #define IS_METEORLAKE(dev_priv) IS_PLATFORM(dev_priv, XE_METEORLAKE) #define IS_LUNARLAKE(dev_priv) IS_PLATFORM(dev_priv, XE_LUNARLAKE) -- 2.43.0
Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
On Mon, Apr 22, 2024 at 03:10:10PM GMT, Jani Nikula wrote: drivers/gpu/drm/xe/xe_debugfs.c | 1 + drivers/gpu/drm/xe/xe_gt_debugfs.c | 2 ++ drivers/gpu/drm/xe/xe_uc_debugfs.c | 2 ++ Acked-by: Lucas De Marchi thanks Lucas De Marchi
Re: [PATCH v8 0/6] drm/{i915,xe}: Convert fbdev to DRM client
On Tue, Apr 09, 2024 at 10:04:22AM GMT, Thomas Zimmermann wrote:
(was: drm/i915: Convert fbdev to DRM client)
Convert i915's fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups. Also
update the xe driver accordingly.
As with the other drivers' fbdev emulation, fbdev in i915 is now
an in-kernel DRM client that runs after the DRM device has been
registered. This allows to remove the asynchronous initialization.
i915 and xe are the final drivers with an fbdev emulation that is not
build upon struct drm_client. Once reviewed, the patches would ideally go
into drm-misc-next, so that the old fbdev helper code can be removed.
We can also attempt to add additional in-kernel clients. A DRM-based
dmesg log or a bootsplash are commonly mentioned. DRM can then switch
easily among the existing clients if/when required.
v8:
- do setup and cleanup in intel_display_driver_{register,unregister}()
(Jani, Jouni)
- mention xe in several commit messages (Rodrigo, Jani)
- resort patches to put driver-independent changes first
- slightly reword cover letter
v7:
- update xe driver
v6:
- reorder patches to fix build (Jouni)
- remove unnecessary handling of non-atomic commits (Jouni, Ville)
- return errors from callbacks (Jouni)
- various minor fixes
v5:
- style fixes (checkpatch)
v4:
v3:
- support module unloading (Jani, CI bot)
- as before, silently ignore devices without displays (CI bot)
v2:
- fix error handling (Jani)
- fix non-fbdev builds
- various minor fixes and cleanups
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
drivers/gpu/drm/drm_client.c | 13 +
drivers/gpu/drm/i915/display/intel_display.c | 1 -
.../drm/i915/display/intel_display_driver.c | 24 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 265 ++
drivers/gpu/drm/i915/display/intel_fbdev.h| 29 +-
drivers/gpu/drm/i915/i915_driver.c| 22 --
drivers/gpu/drm/xe/display/xe_display.c | 11 -
drivers/gpu/drm/xe/xe_device.c| 1 +
Acked-by: Lucas De Marchi
thanks
Lucas De Marchi
8 files changed, 167 insertions(+), 199 deletions(-)
--
2.44.0
Re: [PATCH] nightly.conf: Update drm-intel URLs, add missing bare ssh drm-xe URL
On Wed, Apr 24, 2024 at 01:32:19PM GMT, Ryszard Knop wrote: - Switch drm-intel URLs to the new GitLab location. - Add a short SSH link for drm-xe for completeness with other blocks. - Add a missing tab in drm_tip_config for column alignment. Signed-off-by: Ryszard Knop --- nightly.conf | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/nightly.conf b/nightly.conf index 7ef4249f0c67..2971277b0e25 100644 --- a/nightly.conf +++ b/nightly.conf @@ -30,10 +30,16 @@ https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " drm_tip_repos[drm-xe]=" +g...@gitlab.freedesktop.org:drm/xe/kernel.git https://gitlab.freedesktop.org/drm/xe/kernel.git ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git " drm_tip_repos[drm-intel]=" +g...@gitlab.freedesktop.org:drm/i915/kernel.git we probably need to update dim so pick_protocol_url knows this is an ssh remote. I think it's harmless right now as if there's no chosen protocol, it will use the first (git@... in this case). If a protocol is chosen, it will use one of the urls with protocol in it. We'd have a problem if there was only this form for ssh remote. Acked-by: Lucas De Marchi Lucas De Marchi +https://gitlab.freedesktop.org/drm/i915/kernel.git +ssh://g...@gitlab.freedesktop.org/drm/i915/kernel.git +" +drm_old_urls[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel ssh://git.freedesktop.org/git/drm-intel git://anongit.freedesktop.org/drm/drm-intel @@ -97,6 +103,6 @@ drm_tip_config=( "drm-xedrm-xe-next" "drm-intel topic/core-for-CI" - "drm-xetopic/xe-for-CI" + "drm-xetopic/xe-for-CI" "drm-intel topic/thunderbolt-next" ) # DO NOT CHANGE THIS LINE -- 2.44.0
Re: [PATCH v2 0/5] drm/i915/dmc: firmware path handling changes
On Fri, Apr 19, 2024 at 12:41:53PM GMT, Jani Nikula wrote: v2 of https://lore.kernel.org/r/cover.1713450693.git.jani.nik...@intel.com Jani Nikula (5): 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/display/intel_display_params.c | 4 + .../drm/i915/display/intel_display_params.h | 1 + drivers/gpu/drm/i915/display/intel_dmc.c | 175 +++--- drivers/gpu/drm/i915/i915_params.c| 3 - drivers/gpu/drm/i915/i915_params.h| 1 - drivers/gpu/drm/xe/xe_device_types.h | 3 - Acked-by: Lucas De Marchi thanks Lucas De Marchi 6 files changed, 112 insertions(+), 75 deletions(-) -- 2.39.2
Re: [PATCH 4/5] drm/i915/dmc: change meaning of dmc_firmware_path="" module param
On Thu, Apr 18, 2024 at 05:44:13PM GMT, Gustavo Sousa wrote:
Quoting Jani Nikula (2024-04-18 17:09:04-03:00)
On Thu, 18 Apr 2024, Gustavo Sousa wrote:
Quoting Jani Nikula (2024-04-18 11:39:53-03:00)
The distinction between the dmc_firmware_path module param being NULL
and the empty string "" is problematic. It's not possible to set the
parameter back to NULL via sysfs or debugfs. Remove the distinction, and
consider NULL and the empty string to be the same thing, and use the
platform default for them.
This removes the possibility to disable DMC (and runtime PM) via
i915.dmc_firmware_path="". Instead, you will need to specify a
non-existent file or a file that will not parse correctly.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 20 ++--
drivers/gpu/drm/i915/i915_params.c | 3 ++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 740c05ce83cc..3e510c2be1eb 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -73,6 +73,13 @@ static struct intel_dmc *i915_to_dmc(struct drm_i915_private
*i915)
return i915->display.dmc.dmc;
}
+static const char *dmc_firmware_param(struct drm_i915_private *i915)
+{
+const char *p = i915->params.dmc_firmware_path;
+
+return p && *p ? p : NULL;
+}
+
#define DMC_VERSION(major, minor)((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version)((version) >> 16)
#define DMC_VERSION_MINOR(version)((version) & 0x)
@@ -989,7 +996,7 @@ static void dmc_load_work_fn(struct work_struct *work)
err = request_firmware(, dmc->fw_path, i915->drm.dev);
-if (err == -ENOENT && !i915->params.dmc_firmware_path) {
+if (err == -ENOENT && !dmc_firmware_param(i915)) {
fallback_path = dmc_fallback_path(i915);
if (fallback_path) {
drm_dbg_kms(>drm, "%s not found, falling back to
%s\n",
@@ -1062,15 +1069,8 @@ void intel_dmc_init(struct drm_i915_private *i915)
dmc->fw_path = dmc_firmware_default(i915, >max_fw_size);
-if (i915->params.dmc_firmware_path) {
-if (strlen(i915->params.dmc_firmware_path) == 0) {
-drm_info(>drm,
- "Disabling DMC firmware and runtime PM\n");
-goto out;
-}
-
-dmc->fw_path = i915->params.dmc_firmware_path;
-}
+if (dmc_firmware_param(i915))
+dmc->fw_path = dmc_firmware_param(i915);
if (!dmc->fw_path) {
drm_dbg_kms(>drm,
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index de43048543e8..9e7f2a9f6287 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -109,7 +109,8 @@ i915_param_named_unsafe(huc_firmware_path, charp, 0400,
"HuC firmware path to use instead of the default one");
i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
-"DMC firmware path to use instead of the default one");
+"DMC firmware path to use instead of the default one. "
+"Use non-existent file to disable DMC and runtime PM.");
Okay. But is it too bad to have a magic string for it? The up side is
that there wouldn't be error messages in the log if we had such option.
Another upside is that we could also just skip requesting the firmware
altogether, similar to what we have currently.
It's just a small naming problem... what should the magic string for
"disabled" be? Like, yes, that's the obvious choice right there, but
it's also a valid filename. Who am I to say how people should name their
firmware blobs. :)
"/dev/null"?
I like this one!
+1
Lucas De Marchi
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc5. thanks Lucas De Marchi drm-xe-fixes-2024-04-18: - Fix bo leak on error path during fb init - Fix use-after-free due to order vm is put and destroyed The following changes since commit 0bbac3facb5d6cc0171c45c9873a2dc96bea9680: Linux 6.9-rc4 (2024-04-14 13:38:39 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-04-18 for you to fetch changes up to ca7c52ac7ad384bcf299d89482c45fec7cd00da9: drm/xe/vm: prevent UAF with asid based lookup (2024-04-17 08:03:13 -0500) - Fix bo leak on error path during fb init - Fix use-after-free due to order vm is put and destroyed Maarten Lankhorst (1): drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init Matthew Auld (1): drm/xe/vm: prevent UAF with asid based lookup drivers/gpu/drm/xe/display/intel_fb_bo.c | 8 ++-- drivers/gpu/drm/xe/xe_vm.c | 21 +++-- 2 files changed, 17 insertions(+), 12 deletions(-)
Re: [PATCH 1/2] drm/i915/display: remove small micro-optimizations in irq handling
On Mon, Apr 08, 2024 at 03:54:44PM GMT, Jani Nikula wrote:
The raw register reads/writes are there as micro-optimizations to avoid
multiple pointer indirections on uncore->regs. Presumably this is useful
when there are plenty of register reads/writes in the same
function. However, the display irq handling only has a few raw
reads/writes. Remove them for simplification.
I think that comment didn't age well. Not to say there's something wrong
with this commit, but just to make sure we are aware of the additional
stuff going on and we if we are ok with that.
using intel_de_read() in place of raw_reg_read() will do (for newer
platforms):
1) Read FPGA_DBG to detect unclaimed access before the actual read
2) Find the relevant forcewake for that register, acquire and wait for
ack
3) readl(reg)
4) Read FPGA_DBG to detect unclaimed access after the actual read
5) Trace reg rw
That's much more than a pointer indirection. Are we ok with that in the
irq? Also, I don't know why but we have variants to skip tracing (step
5 above), but on my books a disabled tracepoint is order of magnitudes
less overhead than 1, 2 and 4.
btw, if we drop the raw accesses, then we can probably drop (1) above.
Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_irq.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index f846c5b108b5..d4ae9139be39 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -1148,15 +1148,14 @@ void gen8_de_irq_handler(struct drm_i915_private
*dev_priv, u32 master_ctl)
u32 gen11_gu_misc_irq_ack(struct drm_i915_private *i915, const u32 master_ctl)
{
- void __iomem * const regs = intel_uncore_regs(>uncore);
u32 iir;
if (!(master_ctl & GEN11_GU_MISC_IRQ))
return 0;
- iir = raw_reg_read(regs, GEN11_GU_MISC_IIR);
+ iir = intel_de_read(i915, GEN11_GU_MISC_IIR);
if (likely(iir))
- raw_reg_write(regs, GEN11_GU_MISC_IIR, iir);
+ intel_de_write(i915, GEN11_GU_MISC_IIR, iir);
return iir;
}
@@ -1169,18 +1168,18 @@ void gen11_gu_misc_irq_handler(struct drm_i915_private
*i915, const u32 iir)
void gen11_display_irq_handler(struct drm_i915_private *i915)
{
- void __iomem * const regs = intel_uncore_regs(>uncore);
- const u32 disp_ctl = raw_reg_read(regs, GEN11_DISPLAY_INT_CTL);
+ u32 disp_ctl;
disable_rpm_wakeref_asserts(>runtime_pm);
/*
* GEN11_DISPLAY_INT_CTL has same format as GEN8_MASTER_IRQ
* for the display related bits.
*/
- raw_reg_write(regs, GEN11_DISPLAY_INT_CTL, 0x0);
+ disp_ctl = intel_de_read(i915, GEN11_DISPLAY_INT_CTL);
+
+ intel_de_write(i915, GEN11_DISPLAY_INT_CTL, 0);
gen8_de_irq_handler(i915, disp_ctl);
- raw_reg_write(regs, GEN11_DISPLAY_INT_CTL,
- GEN11_DISPLAY_IRQ_ENABLE);
+ intel_de_write(i915, GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
enable_rpm_wakeref_asserts(>runtime_pm);
}
--
2.39.2
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc4. Just some trivial fixes, mostly from code analysis. The last one doesn't trigger any issue for now since the register is not used for mmio. I decided to include it, because it would be a silent prereq of any future commit making use of that register. thanks Lucas De Marchi drm-xe-fixes-2024-04-11: - Fix double display mutex initializations - Fix u32 -> u64 implicit conversions - Fix RING_CONTEXT_CONTROL not marked as masked 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://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-04-11 for you to fetch changes up to f76646c83f028c62853c23dac49204232e903597: drm/xe: Label RING_CONTEXT_CONTROL as masked (2024-04-11 08:41:54 -0500) - Fix double display mutex initializations - Fix u32 -> u64 implicit conversions - Fix RING_CONTEXT_CONTROL not marked as masked Ashutosh Dixit (1): drm/xe: Label RING_CONTEXT_CONTROL as masked Himal Prasad Ghimiray (1): drm/xe/xe_migrate: Cast to output precision before multiplying operands Karthik Poosa (1): drm/xe/hwmon: Cast result to output precision on left shift of operand Lucas De Marchi (1): drm/xe/display: Fix double mutex initialization drivers/gpu/drm/xe/display/xe_display.c | 5 - drivers/gpu/drm/xe/regs/xe_engine_regs.h | 2 +- drivers/gpu/drm/xe/xe_hwmon.c| 4 ++-- drivers/gpu/drm/xe/xe_lrc.c | 5 ++--- drivers/gpu/drm/xe/xe_migrate.c | 8 5 files changed, 9 insertions(+), 15 deletions(-)
Re: [PATCH i-g-t v2] lib/kunit: Read results from debugfs
On Wed, Apr 10, 2024 at 08:28:40PM +0200, Janusz Krzysztofik wrote: Hi Lucas, On Friday, 5 April 2024 19:54:53 CEST Janusz Krzysztofik wrote: KUnit can provide KTAP reports from test modules via debugfs files, one per test suite. Using that source of test results instead of extracting them from dmesg, where they may be interleaved with other kernel messages, seems more easy to handle and less error prone. Switch to it. If KUnit debugfs support is found not configured then fall back to legacy processing path. v2: Check validity of debugfs argument before calling kunit_get_tests() (Kamil), - replace multiple openat() + fdopen/fdopendir(), each followed by an error check, with less expensive fopen/opendir() of file/dir pathname components concatentated to a local buffer, protected from buffer overflow or truncation with a single check for enough buffer space (Lucas), - avoid confusing 'if' statement condition (Lucas). Could you please confirm if your R-b still applies? yes, LGTM. Reviewed-by: Lucas De Marchi thanks Lucas De Marchi
Re: [PATCH 00/10] drm: move Intel drm headers to a subdirectory
On Wed, Apr 10, 2024 at 01:05:07PM +0300, Jani Nikula wrote: We've accumulated enough Intel specific header files under include/drm that they warrant a subdirectory of their own. Clean up the top drm header directory by moving the Intel files under include/drm/intel. Since i915 is most impacted, I suggest merging the lot via drm-intel-next. Please ack if this is fine for you. Acked-by: Lucas De Marchi Lucas De Marchi
Re: [PATCH 0/8] drm/i915: drm_i915_private and xe_device cleanups
On Tue, Apr 09, 2024 at 12:02:17AM +0300, Jani Nikula wrote: On Mon, 08 Apr 2024, Jani Nikula wrote: Continue cleaning up the members from drm_i915_private and xe_device to struct intel_display. Lucas, there's a bunch of xe changes included here, ack for merging via drm-intel-next? Acked-by: Lucas De Marchi I skimmed through the series and left just one comment. It may be very well because I skimmed through it too fast though. I agree on merging it through drm-intel-next. Lucas De Marchi
Re: [PATCH 6/8] drm/i915: move de_irq_mask to display substruct
On Mon, Apr 08, 2024 at 09:08:41PM +0300, Jani Nikula wrote:
The info is related to display, and should be placed under
i915->display.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_core.h | 2 ++
.../gpu/drm/i915/display/intel_display_irq.c| 17 +
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/xe/xe_device_types.h| 7 ++-
4 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 68aee44b4822..7a70b162b015 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -452,6 +452,8 @@ struct intel_display {
/* For i915gm/i945gm vblank irq workaround */
u8 vblank_enabled;
+
+ u32 de_irq_mask[I915_MAX_PIPES];
} irq;
struct {
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
b/drivers/gpu/drm/i915/display/intel_display_irq.c
index e9fcdac90efd..9b9548ae9797 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -117,13 +117,14 @@ static void bdw_update_pipe_irq(struct drm_i915_private
*dev_priv,
if (drm_WARN_ON(_priv->drm, !intel_irqs_enabled(dev_priv)))
return;
- new_val = dev_priv->de_irq_mask[pipe];
+ new_val = dev_priv->display.irq.de_irq_mask[pipe];
is this a good name though? I'd expect to see something like
display.irq.mask in the code.
Lucas De Marchi
Re: [PATCH 0/6] drm/i915 and drm/xe display integration cleanups
On Fri, Apr 05, 2024 at 10:37:37PM +0300, Jani Nikula wrote:
Some cleanups on i915 side, and subsequent cleanups on xe side. I'd like
to merge all of these via drm-intel-next.
For the entire series:
Reviewed-by: Lucas De Marchi
and ack on merging via drm-intel-next.
Lucas De Marchi
BR,
Jani.
Jani Nikula (6):
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/display/intel_ddi_buf_trans.c| 4 +--
drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++-
.../{i915_fixed.h => display/intel_fixed.h} | 0
drivers/gpu/drm/i915/display/skl_watermark.c | 2 +-
.../gpu/drm/xe/compat-i915-headers/i915_drv.h | 34 ---
.../drm/xe/compat-i915-headers/i915_fixed.h | 6
.../gpu/drm/xe/compat-i915-headers/i915_gem.h | 9 -
.../drm/xe/compat-i915-headers/i915_vgpu.h| 26 --
.../drm/xe/compat-i915-headers/intel_uc_fw.h | 11 --
9 files changed, 6 insertions(+), 90 deletions(-)
rename drivers/gpu/drm/i915/{i915_fixed.h => display/intel_fixed.h} (100%)
delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/i915_fixed.h
delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/i915_gem.h
delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
--
2.39.2
Re: [PATCH 2/6] drm/i915/dmc: define firmware URL locally
On Fri, Apr 05, 2024 at 10:37:39PM +0300, Jani Nikula wrote:
Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat
intel_uc_fw.h. If there needs to be duplication of the URL, at least
have the duplication in a sensible way.
Cc: Lucas De Marchi
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
but see below. +Josh
---
drivers/gpu/drm/i915/display/intel_dmc.c | 4 +++-
drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h| 1 -
drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h | 11 ---
3 files changed, 3 insertions(+), 13 deletions(-)
delete mode 100644 drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 3fa851b5c7a6..e61e9c1b8947 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -38,6 +38,8 @@
* low-power state and comes back to normal.
*/
+#define INTEL_DMC_FIRMWARE_URL
"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
repo recently moved to gitlab, but as far as I know the one on
kernel.org will still work. Do we want to change it?
https://gitlab.com/kernel-firmware/linux-firmware
thanks
Lucas De Marchi
+
enum intel_dmc_id {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
@@ -953,7 +955,7 @@ static void dmc_load_work_fn(struct work_struct *work)
" Disabling runtime power management.\n",
dmc->fw_path);
drm_notice(>drm, "DMC firmware homepage: %s",
- INTEL_UC_FIRMWARE_URL);
+ INTEL_DMC_FIRMWARE_URL);
}
release_firmware(fw);
diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
index a01d1b869c2d..837e95e3604e 100644
--- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
+++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h
@@ -26,7 +26,6 @@
#include "i915_utils.h"
#include "intel_gt_types.h"
#include "intel_step.h"
-#include "intel_uc_fw.h"
#include "intel_uncore.h"
#include "intel_runtime_pm.h"
#include
diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
b/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
deleted file mode 100644
index 009745328992..
--- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uc_fw.h
+++ /dev/null
@@ -1,11 +0,0 @@
-/* SPDX-License-Identifier: MIT */
-/*
- * Copyright © 2023 Intel Corporation
- */
-
-#ifndef _INTEL_UC_FW_H_
-#define _INTEL_UC_FW_H_
-
-#define INTEL_UC_FIRMWARE_URL
"https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;
-
-#endif
--
2.39.2
[PATCH] drm/xe/display: Fix double mutex initialization
All of these mutexes are already initialized by the display side since
commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display
code"), so the xe shouldn´t initialize them.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Cc: Jani Nikula
Cc: Arun R Murthy
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/display/xe_display.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index e4db069f0db3..6ec375c1c4b6 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -108,11 +108,6 @@ int xe_display_create(struct xe_device *xe)
xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
drmm_mutex_init(>drm, >sb_lock);
- drmm_mutex_init(>drm, >display.backlight.lock);
- drmm_mutex_init(>drm, >display.audio.mutex);
- drmm_mutex_init(>drm, >display.wm.wm_mutex);
- drmm_mutex_init(>drm, >display.pps.mutex);
- drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
xe->enabled_irq_mask = ~0;
err = drmm_add_action_or_reset(>drm, display_destroy, NULL);
--
2.43.0
Re: [rebase 1/3] drm: Add drm_vblank_work_flush_all().
what does "rebase" instead of "PATCH" is supposed to mean here?
And then we have a "PATCH v2" as reply to this one.
Shouldn't this go to dri-devel (too)?
Lucas De Marchi
On Thu, Apr 04, 2024 at 12:48:11PM +0200, Maarten Lankhorst wrote:
From: Maarten Lankhorst
In some cases we want to flush all vblank work, right before vblank_off
for example. Add a simple function to make this possible.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_vblank_work.c | 22 ++
include/drm/drm_vblank_work.h | 2 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_vblank_work.c
b/drivers/gpu/drm/drm_vblank_work.c
index 43cd5c0f4f6f..ff86f2b2e052 100644
--- a/drivers/gpu/drm/drm_vblank_work.c
+++ b/drivers/gpu/drm/drm_vblank_work.c
@@ -232,6 +232,28 @@ void drm_vblank_work_flush(struct drm_vblank_work *work)
}
EXPORT_SYMBOL(drm_vblank_work_flush);
+/**
+ * drm_vblank_work_flush_all - flush all currently pending vblank work on crtc.
+ * @crtc: crtc for which vblank work to flush
+ *
+ * Wait until all currently queued vblank work on @crtc
+ * has finished executing once.
+ */
+void drm_vblank_work_flush_all(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_vblank_crtc *vblank = >vblank[drm_crtc_index(crtc)];
+
+ spin_lock_irq(>event_lock);
+ wait_event_lock_irq(vblank->work_wait_queue,
+ waitqueue_active(>work_wait_queue),
+ dev->event_lock);
+ spin_unlock_irq(>event_lock);
+
+ kthread_flush_worker(vblank->worker);
+}
+EXPORT_SYMBOL(drm_vblank_work_flush_all);
+
/**
* drm_vblank_work_init - initialize a vblank work item
* @work: vblank work item
diff --git a/include/drm/drm_vblank_work.h b/include/drm/drm_vblank_work.h
index eb41d0810c4f..e04d436b7297 100644
--- a/include/drm/drm_vblank_work.h
+++ b/include/drm/drm_vblank_work.h
@@ -17,6 +17,7 @@ struct drm_crtc;
* drm_vblank_work_init()
* drm_vblank_work_cancel_sync()
* drm_vblank_work_flush()
+ * drm_vblank_work_flush_all()
*/
struct drm_vblank_work {
/**
@@ -67,5 +68,6 @@ void drm_vblank_work_init(struct drm_vblank_work *work,
struct drm_crtc *crtc,
void (*func)(struct kthread_work *work));
bool drm_vblank_work_cancel_sync(struct drm_vblank_work *work);
void drm_vblank_work_flush(struct drm_vblank_work *work);
+void drm_vblank_work_flush_all(struct drm_crtc *crtc);
#endif /* !_DRM_VBLANK_WORK_H_ */
--
2.43.0
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc3. This is a little late in the week as I was waiting a critical fix to be applied to get our CI back. This is mainly due to some stress tests creating hundreds of exec queues and that not playing nice with the workqueue changes introduced in v6.9. That shouldn't be the normal use case but was causing CI to abort further tests. Other changes include fixes around rebinding and TLB invalidation. thanks Lucas De Marchi drm-xe-fixes-2024-04-04: - Stop using system_unbound_wq for preempt fences, as this can cause starvation when reaching more than max_active defined by workqueue - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency 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://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-04-04 for you to fetch changes up to 77a011012d7d8b98368a763bf74317c6d5ce00f1: drm/xe: Use ordered wq for preempt fence waiting (2024-04-04 08:32:34 -0500) - Stop using system_unbound_wq for preempt fences, as this can cause starvation when reaching more than max_active defined by workqueue - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency Matthew Brost (1): drm/xe: Use ordered wq for preempt fence waiting Thomas Hellström (4): drm/xe: Use ring ops TLB invalidation for rebinds drm/xe: Rework rebinding drm/xe: Make TLB invalidation fences unordered drm/xe: Move vma rebinding to the drm_exec locking loop drivers/gpu/drm/xe/xe_device.c | 11 ++- drivers/gpu/drm/xe/xe_device_types.h| 3 + drivers/gpu/drm/xe/xe_exec.c| 79 ++-- drivers/gpu/drm/xe/xe_exec_queue_types.h| 5 ++ drivers/gpu/drm/xe/xe_gt_pagefault.c| 3 +- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 1 - drivers/gpu/drm/xe/xe_gt_types.h| 7 -- drivers/gpu/drm/xe/xe_preempt_fence.c | 2 +- drivers/gpu/drm/xe/xe_pt.c | 25 +-- drivers/gpu/drm/xe/xe_ring_ops.c| 11 +-- drivers/gpu/drm/xe/xe_sched_job.c | 10 +++ drivers/gpu/drm/xe/xe_sched_job_types.h | 2 + drivers/gpu/drm/xe/xe_vm.c | 110 +--- drivers/gpu/drm/xe/xe_vm.h | 8 +- drivers/gpu/drm/xe/xe_vm_types.h| 8 +- 15 files changed, 140 insertions(+), 145 deletions(-)
Re: [PATCHv2] drm/xe/display: check for error on drmm_mutex_init
On Thu, Mar 28, 2024 at 12:33:09PM +0200, Jani Nikula wrote:
On Thu, 28 Mar 2024, Andi Shyti wrote:
Hi Arun,
...
- drmm_mutex_init(>drm, >sb_lock);
- drmm_mutex_init(>drm, >display.backlight.lock);
- drmm_mutex_init(>drm, >display.audio.mutex);
- drmm_mutex_init(>drm, >display.wm.wm_mutex);
- drmm_mutex_init(>drm, >display.pps.mutex);
- drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
+ if (drmm_mutex_init(>drm, >sb_lock) ||
+ drmm_mutex_init(>drm, >display.backlight.lock) ||
+ drmm_mutex_init(>drm, >display.audio.mutex) ||
+ drmm_mutex_init(>drm, >display.wm.wm_mutex) ||
+ drmm_mutex_init(>drm, >display.pps.mutex) ||
+ drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex))
+ return -ENOMEM;
My suggestion from v1 was to assign and check the return value, not to
hardcode the return like done here. Now we have a v3 going back to v1
and we never had what was suggested. Why? Let me be explicit and type
it:
if ((err = drmm_mutex_init(>drm, >sb_lock)) ||
(err = drmm_mutex_init(>drm, >display.backlight.lock)) ||
(err = drmm_mutex_init(>drm, >display.audio.mutex)) ||
(err = drmm_mutex_init(>drm, >display.wm.wm_mutex)) ||
(err = drmm_mutex_init(>drm, >display.pps.mutex)) ||
(err = drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex)))
return err;
I also said I usually don't like assign + check in the same statement,
but all the alternatives I've seen here are worse.
However it turns out all of these display mutex initializations are
actually wrong after commit 3fef3e6ff86a ("drm/i915: move display mutex
inits to display code"), which predates xe in the tree.
drivers/gpu/drm/i915/i915_driver.c:
intel_display_driver_early_probe(dev_priv);
drivers/gpu/drm/xe/display/xe_display.c:
intel_display_driver_early_probe(xe);
So intel_display_driver_early_probe() is actually called from xe, which
does the mutex_init() (and misses the mutex_destroy()). Am I missing
anything?
why not extract the value from drmm_mutex_init()? it would make
the code a bit more complex, but better than forcing a -ENOMEM
return.
err = drmm_mutex_init(...)
if (err)
return err;
err = drmm_mutex_init(...)
if (err)
return err;
err = drmm_mutex_init(...)
if (err)
return err;
...
On the other hand drmm_mutex_init(), as of now returns only
-ENOMEM, but it's a bad practice to assume it will always do. I'd
rather prefer not to check the error value at all.
And round and round we go. This is exactly what v1 was [1], but it's not
clear because the patch doesn't have a changelog.
This is all utterly ridiculous compared to *why* we even have or use
drmm_mutex_init(). Managed initialization causes more trouble here than
it gains us. Gah.
I think managed initialization make sense to keep the teardown/unwind
part sane (which is often not tested). However drmm_mutex_init() maybe
is overkill indeed. We started using it because people often forget the
mutex_destroy() and drm/ as whole started using it. Compare:
git grep mutex_init -- drivers/gpu/drm/i915/
git grep mutex_destroy -- drivers/gpu/drm/i915/
This is only an issue when mutex_init does more than init, which is the
case with CONFIG_PREEMPT_RT + CONFIG_DEBUG_MUTEXES, which most people
don't have set so they don't see it, CI doesn't see it, but it causes
problems for people who have that set. Maybe what we could have would be
a drmm_mutex_vinit(mutex, ...) so we can do:
err = drmm_mutex_vinit(>drm,
>sb_lock,
>display.backlight.lock,
...,
NULL);
if (err)
return err;
or... just stop using drmm_mutex_init and add the destroy. No need for
unwind as mutex_init() can't fail. We still need to keep the destroy
explicit, but I think that would be fine (and doesn't cause 1 allocation
per mutex).
Lucas De Marchi
BR,
Jani.
[1]
https://lore.kernel.org/r/ki4ynsl4nmhavf63vzdlt2xkedjo7p7iouzvcksvki3okgz6ak@twlznnlo3g22
Andi
xe->enabled_irq_mask = ~0;
err = drmm_add_action_or_reset(>drm, display_destroy, NULL);
--
2.25.1
--
Jani Nikula, Intel
Re: [PATCH v2 02/25] drm/xe/bmg: Add BMG platform definition
On Wed, Apr 03, 2024 at 04:52:30PM +0530, Balasubramani Vivekanandan wrote: diff --git a/include/drm/xe_pciids.h b/include/drm/xe_pciids.h index c7fc288dacee..73d972a8aca1 100644 --- a/include/drm/xe_pciids.h +++ b/include/drm/xe_pciids.h @@ -208,4 +208,11 @@ MACRO__(0x64A0, ## __VA_ARGS__), \ MACRO__(0x64B0, ## __VA_ARGS__) +#define XE_BMG_IDS(MACRO__, ...) \ + MACRO__(0xE202, ## __VA_ARGS__), \ + MACRO__(0xE20B, ## __VA_ARGS__), \ + MACRO__(0xE20C, ## __VA_ARGS__), \ + MACRO__(0xE20D, ## __VA_ARGS__), \ + MACRO__(0xE212, ## __VA_ARGS__) see my previous review. I don't think these patches are split correctly. We should postpone the PCI additions and let this one be only about adding the platform descriptor and definitions. The next patch adding IS_BATTLEMAGE() could be squashed in this one, while the PCI additions be separate in another patch. Lucas De Marchi
Re: [PATCH] drm/i915/display: fix display param dup for NULL char * params
On Tue, Apr 02, 2024 at 06:55:34PM +0300, Jani Nikula wrote:
The display param duplication deviates from the original param
duplication in that it converts NULL params to to allocated empty
strings. This works for the vbt_firmware parameter, but not for
dmc_firmware_path, the user of which interprets NULL and the empty
string as distinct values. Specifically, the empty dmc_firmware_path
leads to DMC and PM being disabled.
Just remove the NULL check and pass it to kstrdup(), which safely
returns NULL for NULL input.
Fixes: 8015bee0bfec ("drm/i915/display: Add framework to add parameters specific to
display")
Fixes: 0d82a0d6f556 ("drm/i915/display: move dmc_firmware_path to display
params")
Cc: Jouni Högander
Cc: Luca Coelho
Cc: # v6.8+
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
... but what's the purpose of the duplication? How one is supposed to
use the dmc_firmware with e.g. LNL + BMG? Setting it later via debugfs
doesn´t change the behavior. AFAIR this was done to support multiple
devices, but I don't think it achieves its purpose or I'm missing
something.
By leaving a param writable and not duplicate it at all, we are at
least be allowed to:
1) disable autoprobe
2) load module
3) bind do LNL
4) set dmc_firmware param
5) bind to BMG
Yeah, it's manual and not intuitive, but should only be used by
developers with targeted debug. How would we do something like that
with the current code?
I know that for params via sysfs, it's impossible to get them back to
NULL, so I think we should make sure NULL and empty is handled the same
way. Getting it back to empty is hard enough but at least possible (see
https://lore.kernel.org/igt-dev/20240228223134.3908035-4-lucas.demar...@intel.com/),
but I think this is not the case for debugfs.
Lucas De Marchi
Re: [PATCH 05/13] spi: add driver for intel graphics on-die spi device
On Thu, Mar 28, 2024 at 02:22:28PM +0200, Alexander Usyskin wrote: Add auxiliary driver for intel discrete graphics on-die spi device. CC: Rodrigo Vivi Signed-off-by: Tomas Winkler Signed-off-by: Lucas De Marchi did you mean to Cc me? I never gave my s-o-b afair. The order of the s-o-b in these patches also seem to be messed up. Who is the author of this patch (and others)? Is it you or Tomas? If it's Tomas, then the commit in your tree is wrong and you have to fix it up so when you send the patch git adds a "From:" to the body. Otherwise, please fix the order. Lucas De Marchi
Re: [topic/core-for-CI] ASoC: SOF: Core: Add remove_late() to sof_init_environment failure path
On Thu, Mar 28, 2024 at 09:52:33AM -0400, Rodrigo Vivi wrote:
From: Chaitanya Kumar Borah
In cases where the sof driver is unable to find the firmware and/or
topology file [1], it exits without releasing the i915 runtime
pm wakeref [2]. This results in dmesg warnings[3] during
suspend/resume or driver unbind. Add remove_late() to the failure path
of sof_init_environment so that i915 wakeref is released appropriately
[1]
[8.990366] sof-audio-pci-intel-mtl :00:1f.3: SOF firmware and/or
topology file not found.
[8.990396] sof-audio-pci-intel-mtl :00:1f.3: Supported default profiles
[8.990398] sof-audio-pci-intel-mtl :00:1f.3: - ipc type 1 (Requested):
[8.990399] sof-audio-pci-intel-mtl :00:1f.3: Firmware file:
intel/sof-ipc4/mtl/sof-mtl.ri
[8.990401] sof-audio-pci-intel-mtl :00:1f.3: Topology file:
intel/sof-ace-tplg/sof-mtl-rt711-2ch.tplg
[8.990402] sof-audio-pci-intel-mtl :00:1f.3: Check if you have
'sof-firmware' package installed.
[8.990403] sof-audio-pci-intel-mtl :00:1f.3: Optionally it can be
manually downloaded from:
[8.990404] sof-audio-pci-intel-mtl :00:1f.3:
https://github.com/thesofproject/sof-bin/
[8.999088] sof-audio-pci-intel-mtl :00:1f.3: error: sof_probe_work
failed err: -2
[2]
ref_tracker: :00:02.0@9b8511b6a378 has 1/5 users at
track_intel_runtime_pm_wakeref.part.0+0x36/0x70 [i915]
__intel_runtime_pm_get+0x51/0xb0 [i915]
intel_runtime_pm_get+0x17/0x20 [i915]
intel_display_power_get+0x2f/0x70 [i915]
i915_audio_component_get_power+0x23/0x120 [i915]
snd_hdac_display_power+0x89/0x130 [snd_hda_core]
hda_codec_i915_init+0x3f/0x50 [snd_sof_intel_hda]
hda_dsp_probe_early+0x170/0x250 [snd_sof_intel_hda_common]
snd_sof_device_probe+0x224/0x320 [snd_sof]
sof_pci_probe+0x15b/0x220 [snd_sof_pci]
hda_pci_intel_probe+0x30/0x70 [snd_sof_intel_hda_common]
local_pci_probe+0x4c/0xb0
pci_device_probe+0xcc/0x250
really_probe+0x18e/0x420
__driver_probe_device+0x7e/0x170
driver_probe_device+0x23/0xa0
[3]
[ 484.105070] [ cut here ]
[ 484.108238] thunderbolt :00:0d.2: PM: pci_pm_suspend_late+0x0/0x50
returned 0 after 0 usecs
[ 484.117106] i915 :00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup
[ 484.792005] WARNING: CPU: 2 PID: 2405 at
drivers/gpu/drm/i915/intel_runtime_pm.c:444
intel_runtime_pm_driver_release+0x6c/0x80
Signed-off-by: Chaitanya Kumar Borah
Tested-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
[This commit is still under review on the sof tree, but likely targeting 6.10
Adding to topic branch to unblock RPM in LNL VLK-56970]
Link: https://github.com/thesofproject/linux/pull/4878
Signed-off-by: Rodrigo Vivi
Acked-by: Lucas De Marchi
to merge in our topic/core-for-CI branch.
thanks
Lucas De Marchi
---
sound/soc/sof/core.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 425b023b03b4..3e41821562f0 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -339,8 +339,7 @@ static int sof_init_environment(struct snd_sof_dev *sdev)
ret = snd_sof_probe(sdev);
if (ret < 0) {
dev_err(sdev->dev, "failed to probe DSP %d\n", ret);
- sof_ops_free(sdev);
- return ret;
+ goto err_sof_probe;
}
/* check machine info */
@@ -358,15 +357,18 @@ static int sof_init_environment(struct snd_sof_dev *sdev)
ret = validate_sof_ops(sdev);
if (ret < 0) {
snd_sof_remove(sdev);
+ snd_sof_remove_late(sdev);
return ret;
}
}
+ return 0;
+
err_machine_check:
- if (ret) {
- snd_sof_remove(sdev);
- sof_ops_free(sdev);
- }
+ snd_sof_remove(sdev);
+err_sof_probe:
+ snd_sof_remove_late(sdev);
+ sof_ops_free(sdev);
return ret;
}
--
2.44.0
Re: [PATCH] drm/i915: use fine grained -Woverride-init disable
On Thu, Mar 28, 2024 at 12:24:55PM +0200, Jani Nikula wrote:
Use localized __diag_push(), __diag_ignore_all() with rationale, and
__diag_pop() for specific initializations instead of blanket disabling
of -Woverride-init across several files.
Note that we've tried this before with commit 88e9664434c9 ("drm/i915:
use localized __diag_ignore_all() instead of per file") and reverted in
commit 290d16104575 ("Revert "drm/i915: use localized
__diag_ignore_all() instead of per file""). The issue turned out to be
in __diag_ignore_all() and it was fixed by commit 689b097a06ba
("compiler-gcc: Suppress -Wmissing-prototypes warning for all supported
GCC"). So we should be able to pull this off now.
Cc: "Arnd Bergmann"
Cc: Lucas De Marchi
Signed-off-by: Jani Nikula
great! I had a vague memory of us using these localized warning-suppress
rather than doing it on the entire files.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
Re: [PATCH i-g-t] lib/kunit: Read results from debugfs
On Wed, Mar 27, 2024 at 10:54:53PM +0100, Janusz Krzysztofik wrote:
>+static DIR *kunit_debugfs_open(void)
>+{
>+ const char *debugfs_path = igt_debugfs_mount();
>+ int debugfs_fd, kunit_fd;
>+ DIR *kunit_dir;
>+
>+ if (igt_debug_on(!debugfs_path))
>+ return NULL;
>+
>+ debugfs_fd = open(debugfs_path, O_DIRECTORY);
>+ if (igt_debug_on(debugfs_fd < 0))
>+ return NULL;
>+
>+ kunit_fd = openat(debugfs_fd, "kunit", O_DIRECTORY);
>+ close(debugfs_fd);
>+ if (igt_debug_on(kunit_fd < 0))
>+ return NULL;
>+
>+ kunit_dir = fdopendir(kunit_fd);
>+ if (igt_debug_on(!kunit_dir))
>+ close(kunit_fd);
>+
>+ return kunit_dir;
any reason not to use strcat() + return fopen()
To me the code looked simpler than if I copied and concatenated strings to a
local buffer of fixed size with potential truncation handling. I guess
you prefer your pattern over mine, but you haven't explained why. Would you
like to convince me?
not really important. It just seems simpler to me, with no calls into
the kernel... completely untested, but something like:
const char *debugfs_path = igt_debugfs_mount();
char path[PATH_MAX];
if (igt_debug_on(!debugfs_path || (strlen(debugfs_path) + strlen("/kunit")
>= PATH_MAX)))
return NULL;
strcat(stpcpy(path, debugfs_path), "/kunit");
return opendir(path);
Lucas De Marchi
Re: [PATCH i-g-t] lib/kunit: Read results from debugfs
test *tst,
const char *suite,
const char *opts,
+ DIR *debugfs_dir,
struct igt_ktap_results **ktap)
{
- struct sigaction sigalrm = { .sa_handler = kunit_get_tests_timeout, },
-*saved;
struct igt_ktap_result *r, *rn;
+ struct dirent *subdir;
unsigned long taints;
- int flags, err;
-
- igt_skip_on_f(tst->kmsg < 0, "Could not open /dev/kmsg\n");
+ int debugfs_fd;
- igt_skip_on((flags = fcntl(tst->kmsg, F_GETFL, 0), flags < 0));
- igt_skip_on_f(fcntl(tst->kmsg, F_SETFL, flags & ~O_NONBLOCK) == -1,
- "Could not set /dev/kmsg to blocking mode\n");
-
- igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
+ if (igt_debug_on(!debugfs_dir))
+ return false;
/*
* To get a list of test cases provided by a kunit test module, ask the
@@ -1260,19 +1308,32 @@ static bool kunit_get_tests(struct igt_list_head *tests,
if (igt_debug_on(!kunit_set_filtering(suite, "module=none", "skip")))
return false;
+ if (!suite) {
+ seekdir(debugfs_dir, 2);/* directory itself and its
parent */
+ errno = 0;
+ igt_skip_on_f(readdir(debugfs_dir) || errno,
+ "Require empty KUnit debugfs directory\n");
+ rewinddir(debugfs_dir);
+ }
+
igt_skip_on(modprobe(tst->kmod, opts));
igt_skip_on(igt_kernel_tainted());
- igt_skip_on(sigaction(SIGALRM, , saved));
- alarm(10);
+ debugfs_fd = dirfd(debugfs_dir);
+ if (suite) {
+ igt_skip_on(kunit_get_results(tests, debugfs_fd, suite, ktap));
instead of skipping, do we need to treat it specially if this returns
-EINPROGRESS? That would probably be bug in our ktap parser or a format
change or something like that so we may want to start failing rather
than skipping.
anyway, consider the comments above as just nits. This seems like a
great improvement.
Reviewed-by: Lucas De Marchi
thanks
Lucas De Marchi
- err = kunit_get_results(tests, tst->kmsg, ktap);
+ } else while (subdir = readdir(debugfs_dir), subdir) {
+ if (!(subdir->d_type & DT_DIR))
+ continue;
- alarm(0);
- igt_debug_on(sigaction(SIGALRM, saved, NULL));
+ if (!strcmp(subdir->d_name, ".") || !strcmp(subdir->d_name,
".."))
+ continue;
- igt_skip_on_f(err,
- "KTAP parser failed while getting a list of test
cases\n");
+ igt_warn_on_f(kunit_get_results(tests, debugfs_fd,
subdir->d_name, ktap),
+ "parsing KTAP report from test suite \"%s\"
failed\n",
+ subdir->d_name);
+ }
igt_list_for_each_entry_safe(r, rn, tests, link)
igt_require_f(r->code == IGT_EXIT_SKIP,
@@ -1287,6 +1348,7 @@ static void __igt_kunit(struct igt_ktest *tst,
const char *subtest,
const char *suite,
const char *opts,
+ int debugfs_fd,
struct igt_list_head *tests,
struct igt_ktap_results **ktap)
{
@@ -1307,8 +1369,6 @@ static void __igt_kunit(struct igt_ktest *tst,
igt_skip_on(igt_kernel_tainted());
- igt_fail_on(lseek(tst->kmsg, 0, SEEK_END) == -1 &&
errno);
-
igt_assert_lt(snprintf(glob, sizeof(glob), "%s.%s",
t->suite_name, t->case_name),
sizeof(glob));
@@ -1317,7 +1377,8 @@ static void __igt_kunit(struct igt_ktest *tst,
igt_assert_eq(modprobe(tst->kmod, opts), 0);
igt_assert_eq(igt_kernel_tainted(), 0);
- igt_assert_eq(kunit_get_results(, tst->kmsg,
ktap), 0);
+ igt_assert_eq(kunit_get_results(, debugfs_fd,
+ t->suite_name, ktap),
0);
for (i = 0; i < 2; i++) {
kunit_result_free(, _name, _name);
@@ -1388,6 +1449,7 @@ void igt_kunit(const char *module_name, const char
*suite, const char *opts)
struct igt_ktest tst = { .kmsg = -1, };
struct igt_ktap_results *ktap = NULL;
const char *subtest = suite;
+ DIR *debugfs_dir = NULL;
IGT_LIST_HEAD(tests);
/*
@@ -1435,10 +1497,12 @@ void igt_kunit(const char *module_name, const char
*suite, const char *opts)
* LTS kernels not capable of using K
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc2. drm-xe-fixes-2024-03-26: - Fix build on mips - Fix wrong bound checks - Fix use of msec rather than jiffies - Remove dead code 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://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-03-26 for you to fetch changes up to 0d8cf0c924732a045273c6aca6900a340ac88529: drm/xe: Fix END redefinition (2024-03-25 13:47:48 -0500) - Fix build on mips - Fix wrong bound checks - Fix use of msec rather than jiffies - Remove dead code Lucas De Marchi (1): drm/xe: Fix END redefinition Matthew Auld (5): drm/xe/guc_submit: use jiffies for job timeout drm/xe/queue: fix engine_class bounds check drm/xe/device: fix XE_MAX_GT_PER_TILE check drm/xe/device: fix XE_MAX_TILES_PER_DEVICE check drm/xe/query: fix gt_id bounds check Nirmoy Das (1): drm/xe: Remove unused xe_bo->props struct drivers/gpu/drm/xe/xe_bo.c | 59 ++ drivers/gpu/drm/xe/xe_bo_types.h | 19 drivers/gpu/drm/xe/xe_device.h | 4 +-- drivers/gpu/drm/xe/xe_exec_queue.c | 2 +- drivers/gpu/drm/xe/xe_guc_submit.c | 2 +- drivers/gpu/drm/xe/xe_lrc.c| 20 ++--- drivers/gpu/drm/xe/xe_query.c | 2 +- 7 files changed, 23 insertions(+), 85 deletions(-)
[PATCH] drm/i915: Delete stray .rej file
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej was incorrectly added to
the tree after solving a conflict. Remove it.
Fixes: 326e30e4624c ("drm/i915: Drop dead code for pvc")
Reported-by: Stephen Rothwell
Closes: https://lore.kernel.org/r/20240325083435.4f970...@canb.auug.org.au
Cc: Jani Nikula
Signed-off-by: Lucas De Marchi
---
.../gpu/drm/i915/gt/intel_workarounds.c.rej| 18 --
1 file changed, 18 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
b/drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
deleted file mode 100644
index 91463b1d684a..
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
+++ /dev/null
@@ -1,18 +0,0 @@
-diff a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c (rejected hunks)
-@@ -2844,14 +2767,13 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
-
- if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
- IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0) ||
-- IS_PONTEVECCHIO(i915) ||
- IS_DG2(i915)) {
- /* Wa_22014226127 */
- wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
DISABLE_D8_D16_COASLESCE);
- }
-
-- if (IS_PONTEVECCHIO(i915) || IS_DG2(i915))
-- /* Wa_14015227452:dg2,pvc */
-+ if (IS_DG2(i915))
-+ /* Wa_14015227452 */
- wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN4, XEHP_DIS_BBL_SYSPIPE);
-
- if (IS_DG2(i915)) {
--
2.43.0
Re: [CI 0/6] drm/i915: cleanup dead code
On Mon, Mar 25, 2024 at 11:56:51AM +0200, Jani Nikula wrote: On Tue, 19 Mar 2024, Lucas De Marchi wrote: .../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 + create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej Whoops. [1] argh... sorry about that. Should I just amend the commit removing it? Or a real fix on top? Lucas De Marchi BR, Jani. [1] https://lore.kernel.org/r/20240325083435.4f970...@canb.auug.org.au -- Jani Nikula, Intel
Re: [CI 0/6] drm/i915: cleanup dead code
On Tue, Mar 19, 2024 at 11:02:57PM -0700, Lucas De Marchi wrote: For CI coverage. No change from previous version except the rebase. See 20240312235145.2443975-1-lucas.demar...@intel.com and 20240312235145.2443975-1-lucas.demar...@intel.com for details. I will probably wait the drm-next backmerge anyway so drm-intel-next and drm-intel-gt-next are back in sync. Unrelated failure in CI. This is now applied to drm-intel-next. Thank you all for review and acks. There were minor conflicts with drm-intel-gt-next due to workarounds applied there (and still not in drm-next). Lucas De Marchi
Re: [PATCH] drm/xe/display: check for error on drmm_mutex_init
On Thu, Mar 21, 2024 at 11:31:24AM +0530, Arun R Murthy wrote:
Check return value for drmm_mutex_init as it can fail and return on
failure.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/xe/display/xe_display.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index e4db069f0db3..ac2e58d1fa82 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -107,12 +107,14 @@ int xe_display_create(struct xe_device *xe)
xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
- drmm_mutex_init(>drm, >sb_lock);
- drmm_mutex_init(>drm, >display.backlight.lock);
- drmm_mutex_init(>drm, >display.audio.mutex);
- drmm_mutex_init(>drm, >display.wm.wm_mutex);
- drmm_mutex_init(>drm, >display.pps.mutex);
- drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
+ if ((drmm_mutex_init(>drm, >sb_lock)) ||
^^
you only need 2 parenthesis if you were going to record the return.
Lucas De Marchi
Re: [PATCH] drm/i915/display: move dmc_firmware_path to display params
On Fri, Mar 22, 2024 at 11:06:20AM -0500, Lucas De Marchi wrote:
On Fri, Mar 22, 2024 at 10:48:43AM +0200, Jani Nikula wrote:
On Thu, 21 Mar 2024, Lucas De Marchi wrote:
On Thu, Mar 21, 2024 at 06:20:57PM +0200, Jani Nikula wrote:
On Thu, 21 Mar 2024, Jani Nikula wrote:
The dmc_firmware_path parameter is clearly a display parameter. Move it
there. This also cleans up the ugly member in struct xe_device.
Hmm, does this actually fix the parameter on xe?!
not sure what you meant here. Patches makes sense to me.
Unless I'm mistaken, the parameter currently does not work on xe at
all. I only realized after posting the patch that this probably fixes
that issue too.
+Gustavo
I never really tried the dmc_firmware_path param, but current code
contains:
drivers/gpu/drm/i915/display/intel_dmc.c: if (err == -ENOENT &&
!i915->params.dmc_firmware_path) {
drivers/gpu/drm/i915/display/intel_dmc.c: if
(i915->params.dmc_firmware_path) {
drivers/gpu/drm/i915/display/intel_dmc.c: if
(strlen(i915->params.dmc_firmware_path) == 0) {
drivers/gpu/drm/i915/display/intel_dmc.c: dmc->fw_path =
i915->params.dmc_firmware_path;
drivers/gpu/drm/i915/i915_params.c:i915_param_named_unsafe(dmc_firmware_path,
charp, 0400,
drivers/gpu/drm/i915/i915_params.h: param(char *, dmc_firmware_path, NULL,
0400) \
drivers/gpu/drm/xe/xe_device_types.h: const char *dmc_firmware_path;
So dmc_firmware_path is only dealt with inside display... it would be
odd if it was not working. I'll double check.
oh, now I understand. You mean that xe module doesn't have the param
because it's only declared in drivers/gpu/drm/i915/i915_params.c.
Could you extend the commit message with something like this?
The dmc_firmware_path parameter is clearly a display parameter. Move it
there so it's available to both i915 and xe modules ....
thanks
Reviewed-by: Lucas De Marchi
Lucas De Marchi
Lucas De Marchi
Re: [PATCH] drm/i915/display: move dmc_firmware_path to display params
On Fri, Mar 22, 2024 at 10:48:43AM +0200, Jani Nikula wrote:
On Thu, 21 Mar 2024, Lucas De Marchi wrote:
On Thu, Mar 21, 2024 at 06:20:57PM +0200, Jani Nikula wrote:
On Thu, 21 Mar 2024, Jani Nikula wrote:
The dmc_firmware_path parameter is clearly a display parameter. Move it
there. This also cleans up the ugly member in struct xe_device.
Hmm, does this actually fix the parameter on xe?!
not sure what you meant here. Patches makes sense to me.
Unless I'm mistaken, the parameter currently does not work on xe at
all. I only realized after posting the patch that this probably fixes
that issue too.
+Gustavo
I never really tried the dmc_firmware_path param, but current code
contains:
drivers/gpu/drm/i915/display/intel_dmc.c: if (err == -ENOENT &&
!i915->params.dmc_firmware_path) {
drivers/gpu/drm/i915/display/intel_dmc.c: if
(i915->params.dmc_firmware_path) {
drivers/gpu/drm/i915/display/intel_dmc.c: if
(strlen(i915->params.dmc_firmware_path) == 0) {
drivers/gpu/drm/i915/display/intel_dmc.c: dmc->fw_path =
i915->params.dmc_firmware_path;
drivers/gpu/drm/i915/i915_params.c:i915_param_named_unsafe(dmc_firmware_path,
charp, 0400,
drivers/gpu/drm/i915/i915_params.h: param(char *, dmc_firmware_path, NULL,
0400) \
drivers/gpu/drm/xe/xe_device_types.h: const char *dmc_firmware_path;
So dmc_firmware_path is only dealt with inside display... it would be
odd if it was not working. I'll double check.
Lucas De Marchi
Re: [PATCH] drm/i915/display: move dmc_firmware_path to display params
On Thu, Mar 21, 2024 at 06:20:57PM +0200, Jani Nikula wrote:
On Thu, 21 Mar 2024, Jani Nikula wrote:
The dmc_firmware_path parameter is clearly a display parameter. Move it
there. This also cleans up the ugly member in struct xe_device.
Hmm, does this actually fix the parameter on xe?!
not sure what you meant here. Patches makes sense to me.
Lucas De Marchi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_params.c | 3 +++
drivers/gpu/drm/i915/display/intel_display_params.h | 1 +
drivers/gpu/drm/i915/display/intel_dmc.c| 8
drivers/gpu/drm/i915/i915_params.c | 3 ---
drivers/gpu/drm/i915/i915_params.h | 1 -
drivers/gpu/drm/xe/xe_device_types.h| 3 ---
6 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_params.c
b/drivers/gpu/drm/i915/display/intel_display_params.c
index 11e03cfb774d..c8e3d6892e23 100644
--- a/drivers/gpu/drm/i915/display/intel_display_params.c
+++ b/drivers/gpu/drm/i915/display/intel_display_params.c
@@ -27,6 +27,9 @@ static struct intel_display_params intel_display_modparams
__read_mostly = {
* debugfs mode to 0.
*/
+intel_display_param_named_unsafe(dmc_firmware_path, charp, 0400,
+ "DMC firmware path to use instead of the default one");
+
intel_display_param_named_unsafe(vbt_firmware, charp, 0400,
"Load VBT from specified file under /lib/firmware");
diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h
b/drivers/gpu/drm/i915/display/intel_display_params.h
index 6206cc51df04..f95a6f79904f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_params.h
+++ b/drivers/gpu/drm/i915/display/intel_display_params.h
@@ -24,6 +24,7 @@ struct drm_i915_private;
* debugfs file
*/
#define INTEL_DISPLAY_PARAMS_FOR_EACH(param) \
+ param(char *, dmc_firmware_path, NULL, 0400) \
param(char *, vbt_firmware, NULL, 0400) \
param(int, lvds_channel_mode, 0, 0400) \
param(int, panel_use_ssc, -1, 0600) \
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 3fa851b5c7a6..b4e730882ce2 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -927,7 +927,7 @@ static void dmc_load_work_fn(struct work_struct *work)
err = request_firmware(, dmc->fw_path, i915->drm.dev);
- if (err == -ENOENT && !i915->params.dmc_firmware_path) {
+ if (err == -ENOENT && !i915->display.params.dmc_firmware_path) {
fallback_path = dmc_fallback_path(i915);
if (fallback_path) {
drm_dbg_kms(>drm, "%s not found, falling back to
%s\n",
@@ -1034,14 +1034,14 @@ void intel_dmc_init(struct drm_i915_private *i915)
dmc->max_fw_size = BXT_DMC_MAX_FW_SIZE;
}
- if (i915->params.dmc_firmware_path) {
- if (strlen(i915->params.dmc_firmware_path) == 0) {
+ if (i915->display.params.dmc_firmware_path) {
+ if (strlen(i915->display.params.dmc_firmware_path) == 0) {
drm_info(>drm,
"Disabling DMC firmware and runtime PM\n");
goto out;
}
- dmc->fw_path = i915->params.dmc_firmware_path;
+ dmc->fw_path = i915->display.params.dmc_firmware_path;
}
if (!dmc->fw_path) {
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index de43048543e8..8c00169e3ab7 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -108,9 +108,6 @@ i915_param_named_unsafe(guc_firmware_path, charp, 0400,
i915_param_named_unsafe(huc_firmware_path, charp, 0400,
"HuC firmware path to use instead of the default one");
-i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
- "DMC firmware path to use instead of the default one");
-
i915_param_named_unsafe(gsc_firmware_path, charp, 0400,
"GSC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 1315d7fac850..2eb3f2115ff2 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -51,7 +51,6 @@ struct drm_printer;
param(int, guc_log_level, -1, 0400) \
param(char *, guc_firmware_path, NULL, 0400) \
param(char *, huc_firmware_path, NULL, 0400) \
- param(char *, dmc_firmware_path, NULL, 0400) \
param(char *, gsc_firmware_path, NULL, 0400) \
param(bool, memtest, false, 0400) \
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO), 0600) \
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device
Re: [PATCH] drm/xe/display: check for error on drmm_mutex_init
On Thu, Mar 21, 2024 at 05:04:51AM +, Murthy, Arun R wrote:
-Original Message-
From: De Marchi, Lucas
Sent: Wednesday, March 20, 2024 6:06 AM
To: Murthy, Arun R
Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
Subject: Re: [PATCH] drm/xe/display: check for error on drmm_mutex_init
On Tue, Mar 19, 2024 at 08:33:41AM +0530, Arun R Murthy wrote:
>Check return value for drmm_mutex_init as it can fail and return on
>failure.
>
>Signed-off-by: Arun R Murthy
>---
> drivers/gpu/drm/xe/display/xe_display.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/gpu/drm/xe/display/xe_display.c
>b/drivers/gpu/drm/xe/display/xe_display.c
>index e4db069f0db3..c59fa832758d 100644
>--- a/drivers/gpu/drm/xe/display/xe_display.c
>+++ b/drivers/gpu/drm/xe/display/xe_display.c
>@@ -107,12 +107,24 @@ int xe_display_create(struct xe_device *xe)
>
>xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
>
>- drmm_mutex_init(>drm, >sb_lock);
>- drmm_mutex_init(>drm, >display.backlight.lock);
>- drmm_mutex_init(>drm, >display.audio.mutex);
>- drmm_mutex_init(>drm, >display.wm.wm_mutex);
>- drmm_mutex_init(>drm, >display.pps.mutex);
>- drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
>+ err = drmm_mutex_init(>drm, >sb_lock);
>+ if (err)
>+ return err;
>+ err = drmm_mutex_init(>drm, >display.backlight.lock);
>+ if (err)
>+ return err;
>+ err = drmm_mutex_init(>drm, >display.audio.mutex);
>+ if (err)
>+ return err;
>+ err = drmm_mutex_init(>drm, >display.wm.wm_mutex);
>+ if (err)
>+ return err;
>+ err = drmm_mutex_init(>drm, >display.pps.mutex);
>+ if (err)
>+ return err;
>+ err = drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
>+ if (err)
>+ return err;
humn... but not very pretty. What about?
if ((err = drmm_mutex_init(>drm, >sb_lock)) ||
(err = drmm_mutex_init(>drm, >display.backlight.lock)) ||
(err = ...))
return err;
I think there are few places in life for assignment + check in single statement,
but IMO this is one of them where the alternative is uglier and more error
prone.
thoughts?
We should not proceed with the remaining mutex_init in case of failures. As an
alternative we can have
with the code above, we are not proceeding with the other drmm_mutex_init()
initializations.
foo() || bar() doesn't execute bar() if foo() returned != 0.
Lucas De Marchi
drmm_mutex_init(var1) ? (drmm_mutex_init(var2) ? drmm_mutex_init(var3) : return
ret) : return ret;
With the existing one traversing the code is more easier, these optimization
might make the code look complex.
Thanks and Regards,
Arun R Murthy
Lucas De Marchi
>xe->enabled_irq_mask = ~0;
>
>err = drmm_add_action_or_reset(>drm, display_destroy, NULL);
>--
>2.25.1
>
[CI 5/6] drm/i915: Drop dead code for pvc
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.
Reviewed-by: Rodrigo Vivi
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 | 82 +-
.../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 +++
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 -
22 files changed, 27 insertions(+), 480 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
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 0c5cdab278b69..1495b60744928 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. TGL_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 f59914df6b5a7..e9f65f27b53fb 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 75bde8c1aa5da..396f5fe993c3f 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(stru
[CI 6/6] drm/i915: Remove special handling for !RCS_MASK()
With both XEHPSDV and PVC removed (as platforms, most of their code remain used by others), there's no need to handle !RCS_MASK() as other platforms don't ever have fused-off render. Remove those code paths and the special WA flag when initializing GuC. Reviewed-by: Matt Roper Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 396f5fe993c3f..476651bd0a210 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -497,9 +497,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->logical_mask = BIT(logical_instance); __sprint_engine_name(engine); - if ((engine->class == COMPUTE_CLASS && !RCS_MASK(engine->gt) && -__ffs(CCS_MASK(engine->gt)) == engine->instance) || -engine->class == RENDER_CLASS) + if ((engine->class == COMPUTE_CLASS || engine->class == RENDER_CLASS) && + __ffs(CCS_MASK(engine->gt) | RCS_MASK(engine->gt)) == engine->instance) engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE; /* features common between engines sharing EUs */ diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index 217277329546c..3dd7699f2ad3b 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -320,10 +320,6 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) if (IS_DG2_G11(gt->i915)) flags |= GUC_WA_CONTEXT_ISOLATION; - /* Wa_18020744125 */ - if (!RCS_MASK(gt)) - flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST; - /* * Wa_14018913170: Applicable to all platforms supported by i915 so * don't bother testing for all X/Y/Z platforms explicitly. -- 2.43.0
[CI 1/6] drm/i915: Drop dead code for xehpsdv
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.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
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 | 23 +
drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 -
.../gpu/drm/xe/compat-i915-headers/i915_drv.h | 2 -
24 files changed, 55 insertions(+), 384 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
index 8a8fcd4fceac6..bc26dc1261041 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 fa46d2308b0ed..1bd0e041e15c2 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(0, pat_index, flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
- xehpsdv_ppgtt_insert_huge(vm, vma_res, ,
pat_index, flags);
+ if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 55))
+ xehp_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
else
gen8_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
} else {
@@ -781,11 +781,11 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
-static void __xehpsdv_ppgtt_insert_entry_lm(struct i915_address_space *vm,
- dma_addr_t addr,
-
[CI 4/6] drm/i915: Update IP_VER(12, 50)
With no platform using graphics/media IP_VER(12, 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.
Reviewed-by: Rodrigo Vivi
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_perf.c | 8
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 2 +-
23 files changed, 46 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 3ff3d8889c6cc..edb54903be0a2 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 10a7847f1b049..bac15196b4d24 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))
+ if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
IP_VER(12, 55))
dst_4t = XY_FAST_COPY_BLT_D1_DST_TILE4;
} else if (dst->tiling == CLIENT_TILING_X) {
dst_tiles = XY_FAST_COPY_BLT_D0_DST_TILE_MODE(TILE_X);
@@ -365,7 +365,7 @@ static u64 tiled_offset(const struct intel_gt
[CI 3/6] drm/i915: Stop inheriting IP_VER(12, 50)
All the platforms that inherit the media/graphics version
from XE_HPM_FEATURES / XE_HP_FEATURES just override it to another
version. Just set the version directly in the respective struct
and remove the versions from the _FEATURES macros. Since that was the
only use for XE_HPM_FEATURES, remove it completely.
Reviewed-by: Gustavo Sousa
Reviewed-by: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pci.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b318b7c6bf737..8b673fdcf178f 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -705,8 +705,6 @@ static const struct intel_device_info adl_p_info = {
I915_GTT_PAGE_SIZE_2M
#define XE_HP_FEATURES \
- .__runtime.graphics.ip.ver = 12, \
- .__runtime.graphics.ip.rel = 50, \
XE_HP_PAGE_SIZES, \
TGL_CACHELEVEL, \
.dma_mask_size = 46, \
@@ -730,15 +728,12 @@ static const struct intel_device_info adl_p_info = {
.__runtime.ppgtt_size = 48, \
.__runtime.ppgtt_type = INTEL_PPGTT_FULL
-#define XE_HPM_FEATURES \
- .__runtime.media.ip.ver = 12, \
- .__runtime.media.ip.rel = 50
-
#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, \
PLATFORM(INTEL_DG2), \
.has_64k_pages = 1, \
@@ -773,9 +768,10 @@ static const struct intel_device_info ats_m_info = {
__maybe_unused
static const struct intel_device_info pvc_info = {
XE_HPC_FEATURES,
- XE_HPM_FEATURES,
DGFX_FEATURES,
+ .__runtime.graphics.ip.ver = 12,
.__runtime.graphics.ip.rel = 60,
+ .__runtime.media.ip.ver = 12,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
.has_flat_ccs = 0,
--
2.43.0
[CI 2/6] drm/i915: Remove XEHP_FWRANGES()
Now that DG2 is the only user of this forcewake table, remove the macro
and use FORCEWAKE_RENDER explicitly for range 0xd800 - 0xd87f.
Suggested-by: Matt Roper
Reviewed-by: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_uncore.c | 297 ++--
1 file changed, 145 insertions(+), 152 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 7695bb946fff4..b525318dbd53b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1471,159 +1471,152 @@ static const struct intel_forcewake_range
__gen12_fw_ranges[] = {
0x1d3f00 - 0x1d3fff: VD2 */
};
-/*
- * Graphics IP version 12.55 brings a slight change to the 0xd800 range,
- * switching it from the GT domain to the render domain.
- */
-#define XEHP_FWRANGES(FW_RANGE_D800) \
- GEN_FW_RANGE(0x0, 0x1fff, 0), /*
\
- 0x0 - 0xaff: reserved
\
- 0xb00 - 0x1fff: always on */
\
- GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x2700, 0x4aff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x4b00, 0x51ff, 0), /*
\
- 0x4b00 - 0x4fff: reserved
\
- 0x5000 - 0x51ff: always on */
\
- GEN_FW_RANGE(0x5200, 0x7fff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8000, 0x813f, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x8140, 0x815f, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8160, 0x81ff, 0), /*
\
- 0x8160 - 0x817f: reserved
\
- 0x8180 - 0x81ff: always on */
\
- GEN_FW_RANGE(0x8200, 0x82ff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x8300, 0x84ff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8500, 0x8cff, FORCEWAKE_GT), /*
\
- 0x8500 - 0x87ff: gt
\
- 0x8800 - 0x8c7f: reserved
\
- 0x8c80 - 0x8cff: gt (DG2 only) */
\
- GEN_FW_RANGE(0x8d00, 0x8fff, FORCEWAKE_RENDER), /*
\
- 0x8d00 - 0x8dff: render (DG2 only)
\
- 0x8e00 - 0x8fff: reserved */
\
- GEN_FW_RANGE(0x9000, 0x94cf, FORCEWAKE_GT), /*
\
- 0x9000 - 0x947f: gt
\
- 0x9480 - 0x94cf: reserved */
\
- GEN_FW_RANGE(0x94d0, 0x955f, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x9560, 0x967f, 0), /*
\
- 0x9560 - 0x95ff: always on
\
- 0x9600 - 0x967f: reserved */
\
- GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /*
\
- 0x9680 - 0x96ff: render (DG2 only)
\
- 0x9700 - 0x97ff: reserved */
\
- GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /*
\
- 0x9800 - 0xb4ff: gt
\
- 0xb500 - 0xbfff: reserved
\
- 0xc000 - 0xcfff: gt */
\
- GEN_FW_RANGE(0xd000, 0xd7ff, 0),
\
- GEN_FW_RANGE(0xd800, 0xd87f, FW_RANGE_D800),\
- GEN_FW_RANGE(0xd880, 0xdbff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0xdc00, 0xdcff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0xdd00, 0xde7f, FORCEWAKE_GT), /*
\
- 0xdd00 - 0xddff: gt
\
- 0xde00 - 0xde7f: reserved */
\
- GEN_FW_RANGE(0xde80, 0xe8ff, FORCEWAKE_RENDER), /*
\
- 0xde80 - 0xdfff: render
\
- 0xe000 - 0xe0ff: reserved
\
- 0xe100 - 0xe8ff: render */
\
- GEN_FW_RANGE(0xe900, 0x, FORCEWAKE_GT
[CI 0/6] drm/i915: cleanup dead code
For CI coverage. No change from previous version except the rebase. See 20240312235145.2443975-1-lucas.demar...@intel.com and 20240312235145.2443975-1-lucas.demar...@intel.com for details. I will probably wait the drm-next backmerge anyway so drm-intel-next and drm-intel-gt-next are back in sync. Lucas De Marchi (6): 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() Documentation/gpu/rfc/i915_vm_bind.h | 11 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +- .../i915/gem/selftests/i915_gem_client_blt.c | 8 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +- .../drm/i915/gt/intel_execlists_submission.c | 10 +- drivers/gpu/drm/i915/gt/intel_gsc.c | 15 - drivers/gpu/drm/i915/gt/intel_gt.c| 4 +- drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 52 +-- drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 59 --- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 21 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 51 +-- drivers/gpu/drm/i915/gt/intel_migrate.c | 22 +- drivers/gpu/drm/i915/gt/intel_mocs.c | 52 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 6 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 13 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 181 + .../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 6 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 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 | 13 - drivers/gpu/drm/i915/i915_getparam.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 5 +- drivers/gpu/drm/i915/i915_hwmon.c | 6 - drivers/gpu/drm/i915/i915_pci.c | 61 +-- drivers/gpu/drm/i915/i915_perf.c | 19 +- drivers/gpu/drm/i915/i915_query.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 4 +- drivers/gpu/drm/i915/intel_clock_gating.c | 26 +- drivers/gpu/drm/i915/intel_device_info.c | 2 - drivers/gpu/drm/i915/intel_device_info.h | 2 - drivers/gpu/drm/i915/intel_step.c | 80 +--- drivers/gpu/drm/i915/intel_uncore.c | 380 +- drivers/gpu/drm/i915/selftests/intel_uncore.c | 3 - .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 6 - 43 files changed, 232 insertions(+), 1032 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej -- 2.43.0
Re: [PATCH v2 6/6] drm/i915: Remove special handling for !RCS_MASK()
On Thu, Mar 14, 2024 at 01:57:46PM -0700, Matt Roper wrote: On Tue, Mar 12, 2024 at 04:51:45PM -0700, Lucas De Marchi wrote: With both XEHPSDV and PVC removed (as platforms, most of their code remain used by others), there's no need to handle !RCS_MASK() as other platforms don't ever have fused-off render. Remove those code paths and the special WA flag when initializing GuC. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 - 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 396f5fe993c3..476651bd0a21 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -497,9 +497,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->logical_mask = BIT(logical_instance); __sprint_engine_name(engine); - if ((engine->class == COMPUTE_CLASS && !RCS_MASK(engine->gt) && -__ffs(CCS_MASK(engine->gt)) == engine->instance) || -engine->class == RENDER_CLASS) + if ((engine->class == COMPUTE_CLASS || engine->class == RENDER_CLASS) && + __ffs(CCS_MASK(engine->gt) | RCS_MASK(engine->gt)) == engine->instance) engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE; Given that we expect all i915 platforms to have a render engine now, we could simplify this down to just if (engine->class == RENDER) engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE; makes sense, but I'd rather add a patch on top to get rid of I915_ENGINE_FIRST_RENDER_COMPUTE and make this assumption "we always have a render engine" explicit. It seems that there's more that can be simplified when we do that. But either way, Reviewed-by: Matt Roper I will keep this patch as is for now. Thanks Lucas De Marchi /* features common between engines sharing EUs */ diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index 217277329546..3dd7699f2ad3 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -320,10 +320,6 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) if (IS_DG2_G11(gt->i915)) flags |= GUC_WA_CONTEXT_ISOLATION; - /* Wa_18020744125 */ - if (!RCS_MASK(gt)) - flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST; - /* * Wa_14018913170: Applicable to all platforms supported by i915 so * don't bother testing for all X/Y/Z platforms explicitly. diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h index 14797e80bc92..1ad31a743197 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h @@ -101,7 +101,6 @@ #define GUC_WA_RCS_CCS_SWITCHOUT BIT(16) #define GUC_WA_HOLD_CCS_SWITCHOUTBIT(17) #define GUC_WA_POLLCSBIT(18) -#define GUC_WA_RCS_REGS_IN_CCS_REGS_LIST BIT(21) #define GUC_WA_ENABLE_TSC_CHECK_ON_RC6 BIT(22) #define GUC_CTL_FEATURE2 -- 2.43.0 -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH] drm/xe/display: check for error on drmm_mutex_init
On Tue, Mar 19, 2024 at 08:33:41AM +0530, Arun R Murthy wrote:
Check return value for drmm_mutex_init as it can fail and return on
failure.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/xe/display/xe_display.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display.c
b/drivers/gpu/drm/xe/display/xe_display.c
index e4db069f0db3..c59fa832758d 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -107,12 +107,24 @@ int xe_display_create(struct xe_device *xe)
xe->display.hotplug.dp_wq = alloc_ordered_workqueue("xe-dp", 0);
- drmm_mutex_init(>drm, >sb_lock);
- drmm_mutex_init(>drm, >display.backlight.lock);
- drmm_mutex_init(>drm, >display.audio.mutex);
- drmm_mutex_init(>drm, >display.wm.wm_mutex);
- drmm_mutex_init(>drm, >display.pps.mutex);
- drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
+ err = drmm_mutex_init(>drm, >sb_lock);
+ if (err)
+ return err;
+ err = drmm_mutex_init(>drm, >display.backlight.lock);
+ if (err)
+ return err;
+ err = drmm_mutex_init(>drm, >display.audio.mutex);
+ if (err)
+ return err;
+ err = drmm_mutex_init(>drm, >display.wm.wm_mutex);
+ if (err)
+ return err;
+ err = drmm_mutex_init(>drm, >display.pps.mutex);
+ if (err)
+ return err;
+ err = drmm_mutex_init(>drm, >display.hdcp.hdcp_mutex);
+ if (err)
+ return err;
humn... but not very pretty. What about?
if ((err = drmm_mutex_init(>drm, >sb_lock)) ||
(err = drmm_mutex_init(>drm, >display.backlight.lock)) ||
(err = ...))
return err;
I think there are few places in life for assignment + check in single
statement, but IMO this is one of them where the alternative is uglier
and more error prone.
thoughts?
Lucas De Marchi
xe->enabled_irq_mask = ~0;
err = drmm_add_action_or_reset(>drm, display_destroy, NULL);
--
2.25.1
Re: [PATCH] drm/xe/display: fix type of intel_uncore_read*() functions
On Thu, Mar 14, 2024 at 08:52:21AM +0200, Luca Coelho wrote: Some of the backported intel_uncore_read*() functions used the wrong types. Change the function declarations accordingly. Reviewed-by: Gustavo Sousa Signed-off-by: Luca Coelho if a patch affects xe, please always Cc the xe mailing list so it triggers CI on those machines Lucas De Marchi
[PULL] drm-xe-next-fixes
Hi Dave and Sima, Here are the drm-xe fixes for the 6.9 cycle. Just 3 fixes: one trivial fix for error path handling, one to avoid pinning all VMAs in drm_gpuvm_exec_lock() when num_batch_buffer passed to xe_exec is 0 and the other to allow userspace to free userptr while still having bindings. Lucas De Marchi drm-xe-next-fixes-2024-03-14: Driver changes: - Invalidate userptr VMA on page pin fault, allowing userspace to free userptr while still having bindings - Fail early on sysfs file creation error - Skip VMA pinning on xe_exec with num_batch_buffer == 0 The following changes since commit e62d2e00780b4a465c77d2229837495fcbc480d3: drm/xe: Replace 'grouped target' in Makefile with pattern rule (2024-03-04 08:41:28 -0600) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-fixes-2024-03-14 for you to fetch changes up to dd8a07f06dfd946e0eea1a3323d52e7c28a6ed80: drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC (2024-03-14 14:29:42 -0500) Driver changes: - Invalidate userptr VMA on page pin fault, allowing userspace to free userptr while still having bindings - Fail early on sysfs file creation error - Skip VMA pinning on xe_exec with num_batch_buffer == 0 Himal Prasad Ghimiray (1): drm/xe: Return if kobj creation is failed José Roberto de Souza (1): drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC Matthew Brost (1): drm/xe: Invalidate userptr VMA on page pin fault drivers/gpu/drm/xe/xe_exec.c | 41 drivers/gpu/drm/xe/xe_gt_pagefault.c | 4 ++-- drivers/gpu/drm/xe/xe_trace.h| 2 +- drivers/gpu/drm/xe/xe_vm.c | 32 +--- drivers/gpu/drm/xe/xe_vm_types.h | 7 ++ drivers/gpu/drm/xe/xe_vram_freq.c| 4 +++- 6 files changed, 55 insertions(+), 35 deletions(-)
Re: [PATCH v2 2/8] drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()
On Tue, Mar 12, 2024 at 09:49:05AM -0700, Matt Roper wrote: On Tue, Mar 12, 2024 at 01:36:33PM -0300, Gustavo Sousa wrote: Currently, only Xe2LPD uses CDCLK PLL as the source of MDCLK and previous display IPs use the CD2XCLK. There will be changes in code paths common to those platforms that will rely on which source is being used. As such, let's make that information explicit with the addition of the predicate function mdclk_source_is_cdclk_pll(). Arguably, an enum could be created, but using a boolean should suffice here, since we there are only two possible sources and the logic that will rely on it will be very localized. In order to get the code into a more consistent state, let's also take this opportunity to hook the selection of CDCLK_CTL's "MDCLK Source Select" to that new function. Even though currently only MDCLK_SOURCE_SEL_CDCLK_PLL will be returned, having this extra logic is arguably better than keeping stuff untied and prone to bugs. v2: - Extract mdclk_source_is_cdclk_pll() out of xe2lpd_mdclk_source_sel() to make latter only about the register's field. Bspec: 69090 You might also add 68861 here since that's where we find out that Xe2 I added this while applying. thanks Lucas De Marchi
Re: [PATCH v2 0/8] Enable LNL display
On Tue, 12 Mar 2024 13:36:31 -0300, Gustavo Sousa wrote: > This series aims at providing the remaining patches for enabling display > on Lunar Lake, which used Xe2LPD display IP. > > The first set of patches contains fixes and extra stuff required for > supporting CDCLK on Xe2LPD: > > drm/i915/cdclk: Rename lnl_cdclk_table to xe2lpd_cdclk_table > drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll() > drm/i915/cdclk: Only compute squash waveform when necessary > drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update() > drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state > drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changes > > [...] Applied all the patches to drm-intel-next. Thanks for the patches and reviews. [1/8] drm/i915/cdclk: Rename lnl_cdclk_table to xe2lpd_cdclk_table commit: dfdfc609bb71521ac22a2ff91f608644bf7e7b6d [2/8] drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll() commit: 5372a54d7a3cf32c761d2896276b72b495bcb497 [3/8] drm/i915/cdclk: Only compute squash waveform when necessary commit: 452269e2f0ea180a4bc39fd4643df7fe2ea0bb8e [4/8] drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update() commit: 66a0e0681392420b326f00ba732e6bda099eda29 [5/8] drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state commit: 9161e31181440e4882f78e02783e40325dc82e27 [6/8] drm/i915/xe2lpd: Support MDCLK:CDCLK ratio changes commit: c834a080a0134e7bd0cb18c3a2b0dd674794d182 [7/8] drm/i915/xe2lpd: Load DMC commit: bf1a72ab5a446e383682e34347237ee5317c2185 [8/8] drm/xe/lnl: Enable display support commit: 79263e4b3f0ed5928a1622300d32ed35f7d8fc24 Best regards, -- Lucas De Marchi
[PATCH v2 0/6] drm/i915: cleanup dead code
Remove platforms that never had their PCI IDs added to the driver and are of course marked with requiring force_probe. Note that most of the code for those platforms is actually used by subsequent ones, so it's not a huge amount of code being removed. drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h is also changed on the xe side, but that should be ok: the defines are there only for compat reasons while building the display side (and none of these platforms have display, so it's build-issue only). v2: handle feedback from Rodrigo, Tvrtko and Matt Roper, mainly - Add a patch to remove XEHP_FWRANGES() - Split out a patch touching i915_pci.c, removing the version from the _FEATURES macros - Fix holes in the forcewake tables Lucas De Marchi (6): 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() Documentation/gpu/rfc/i915_vm_bind.h | 11 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +- .../i915/gem/selftests/i915_gem_client_blt.c | 8 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +- .../drm/i915/gt/intel_execlists_submission.c | 10 +- drivers/gpu/drm/i915/gt/intel_gsc.c | 15 - drivers/gpu/drm/i915/gt/intel_gt.c| 4 +- drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 52 +-- drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 59 --- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 21 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 51 +-- drivers/gpu/drm/i915/gt/intel_migrate.c | 22 +- drivers/gpu/drm/i915/gt/intel_mocs.c | 52 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 6 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 13 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 183 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 6 +- 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_fwif.h | 1 - .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 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 | 13 - drivers/gpu/drm/i915/i915_getparam.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 5 +- drivers/gpu/drm/i915/i915_hwmon.c | 6 - drivers/gpu/drm/i915/i915_pci.c | 61 +-- drivers/gpu/drm/i915/i915_perf.c | 19 +- drivers/gpu/drm/i915/i915_query.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 4 +- drivers/gpu/drm/i915/intel_clock_gating.c | 26 +- drivers/gpu/drm/i915/intel_device_info.c | 2 - drivers/gpu/drm/i915/intel_device_info.h | 2 - drivers/gpu/drm/i915/intel_step.c | 80 +--- drivers/gpu/drm/i915/intel_uncore.c | 380 +- drivers/gpu/drm/i915/selftests/intel_uncore.c | 3 - .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 6 - 43 files changed, 215 insertions(+), 1034 deletions(-) -- 2.43.0
[PATCH v2 6/6] drm/i915: Remove special handling for !RCS_MASK()
With both XEHPSDV and PVC removed (as platforms, most of their code remain used by others), there's no need to handle !RCS_MASK() as other platforms don't ever have fused-off render. Remove those code paths and the special WA flag when initializing GuC. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 - 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 396f5fe993c3..476651bd0a21 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -497,9 +497,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->logical_mask = BIT(logical_instance); __sprint_engine_name(engine); - if ((engine->class == COMPUTE_CLASS && !RCS_MASK(engine->gt) && -__ffs(CCS_MASK(engine->gt)) == engine->instance) || -engine->class == RENDER_CLASS) + if ((engine->class == COMPUTE_CLASS || engine->class == RENDER_CLASS) && + __ffs(CCS_MASK(engine->gt) | RCS_MASK(engine->gt)) == engine->instance) engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE; /* features common between engines sharing EUs */ diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index 217277329546..3dd7699f2ad3 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -320,10 +320,6 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) if (IS_DG2_G11(gt->i915)) flags |= GUC_WA_CONTEXT_ISOLATION; - /* Wa_18020744125 */ - if (!RCS_MASK(gt)) - flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST; - /* * Wa_14018913170: Applicable to all platforms supported by i915 so * don't bother testing for all X/Y/Z platforms explicitly. diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h index 14797e80bc92..1ad31a743197 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h @@ -101,7 +101,6 @@ #define GUC_WA_RCS_CCS_SWITCHOUT BIT(16) #define GUC_WA_HOLD_CCS_SWITCHOUTBIT(17) #define GUC_WA_POLLCSBIT(18) -#define GUC_WA_RCS_REGS_IN_CCS_REGS_LIST BIT(21) #define GUC_WA_ENABLE_TSC_CHECK_ON_RC6 BIT(22) #define GUC_CTL_FEATURE2 -- 2.43.0
[PATCH v2 3/6] drm/i915: Stop inheriting IP_VER(12, 50)
All the platforms that inherit the media/graphics version
from XE_HPM_FEATURES / XE_HP_FEATURES just override it to another
version. Just set the version directly in the respective struct
and remove the versions from the _FEATURES macros. Since that was the
only use for XE_HPM_FEATURES, remove it completely.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pci.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b318b7c6bf73..8b673fdcf178 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -705,8 +705,6 @@ static const struct intel_device_info adl_p_info = {
I915_GTT_PAGE_SIZE_2M
#define XE_HP_FEATURES \
- .__runtime.graphics.ip.ver = 12, \
- .__runtime.graphics.ip.rel = 50, \
XE_HP_PAGE_SIZES, \
TGL_CACHELEVEL, \
.dma_mask_size = 46, \
@@ -730,15 +728,12 @@ static const struct intel_device_info adl_p_info = {
.__runtime.ppgtt_size = 48, \
.__runtime.ppgtt_type = INTEL_PPGTT_FULL
-#define XE_HPM_FEATURES \
- .__runtime.media.ip.ver = 12, \
- .__runtime.media.ip.rel = 50
-
#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, \
PLATFORM(INTEL_DG2), \
.has_64k_pages = 1, \
@@ -773,9 +768,10 @@ static const struct intel_device_info ats_m_info = {
__maybe_unused
static const struct intel_device_info pvc_info = {
XE_HPC_FEATURES,
- XE_HPM_FEATURES,
DGFX_FEATURES,
+ .__runtime.graphics.ip.ver = 12,
.__runtime.graphics.ip.rel = 60,
+ .__runtime.media.ip.ver = 12,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
.has_flat_ccs = 0,
--
2.43.0
[PATCH v2 5/6] drm/i915: Drop dead code for pvc
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.
Reviewed-by: Rodrigo Vivi
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 | 84 +--
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, 10 insertions(+), 481 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..1495b6074492 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. TGL_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 f59914df6b5a..e9f65f27b53f 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)
engine_mask_apply_media_fuses(gt);
engine_mask_apply_compute_fuses(gt);
- engine_mask_apply_copy_fuses(gt);
[PATCH v2 2/6] drm/i915: Remove XEHP_FWRANGES()
Now that DG2 is the only user of this forcewake table, remove the macro
and use FORCEWAKE_RENDER explicitly for range 0xd800 - 0xd87f.
Suggested-by: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_uncore.c | 297 ++--
1 file changed, 145 insertions(+), 152 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 7695bb946fff..b525318dbd53 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1471,159 +1471,152 @@ static const struct intel_forcewake_range
__gen12_fw_ranges[] = {
0x1d3f00 - 0x1d3fff: VD2 */
};
-/*
- * Graphics IP version 12.55 brings a slight change to the 0xd800 range,
- * switching it from the GT domain to the render domain.
- */
-#define XEHP_FWRANGES(FW_RANGE_D800) \
- GEN_FW_RANGE(0x0, 0x1fff, 0), /*
\
- 0x0 - 0xaff: reserved
\
- 0xb00 - 0x1fff: always on */
\
- GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x2700, 0x4aff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x4b00, 0x51ff, 0), /*
\
- 0x4b00 - 0x4fff: reserved
\
- 0x5000 - 0x51ff: always on */
\
- GEN_FW_RANGE(0x5200, 0x7fff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8000, 0x813f, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x8140, 0x815f, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8160, 0x81ff, 0), /*
\
- 0x8160 - 0x817f: reserved
\
- 0x8180 - 0x81ff: always on */
\
- GEN_FW_RANGE(0x8200, 0x82ff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0x8300, 0x84ff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x8500, 0x8cff, FORCEWAKE_GT), /*
\
- 0x8500 - 0x87ff: gt
\
- 0x8800 - 0x8c7f: reserved
\
- 0x8c80 - 0x8cff: gt (DG2 only) */
\
- GEN_FW_RANGE(0x8d00, 0x8fff, FORCEWAKE_RENDER), /*
\
- 0x8d00 - 0x8dff: render (DG2 only)
\
- 0x8e00 - 0x8fff: reserved */
\
- GEN_FW_RANGE(0x9000, 0x94cf, FORCEWAKE_GT), /*
\
- 0x9000 - 0x947f: gt
\
- 0x9480 - 0x94cf: reserved */
\
- GEN_FW_RANGE(0x94d0, 0x955f, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x9560, 0x967f, 0), /*
\
- 0x9560 - 0x95ff: always on
\
- 0x9600 - 0x967f: reserved */
\
- GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /*
\
- 0x9680 - 0x96ff: render (DG2 only)
\
- 0x9700 - 0x97ff: reserved */
\
- GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /*
\
- 0x9800 - 0xb4ff: gt
\
- 0xb500 - 0xbfff: reserved
\
- 0xc000 - 0xcfff: gt */
\
- GEN_FW_RANGE(0xd000, 0xd7ff, 0),
\
- GEN_FW_RANGE(0xd800, 0xd87f, FW_RANGE_D800),\
- GEN_FW_RANGE(0xd880, 0xdbff, FORCEWAKE_GT),
\
- GEN_FW_RANGE(0xdc00, 0xdcff, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0xdd00, 0xde7f, FORCEWAKE_GT), /*
\
- 0xdd00 - 0xddff: gt
\
- 0xde00 - 0xde7f: reserved */
\
- GEN_FW_RANGE(0xde80, 0xe8ff, FORCEWAKE_RENDER), /*
\
- 0xde80 - 0xdfff: render
\
- 0xe000 - 0xe0ff: reserved
\
- 0xe100 - 0xe8ff: render */
\
- GEN_FW_RANGE(0xe900, 0x, FORCEWAKE_GT), /*
\
- 0xe900 - 0xe9ff: gt
[PATCH v2 1/6] drm/i915: Drop dead code for xehpsdv
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.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
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 | 23 +
drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 -
.../gpu/drm/xe/compat-i915-headers/i915_drv.h | 2 -
24 files changed, 55 insertions(+), 384 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(0, pat_index, flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
- xehpsdv_ppgtt_insert_huge(vm, vma_res, ,
pat_index, flags);
+ if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 55))
+ xehp_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
else
gen8_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
} else {
@@ -781,11 +781,11 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
-static void __xehpsdv_ppgtt_insert_entry_lm(struct i915_address_space *vm,
- dma_addr_t addr,
-
[PATCH v2 4/6] drm/i915: Update IP_VER(12, 50)
With no platform using graphics/media IP_VER(12, 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.
Reviewed-by: Rodrigo Vivi
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_perf.c | 8
drivers/gpu/drm/i915/i915_query.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c| 2 +-
23 files changed, 46 insertions(+), 48 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))
+ if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
IP_VER(12, 55))
dst_4t = XY_FAST_COPY_BLT_D1_DST_TILE4;
} else if (dst->tiling == CLIENT_TILING_X) {
dst_tiles = XY_FAST_COPY_BLT_D0_DST_TILE_MODE(TILE_X);
@@ -365,7 +365,7 @@ static u64 tiled_offset(const struct intel_gt
Re: [PATCH] drm/i915/guc: Update w/a 14019159160
On Tue, Mar 12, 2024 at 04:43:06PM -0700, John Harrison wrote: On 3/12/2024 09:24, Matt Roper wrote: diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index 0c67d674c94de..4c3dae98656af 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -296,7 +296,8 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) /* Wa_16019325821 */ /* Wa_14019159160 */ - if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))) + if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) || From what I can see, this workaround is also needed on Xe_LPG+ (12.74) Isn't that an Xe platform? Or is 12.74 just ARL? official xe platforms start with Xe2, with graphics version being 20 Lucas De Marchi
Re: [PATCH 1/5] drm/i915: Drop WA 16015675438
On Tue, Mar 12, 2024 at 03:54:09PM -0700, Matt Roper wrote: On Wed, Mar 06, 2024 at 11:36:39AM -0800, Lucas De Marchi wrote: With dynamic load-balancing disabled on the compute side, there's no reason left to enable WA 16015675438. Drop it from both PVC and DG2. Note that this can be done because now the driver always set a fixed partition of EUs during initialization via the ccs_mode configuration. The flag to GuC is still needed because of 18020744125, so update the comment accordingly. Cc: Mateusz Jablonski Cc: Michal Mrozek Cc: Rodrigo Vivi Signed-off-by: Lucas De Marchi Dynamic load-balancing disable hasn't landed in i915 yet (although it probably will soon). Assuming we wait for that to happen first before applying this, Reviewed-by: Matt Roper Humn... I probably grepped the wrong tree for this one since I was seeing ccs_mode being set. Indeed it isn't :-/, so I will have to land a fix or revert since this patch already landed a few days ago. Lucas De Marchi
Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv
On Tue, Mar 12, 2024 at 03:58:19PM -0700, Matt Roper wrote:
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.
...
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 76400e9c40f0..4f1e56187442 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1536,17 +1536,12 @@ static const struct intel_forcewake_range
__gen12_fw_ranges[] = {
GEN_FW_RANGE(0x13200, 0x13fff, FORCEWAKE_MEDIA_VDBOX2), /*
\
0x13200 - 0x133ff: VD2 (DG2 only)
\
0x13400 - 0x13fff: reserved */
\
- GEN_FW_RANGE(0x14000, 0x141ff, FORCEWAKE_MEDIA_VDBOX0), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14200, 0x143ff, FORCEWAKE_MEDIA_VDBOX2), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14400, 0x145ff, FORCEWAKE_MEDIA_VDBOX4), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14600, 0x147ff, FORCEWAKE_MEDIA_VDBOX6), /* XEHPSDV only
*/ \
We can't just remove ranges in the middle of the table since that breaks
the "watertight" table requirement that our selftests check for. We
need to either roll the now-unused ranges into an adjacent range, or add
a new "reserved" range.
see 23n224gu57lfd4wbroqflav4pih6usrkf53q2ve4ntekhueylb@eqigxyktri6b
GEN_FW_RANGE(0x14800, 0x14fff, FORCEWAKE_RENDER),
\
GEN_FW_RANGE(0x15000, 0x16dff, FORCEWAKE_GT), /*
\
0x15000 - 0x15fff: gt (DG2 only)
\
0x16000 - 0x16dff: reserved */
\
GEN_FW_RANGE(0x16e00, 0x1, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x2, 0x21fff, FORCEWAKE_MEDIA_VDBOX0), /*
\
- 0x2 - 0x20fff: VD0 (XEHPSDV only)
\
+ GEN_FW_RANGE(0x21000, 0x21fff, FORCEWAKE_MEDIA_VDBOX0), /*
\
0x21000 - 0x21fff: reserved */
\
GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_GT),
\
GEN_FW_RANGE(0x24000, 0x2417f, 0), /*
\
@@ -1627,10 +1622,6 @@ static const struct intel_forcewake_range
__gen12_fw_ranges[] = {
0x1f6e00 - 0x1f7fff: reserved */
\
GEN_FW_RANGE(0x1f8000, 0x1fa0ff, FORCEWAKE_MEDIA_VEBOX3),
-static const struct intel_forcewake_range __xehp_fw_ranges[] = {
- XEHP_FWRANGES(FORCEWAKE_GT)
-};
-
static const struct intel_forcewake_range __dg2_fw_ranges[] = {
XEHP_FWRANGES(FORCEWAKE_RENDER)
We can drop the macro here now and just make this a normal table like
everything else.
will add that in v2 too, thanks
Lucas De Marchi
Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv
On Mon, Mar 11, 2024 at 11:16:06AM -0400, Rodrigo Vivi wrote:
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):
After double checking I think the main issue is that the changed table
became wrong since it poke holes. From the docs:
* All platforms' forcewake tables below must be sorted by offset ranges.
* Furthermore, new forcewake tables added should be "watertight" and hav
* no gaps between ranges.
I *think* this would be the more correct change:
@@ -1533,21 +1533,16 @@ static const struct intel_forcewake_range
__gen12_fw_ranges[] = {
0x12000 - 0x127ff: always on
\
0x12800 - 0x12fff: reserved */
\
GEN_FW_RANGE(0x13000, 0x131ff, FORCEWAKE_MEDIA_VDBOX0), /* DG2 only */
\
- GEN_FW_RANGE(0x13200, 0x13fff, FORCEWAKE_MEDIA_VDBOX2), /*
\
+ GEN_FW_RANGE(0x13200, 0x147ff, FORCEWAKE_MEDIA_VDBOX2), /*
\
0x13200 - 0x133ff: VD2 (DG2 only)
\
- 0x13400 - 0x13fff: reserved */
\
- GEN_FW_RANGE(0x14000, 0x141ff, FORCEWAKE_MEDIA_VDBOX0), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14200, 0x143ff, FORCEWAKE_MEDIA_VDBOX2), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14400, 0x145ff, FORCEWAKE_MEDIA_VDBOX4), /* XEHPSDV only
*/ \
- GEN_FW_RANGE(0x14600, 0x147ff, FORCEWAKE_MEDIA_VDBOX6), /* XEHPSDV only
*/ \
+ 0x13400 - 0x147ff: reserved */
\
GEN_FW_RANGE(0x14800, 0x14fff, FORCEWAKE_RENDER),
\
GEN_FW_RANGE(0x15000, 0x16dff, FORCEWAKE_GT), /*
\
0x15000 - 0x15fff: gt (DG2 only)
\
0x16000 - 0x16dff: reserved */
\
- GEN_FW_RANGE(0x16e00, 0x1, FORCEWAKE_RENDER),
\
- GEN_FW_RANGE(0x2, 0x21fff, FORCEWAKE_MEDIA_VDBOX0), /*
\
- 0x2 - 0x20fff: VD0 (XEHPSDV only)
\
- 0x21000 - 0x21fff: reserved */
\
+ GEN_FW_RANGE(0x16e00, 0x21fff, FORCEWAKE_RENDER), /*
\
+ 0x16e00 - 0x1: render
\
+ 0x2 - 0x21fff: reserved */
\
GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_GT),
\
GEN_FW_RANGE(0x24000, 0x2417f, 0), /*
\
0x24000 - 0x2407f: always on
\
did you find any access on DG2 within the reserved ranges?
Lucas De Marchi
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 +-
Re: [PATCH 0/5] drm/i915: cleanup dead code
On Tue, Mar 12, 2024 at 09:54:41AM +, Tvrtko Ursulin wrote:
On 11/03/2024 19:27, Lucas De Marchi wrote:
On Mon, Mar 11, 2024 at 05:43:00PM +, Tvrtko Ursulin wrote:
On 06/03/2024 19:36, Lucas De Marchi wrote:
Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by subsequent ones, so it's
not a huge amount of code being removed.
I had PVC and xehpsdv back in October but could not collect all acks. :(
Last two patches from https://patchwork.freedesktop.org/series/124705/.
oh... I was actually surprised we still had xehpsdv while removing a
WA for PVC, which made me look into removing these platforms.
rebasing your series and comparing yours..my-v2, where my-v2 only has
patches 2 and 4, I have the diff below. I think it's small enough that I
can just take your commits and squash delta. Is that ok to you?
my version is a little bit more aggressive, also doing some renames
s/xehpsdv/xehp/ and dropping some more code
(engine_mask_apply_copy_fuses(), unused registers, default ctx, fw
ranges).
Right, yeah I see I missed some case combos in the comments when
grepping and more.
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/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 1495b6074492..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. TGL_CACHELEVEL.
+ * defined i915/i915_pci.c, e.g. MTL_CACHELEVEL.
Why this?
it was just our different choices while doing the search-and-replace.
It's not that I changed yours, it's that my choice was to go with MTL
and yours to go with TGL. Any of them fit the role here.
* 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_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(0, pat_index, flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct
i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (GRAPHICS_VER_FULL(vm->i915) &
Re: [PATCH 0/5] drm/i915: cleanup dead code
On Mon, Mar 11, 2024 at 05:43:00PM +, Tvrtko Ursulin wrote:
On 06/03/2024 19:36, Lucas De Marchi wrote:
Remove platforms that never had their PCI IDs added to the driver and
are of course marked with requiring force_probe. Note that most of the
code for those platforms is actually used by subsequent ones, so it's
not a huge amount of code being removed.
I had PVC and xehpsdv back in October but could not collect all acks. :(
Last two patches from https://patchwork.freedesktop.org/series/124705/.
oh... I was actually surprised we still had xehpsdv while removing a
WA for PVC, which made me look into removing these platforms.
rebasing your series and comparing yours..my-v2, where my-v2 only has
patches 2 and 4, I have the diff below. I think it's small enough that I
can just take your commits and squash delta. Is that ok to you?
my version is a little bit more aggressive, also doing some renames
s/xehpsdv/xehp/ and dropping some more code
(engine_mask_apply_copy_fuses(), unused registers, default ctx, fw
ranges).
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/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 1495b6074492..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. TGL_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_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(0, pat_index,
flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct
i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
- xehpsdv_ppgtt_insert_huge(vm, vma
Re: ✗ Fi.CI.IGT: failure for drm/i915: Drop WA 16015675438 (rev2)
On Thu, Mar 07, 2024 at 05:24:38PM -, Patchwork wrote: == Series Details == Series: drm/i915: Drop WA 16015675438 (rev2) URL : https://patchwork.freedesktop.org/series/130815/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14400_full -> Patchwork_130815v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_130815v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_130815v2_full, please notify your bug team (i915-ci-in...@lists.freedesktop.org) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (8 -> 8) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_130815v2_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglu: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14400/shard-tglu-2/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-tglu-6/igt@i915_module_l...@reload-with-fault-injection.html * igt@i915_selftest@live@requests: - shard-mtlp: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14400/shard-mtlp-3/igt@i915_selftest@l...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-mtlp-5/igt@i915_selftest@l...@requests.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-glk: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscaling@pipe-a-valid-mode: - shard-dg2: NOTRUN -> [DMESG-WARN][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130815v2/shard-dg2-11/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscal...@pipe-a-valid-mode.html this is the only one that might be related since we are removing wa from pvc/dg2. But looking further, that warning shouldn't really be caused by this patch. Lucas De Marchi
Re: [PATCH 4/5] drm/i915: Drop dead code for pvc
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 Lucas De Marchi
Re: [PATCH] drm/i915: Drop WA 16015675438
On Mon, Mar 11, 2024 at 10:54:57AM -0400, Rodrigo Vivi wrote: On Wed, Mar 06, 2024 at 06:43:39AM -0800, Lucas De Marchi wrote: With dynamic load-balancing disabled on the compute side, there's no reason left to enable WA 16015675438. Drop it from both PVC and DG2. Note that this can be done because now the driver always set a fixed partition of EUs during initialization via the ccs_mode configuration. The flag to GuC is still needed because of 18020744125, so update the comment accordingly. Cc: Rodrigo Vivi Acked-by: Mateusz Jablonski Acked-by: Michal Mrozek Signed-off-by: Lucas De Marchi Reviewed-by: Rodrigo Vivi applied to drm-intel-gt-next, thanks. Lucas De Marchi
Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)
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? thanks Lucas De Marchi
Re: [PATCH v2 14/16] drm/dp_mst: avoid includes in drm_dp_mst_topology_internal.h
On Fri, Mar 08, 2024 at 01:55:52PM +0200, Jani Nikula wrote: Prefer forward declarations over includes where possible. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/display/drm_dp_mst_topology_internal.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology_internal.h b/drivers/gpu/drm/display/drm_dp_mst_topology_internal.h index a785ccbfdd73..f41c34e26be2 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology_internal.h +++ b/drivers/gpu/drm/display/drm_dp_mst_topology_internal.h @@ -10,7 +10,9 @@ #ifndef _DRM_DP_MST_HELPER_INTERNAL_H_ #define _DRM_DP_MST_HELPER_INTERNAL_H_ -#include +struct drm_dp_sideband_msg_req_body; +struct drm_dp_sideband_msg_tx; +struct drm_printer; void drm_dp_encode_sideband_req(const struct drm_dp_sideband_msg_req_body *req, -- 2.39.2
Re: [PATCH v2 15/16] drm: avoid includes in drm_crtc_helper_internal.h
On Fri, Mar 08, 2024 at 01:55:53PM +0200, Jani Nikula wrote: Prefer forward declarations over includes where possible. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi Lucas De Marchi --- drivers/gpu/drm/drm_crtc_helper_internal.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h b/drivers/gpu/drm/drm_crtc_helper_internal.h index ed4deed07abd..8059f65c5d6c 100644 --- a/drivers/gpu/drm/drm_crtc_helper_internal.h +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h @@ -29,10 +29,12 @@ #ifndef __DRM_CRTC_HELPER_INTERNAL_H__ #define __DRM_CRTC_HELPER_INTERNAL_H__ -#include -#include -#include -#include +enum drm_mode_status; +struct drm_connector; +struct drm_crtc; +struct drm_display_mode; +struct drm_encoder; +struct drm_modeset_acquire_ctx; /* drm_probe_helper.c */ enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc, -- 2.39.2
Re: [PATCH v2 07/16] drm/i915/pxp: fix i915_pxp_tee_interface.h kernel-doc warnings
On Fri, Mar 08, 2024 at 01:55:45PM +0200, Jani Nikula wrote:
Make documentation match code. Slightly fix up the documentation
comments while at it.
v2:
- Move comments next to members instead of struct comment (Lucas)
- Small fixups while at it
Cc: Lucas De Marchi
Acked-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
include/drm/i915_pxp_tee_interface.h | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/include/drm/i915_pxp_tee_interface.h
b/include/drm/i915_pxp_tee_interface.h
index 7d96985f2d05..a532d32f58f3 100644
--- a/include/drm/i915_pxp_tee_interface.h
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -12,20 +12,26 @@ struct scatterlist;
/**
* struct i915_pxp_component_ops - ops for PXP services.
- * @owner: Module providing the ops
- * @send: sends data to PXP
- * @receive: receives data from PXP
*/
struct i915_pxp_component_ops {
/**
-* @owner: owner of the module provding the ops
+* @owner: Module providing the ops.
*/
struct module *owner;
+ /**
+* @send: Send a PXP message.
+*/
int (*send)(struct device *dev, const void *message, size_t size,
unsigned long timeout_ms);
+ /**
+* @recv: Receive a PXP message.
+*/
int (*recv)(struct device *dev, void *buffer, size_t size,
unsigned long timeout_ms);
+ /**
+* @gsc_command: Send a GSC command.
+*/
ssize_t (*gsc_command)(struct device *dev, u8 client_id, u32 fence_id,
struct scatterlist *sg_in, size_t total_in_len,
struct scatterlist *sg_out);
@@ -35,14 +41,21 @@ struct i915_pxp_component_ops {
/**
* struct i915_pxp_component - Used for communication between i915 and TEE
* drivers for the PXP services
- * @tee_dev: device that provide the PXP service from TEE Bus.
- * @pxp_ops: Ops implemented by TEE driver, used by i915 driver.
*/
struct i915_pxp_component {
+ /**
+* @tee_dev: device that provide the PXP service from TEE Bus.
+*/
struct device *tee_dev;
+
+ /**
+* @ops: Ops implemented by TEE driver, used by i915 driver.
+*/
const struct i915_pxp_component_ops *ops;
- /* To protect the above members. */
+ /**
+* @mutex: To protect the above members.
+*/
struct mutex mutex;
};
--
2.39.2
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Thu, Feb 29, 2024 at 10:06:02PM -0600, Lucas De Marchi wrote: On Thu, Feb 29, 2024 at 08:27:30PM +0200, Andy Shevchenko wrote: On Thu, Feb 29, 2024 at 12:21:34PM -0600, Lucas De Marchi wrote: On Thu, Feb 29, 2024 at 12:49:57PM +0200, Andy Shevchenko wrote: On Wed, Feb 28, 2024 at 05:39:21PM -0600, Lucas De Marchi wrote: > On Thu, Feb 22, 2024 at 06:49:59AM -0800, Yury Norov wrote: ... > I build-tested this in x86-64, x86-32 and arm64. I didn't like much the > need to fork the __GENMASK() implementation on the 2 sides of the ifdef > since I think the GENMASK_INPUT_CHECK() should be the one covering the > input checks. However to make it common we'd need to solve 2 problems: > the casts and the sizeof. The sizeof can be passed as arg to > __GENMASK(), however the casts I think would need a __CAST_U8(x) > or the like and sprinkle it everywhere, which would hurt readability. > Not pretty. Or go back to the original submission and make it less > horrible :-/ I'm wondering if we can use _Generic() approach here. in assembly? Yes. I added a _Generic() in a random .S and to my surprise the build didn't break. Then I went to implement, and couldn't find where the _Generic() would actually be useful. What I came up with builds for me with gcc on x86-64, x86-32 and arm64. I'm also adding some additional tests in lib/test_bits.c to cover the expected values and types. Thoughts? 8< Subject: [PATCH] bits: introduce fixed-type genmasks Yury, is this something you'd take through your tree? Should I prepare the other patches on top and get some more arch coverage? thanks Lucas De Marchi Generalize __GENMASK() to support different types, and implement fixed-types versions of GENMASK() based on it. The fixed-type version allows more strict checks to the min/max values accepted, which is useful for defining registers like implemented by i915 and xe drivers with their REG_GENMASK*() macros. The strict checks rely on shift-count-overflow compiler check to fail the build if a number outside of the range allowed is passed. Example: #define FOO_MASK GENMASK_U32(33, 4) will generate a warning like: ../include/linux/bits.h:48:23: warning: right shift count is negative [-Wshift-count-negative] 48 | (~literal(0) >> ((w) - 1 - (h) | ^~ Some additional tests in lib/test_bits.c are added to cover the expected/non-expected values and also that the result value matches the expected type. Since those are known at build time, use static_assert() instead of normal kunit tests. Signed-off-by: Lucas De Marchi --- include/linux/bits.h | 33 +++-- lib/test_bits.c | 21 +++-- 2 files changed, 42 insertions(+), 12 deletions(-) diff --git a/include/linux/bits.h b/include/linux/bits.h index 7c0cf5031abe8..6f089e71a195c 100644 --- a/include/linux/bits.h +++ b/include/linux/bits.h @@ -22,24 +22,37 @@ #define GENMASK_INPUT_CHECK(h, l) \ (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ __is_constexpr((l) > (h)), (l) > (h), 0))) +#define __CAST_T(t, v) ((t)v) #else /* * BUILD_BUG_ON_ZERO is not available in h files included from asm files, * disable the input check if that is the case. */ #define GENMASK_INPUT_CHECK(h, l) 0 +#define __CAST_T(t, v) v #endif -#define __GENMASK(h, l) \ - (((~UL(0)) - (UL(1) << (l)) + 1) & \ -(~UL(0) >> (BITS_PER_LONG - 1 - (h -#define GENMASK(h, l) \ - (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) +/* + * Generate a mask for a specific type. @literal is the suffix to be used for + * an integer constant of that type and @width is the bits-per-type. Additional + * checks are made to guarantee the value returned fits in that type, relying + * on shift-count-overflow compiler check to detect incompatible arguments. + * For example, all these create build errors or warnings: + * + * - GENMASK(15, 20): wrong argument order + * - GENMASK(72, 15): doesn't fit unsigned long + * - GENMASK_U32(33, 15): doesn't fit in a u32 + */ +#define __GENMASK(literal, w, h, l) \ + (GENMASK_INPUT_CHECK(h, l) + \ +((~literal(0) - (literal(1) << (l)) + 1) & \ +(~literal(0) >> ((w) - 1 - (h) -#define __GENMASK_ULL(h, l) \ - (((~ULL(0)) - (ULL(1) << (l)) + 1) & \ -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h -#define GENMASK_ULL(h, l) \ - (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l)) +#define GENMASK(h, l) __GENMASK(UL, BITS_PER_LONG, h, l) +#define GENMASK_ULL(h, l) __GENMASK(ULL, BITS_PER_LONG_LONG, h, l) +#define GENMASK_U8(h, l) __CAST_T(u8, __GENMASK(UL, 8, h, l)) +#define GENMASK_U16(h, l) __CAST_T(u16, __GENMASK(UL, 16, h, l)) +#define GENMASK_U32(h, l) __CAST_T(u32, __GENMASK(UL, 32, h, l)) +#define GENMASK_U64(h, l) __CAST_T(u64, __GENMASK(ULL,
Re: [PATCH 17/22] drm/i915/pxp: fix i915_pxp_tee_interface.h kernel-doc warnings
On Wed, Mar 06, 2024 at 08:31:22PM +0200, Jani Nikula wrote:
Make documentation match code.
Signed-off-by: Jani Nikula
---
include/drm/i915_pxp_tee_interface.h | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/drm/i915_pxp_tee_interface.h
b/include/drm/i915_pxp_tee_interface.h
index 7d96985f2d05..653e85d6e32b 100644
--- a/include/drm/i915_pxp_tee_interface.h
+++ b/include/drm/i915_pxp_tee_interface.h
@@ -14,12 +14,10 @@ struct scatterlist;
* struct i915_pxp_component_ops - ops for PXP services.
* @owner: Module providing the ops
* @send: sends data to PXP
- * @receive: receives data from PXP
+ * @recv: receives data from PXP
+ * @gsc_command: send gsc command
*/
struct i915_pxp_component_ops {
- /**
-* @owner: owner of the module provding the ops
-*/
isn't the other way around the more common one? i.e. document the
struct members closer to their declaration.
struct module *owner;
int (*send)(struct device *dev, const void *message, size_t size,
@@ -35,14 +33,21 @@ struct i915_pxp_component_ops {
/**
* struct i915_pxp_component - Used for communication between i915 and TEE
* drivers for the PXP services
- * @tee_dev: device that provide the PXP service from TEE Bus.
- * @pxp_ops: Ops implemented by TEE driver, used by i915 driver.
*/
... which you follow here.
Lucas De Marchi
struct i915_pxp_component {
+ /**
+* @tee_dev: device that provide the PXP service from TEE Bus.
+*/
struct device *tee_dev;
+
+ /**
+* @ops: Ops implemented by TEE driver, used by i915 driver.
+*/
const struct i915_pxp_component_ops *ops;
- /* To protect the above members. */
+ /**
+* @mutex: To protect the above members.
+*/
struct mutex mutex;
};
--
2.39.2
Re: [PATCH 16/22] drm/i915/hdcp: fix i915_hdcp_interface.h kernel-doc warnings
On Wed, Mar 06, 2024 at 08:31:21PM +0200, Jani Nikula wrote:
Make the documentation match code.
Signed-off-by: Jani Nikula
---
include/drm/i915_hdcp_interface.h | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/drm/i915_hdcp_interface.h
b/include/drm/i915_hdcp_interface.h
index 4c9c8167c2d5..a9f2ee576de8 100644
--- a/include/drm/i915_hdcp_interface.h
+++ b/include/drm/i915_hdcp_interface.h
@@ -54,7 +54,7 @@ enum hdcp_ddi {
};
/**
- * enum hdcp_tc - ME/GSC Firmware defined index for transcoders
+ * enum hdcp_transcoder - ME/GSC Firmware defined index for transcoders
* @HDCP_INVALID_TRANSCODER: Index for Invalid transcoder
* @HDCP_TRANSCODER_EDP: Index for EDP Transcoder
* @HDCP_TRANSCODER_DSI0: Index for DSI0 Transcoder
@@ -106,7 +106,7 @@ struct hdcp_port_data {
* And Prepare AKE_Init.
* @verify_receiver_cert_prepare_km: Verify the Receiver Certificate
* AKE_Send_Cert and prepare
-AKE_Stored_Km/AKE_No_Stored_Km
+ * AKE_Stored_Km/AKE_No_Stored_Km
* @verify_hprime: Verify AKE_Send_H_prime
* @store_pairing_info: Store pairing info received
* @initiate_locality_check: Prepare LC_Init
@@ -170,14 +170,22 @@ struct i915_hdcp_ops {
/**
* struct i915_hdcp_arbiter - Used for communication between i915
* and hdcp drivers for the HDCP2.2 services
- * @hdcp_dev: device that provide the HDCP2.2 service from MEI Bus.
- * @hdcp_ops: Ops implemented by hdcp driver or intel_hdcp_gsc , used by i915
driver.
you are just moving what was already there, but may be a good
opportunity for small fixups?
*/
struct i915_hdcp_arbiter {
+ /**
+* @hdcp_dev: device that provide the HDCP2.2 service from MEI Bus.
^provides
+*/
struct device *hdcp_dev;
+
+ /**
+* @ops: Ops implemented by hdcp driver or intel_hdcp_gsc , used by i915
extra space before ","
anyway,
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+* driver.
+*/
const struct i915_hdcp_ops *ops;
- /* To protect the above members. */
+ /**
+* @mutex: To protect the above members.
+*/
struct mutex mutex;
};
--
2.39.2
Re: [PATCH 15/22] drm/i915: fix i915_gsc_proxy_mei_interface.h kernel-doc
On Wed, Mar 06, 2024 at 08:31:20PM +0200, Jani Nikula wrote: There's no proper way to document function pointer members, but at least silence the warnings. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi Lucas De Marchi
[PATCH 5/5] drm/i915: Remove special handling for !RCS_MASK()
With both XEHPSDV and PVC removed (as platforms, most of their code remain used by others), there's no need to handle !RCS_MASK() as other platforms don't ever have fused-off render. Remove those code paths and the special WA flag when initializing GuC. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 - 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 396f5fe993c3..476651bd0a21 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -497,9 +497,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id, engine->logical_mask = BIT(logical_instance); __sprint_engine_name(engine); - if ((engine->class == COMPUTE_CLASS && !RCS_MASK(engine->gt) && -__ffs(CCS_MASK(engine->gt)) == engine->instance) || -engine->class == RENDER_CLASS) + if ((engine->class == COMPUTE_CLASS || engine->class == RENDER_CLASS) && + __ffs(CCS_MASK(engine->gt) | RCS_MASK(engine->gt)) == engine->instance) engine->flags |= I915_ENGINE_FIRST_RENDER_COMPUTE; /* features common between engines sharing EUs */ diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index da6cc268e7b2..bcc7d5c74192 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -315,10 +315,6 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc) if (IS_DG2_G11(gt->i915)) flags |= GUC_WA_CONTEXT_ISOLATION; - /* Wa_18020744125 */ - if (!RCS_MASK(gt)) - flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST; - /* * Wa_14018913170: Applicable to all platforms supported by i915 so * don't bother testing for all X/Y/Z platforms explicitly. diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h index 8ae1846431da..0e4060adcf14 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h @@ -100,7 +100,6 @@ #define GUC_WA_PRE_PARSERBIT(14) #define GUC_WA_HOLD_CCS_SWITCHOUTBIT(17) #define GUC_WA_POLLCSBIT(18) -#define GUC_WA_RCS_REGS_IN_CCS_REGS_LIST BIT(21) #define GUC_WA_ENABLE_TSC_CHECK_ON_RC6 BIT(22) #define GUC_CTL_FEATURE2 -- 2.43.0
[PATCH 4/5] drm/i915: Drop dead code for pvc
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)
engine_mask_apply_media_fuses(gt);
engine_mask_apply_compute_fuses(gt);
- engine_mask_apply_copy_fuses(gt);
/*
* The on
[PATCH 2/5] drm/i915: Drop dead code for xehpsdv
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.
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(0, pat_index, flags);
unsigned int rem = sg_dma_len(iter->sg);
@@ -741,8 +741,8 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
- xehpsdv_ppgtt_insert_huge(vm, vma_res, ,
pat_index, flags);
+ if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 55))
+ xehp_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
else
gen8_ppgtt_insert_huge(vm, vma_res, , pat_index,
flags);
} else {
@@ -781,11 +781,11 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
drm_clflush_virt_range([gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
-static void __xehpsdv_ppgt
[PATCH 1/5] drm/i915: Drop WA 16015675438
With dynamic load-balancing disabled on the compute side, there's no
reason left to enable WA 16015675438. Drop it from both PVC and DG2.
Note that this can be done because now the driver always set a fixed
partition of EUs during initialization via the ccs_mode configuration.
The flag to GuC is still needed because of 18020744125, so update
the comment accordingly.
Cc: Mateusz Jablonski
Cc: Michal Mrozek
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d67d44611c28..7f812409c30a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2928,14 +2928,10 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
DISABLE_D8_D16_COASLESCE);
}
- if (IS_PONTEVECCHIO(i915) || IS_DG2(i915)) {
+ if (IS_PONTEVECCHIO(i915) || IS_DG2(i915))
/* Wa_14015227452:dg2,pvc */
wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN4, XEHP_DIS_BBL_SYSPIPE);
- /* Wa_16015675438:dg2,pvc */
- wa_masked_en(wal, FF_SLICE_CS_CHICKEN2,
GEN12_PERF_FIX_BALANCING_CFE_DISABLE);
- }
-
if (IS_DG2(i915)) {
/*
* Wa_16011620976:dg2_g11
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index d2b7425bbdcc..c6603793af89 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -315,7 +315,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
if (IS_DG2_G11(gt->i915))
flags |= GUC_WA_CONTEXT_ISOLATION;
- /* Wa_16015675438 */
+ /* Wa_18020744125 */
if (!RCS_MASK(gt))
flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST;
--
2.43.0
[PATCH 0/5] drm/i915: cleanup dead code
Remove platforms that never had their PCI IDs added to the driver and are of course marked with requiring force_probe. Note that most of the code for those platforms is actually used by subsequent ones, so it's not a huge amount of code being removed. drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h is also changed on the xe side, but that should be ok: the defines are there only for compat reasons while building the display side (and none of these platforms have display, so it's build-issue only). First patch is what motivated the others and was submitted alone @ 20240306144723.1826977-1-lucas.demar...@intel.com . While loooking at this WA I was wondering why we still had some of that code around. Build-tested only for now. Lucas De Marchi (5): drm/i915: Drop WA 16015675438 drm/i915: Drop dead code for xehpsdv drm/i915: Update IP_VER(12, 50) drm/i915: Drop dead code for pvc drm/i915: Remove special handling for !RCS_MASK() Documentation/gpu/rfc/i915_vm_bind.h | 11 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +- .../i915/gem/selftests/i915_gem_client_blt.c | 8 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40 ++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +--- .../drm/i915/gt/intel_execlists_submission.c | 10 +- drivers/gpu/drm/i915/gt/intel_gsc.c | 15 -- drivers/gpu/drm/i915/gt/intel_gt.c| 4 +- drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 52 + drivers/gpu/drm/i915/gt/intel_gt_mcr.h| 2 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 59 -- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 21 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 51 + drivers/gpu/drm/i915/gt/intel_migrate.c | 22 +- drivers/gpu/drm/i915/gt/intel_mocs.c | 52 + drivers/gpu/drm/i915/gt/intel_rps.c | 6 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 13 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 193 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 6 +- 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_fwif.h | 1 - .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 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 | 13 -- drivers/gpu/drm/i915/i915_getparam.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 5 +- drivers/gpu/drm/i915/i915_hwmon.c | 6 - drivers/gpu/drm/i915/i915_pci.c | 61 +- drivers/gpu/drm/i915/i915_perf.c | 19 +- drivers/gpu/drm/i915/i915_query.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 4 +- drivers/gpu/drm/i915/intel_clock_gating.c | 26 +-- drivers/gpu/drm/i915/intel_device_info.c | 2 - drivers/gpu/drm/i915/intel_device_info.h | 2 - drivers/gpu/drm/i915/intel_step.c | 80 +--- drivers/gpu/drm/i915/intel_uncore.c | 159 +-- drivers/gpu/drm/i915/selftests/intel_uncore.c | 3 - .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 6 - 43 files changed, 110 insertions(+), 928 deletions(-) -- 2.43.0
[PATCH 3/5] drm/i915: Update IP_VER(12, 50)
With no platform declaring graphics/media IP_VER(12, 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))
+ if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
IP_VER(12, 55))
dst_4t = XY_FAST_COPY_BLT_D1_DST_TILE4;
} else if (dst->tiling == CLIENT_TILING_X) {
dst_t
[PATCH] drm/i915: Drop WA 16015675438
With dynamic load-balancing disabled on the compute side, there's no
reason left to enable WA 16015675438. Drop it from both PVC and DG2.
Note that this can be done because now the driver always set a fixed
partition of EUs during initialization via the ccs_mode configuration.
The flag to GuC is still needed because of 18020744125, so update
the comment accordingly.
Cc: Rodrigo Vivi
Acked-by: Mateusz Jablonski
Acked-by: Michal Mrozek
Signed-off-by: Lucas De Marchi
---
This is the i915 counter part. The xe version of this patch
(https://lore.kernel.org/intel-xe/20240304233103.1687412-1-lucas.demar...@intel.com/)
was already merged in drm-xe-next. I'm keeping the acked-by as it also
applies the same logic in i915.
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d67d44611c28..7f812409c30a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2928,14 +2928,10 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0,
DISABLE_D8_D16_COASLESCE);
}
- if (IS_PONTEVECCHIO(i915) || IS_DG2(i915)) {
+ if (IS_PONTEVECCHIO(i915) || IS_DG2(i915))
/* Wa_14015227452:dg2,pvc */
wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN4, XEHP_DIS_BBL_SYSPIPE);
- /* Wa_16015675438:dg2,pvc */
- wa_masked_en(wal, FF_SLICE_CS_CHICKEN2,
GEN12_PERF_FIX_BALANCING_CFE_DISABLE);
- }
-
if (IS_DG2(i915)) {
/*
* Wa_16011620976:dg2_g11
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index d2b7425bbdcc..c6603793af89 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -315,7 +315,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
if (IS_DG2_G11(gt->i915))
flags |= GUC_WA_CONTEXT_ISOLATION;
- /* Wa_16015675438 */
+ /* Wa_18020744125 */
if (!RCS_MASK(gt))
flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST;
--
2.43.0
Re: [RESEND v3 0/2] drm: enable W=1 warnings by default across the subsystem
On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote: On Tue, 05 Mar 2024, "Maxime Ripard" wrote: On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote: Resend of [1] with an intent to merge after the CI results come in. This is aiming for v6.10, so we'll have maximal time to find all the issues my configs didn't catch. I built this on x86-64 (both gcc and clang), arm and arm64, and [ ... ] Acked-by: Maxime Ripard Thanks everyone for acks and reviews, pushed to drm-misc-next. should we start removing the now duplicate ones in i915 and xe? Lucas De Marchi BR, Jani. -- Jani Nikula, Intel
Re: [PATCH 0/4] XE HDCP Enablement
On Tue, Feb 27, 2024 at 11:02:00AM +0530, Suraj Kandpal wrote: This patch series enables HDCP on XE. Mainly includes rewriting functions that were responsible for sending hdcp messages via gsc cs. Signed-off-by: Suraj Kandpal Suraj Kandpal (4): drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file drm/xe/hdcp: Use xe_device struct drm/xe: Use gsc_proxy_init_done to check proxy status drm/xe/hdcp: Enable HDCP for XE please double check your includes to follow the convention used in the driver. I commented in one of them. Other than that and with CI passing, Acked-by: Lucas De Marchi Lucas De Marchi drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 6 + drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 7 +- drivers/gpu/drm/xe/Makefile | 1 + drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 241 +- drivers/gpu/drm/xe/xe_gsc_proxy.c | 4 +- drivers/gpu/drm/xe/xe_gsc_proxy.h | 1 + drivers/gpu/drm/xe/xe_gsc_submit.c| 15 ++ drivers/gpu/drm/xe/xe_gsc_submit.h| 1 + 8 files changed, 258 insertions(+), 18 deletions(-) -- 2.43.2
Re: [PATCH 4/4] drm/xe/hdcp: Enable HDCP for XE
On Tue, Feb 27, 2024 at 11:02:04AM +0530, Suraj Kandpal wrote:
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
--v2
-add kfree at appropriate place [Daniele]
-remove useless define [Daniele]
-move host session logic to xe_gsc_submit.c [Daniele]
-call xe_gsc_check_and_update_pending directly in an if condition
[Daniele]
-use xe_device instead of drm_i915_private [Daniele]
--v3
-use xe prefix for newly exposed function [Daniele]
-remove client specific defines from intel_gsc_mtl_header [Daniele]
-add missing kfree() [Daniele]
-have NULL check for hdcp_message in finish function [Daniele]
-dont have too many variable declarations in the same line [Daniele]
--v4
-don't point the hdcp_message structure in xe_device to anything
until it properly gets initialized [Daniele]
--v5
-Squash commits for buildability
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 198 ++-
drivers/gpu/drm/xe/xe_gsc_submit.c | 15 ++
drivers/gpu/drm/xe/xe_gsc_submit.h | 1 +
4 files changed, 212 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index c531210695db..2b654c908ff3 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -254,6 +254,7 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_global_state.o \
i915-display/intel_gmbus.o \
i915-display/intel_hdcp.o \
+ i915-display/intel_hdcp_gsc_message.o \
i915-display/intel_hdmi.o \
i915-display/intel_hotplug.o \
i915-display/intel_hotplug_irq.o \
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 0de06e0373ef..bb3bddcd5747 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -4,14 +4,31 @@
*/
#include
+#include
+#include
+#include "abi/gsc_command_header_abi.h"
#include "intel_hdcp_gsc.h"
+#include "intel_hdcp_gsc_message.h"
#include "xe_device_types.h"
#include "xe_device.h"
#include "xe_gt.h"
#include "xe_gsc_proxy.h"
#include "xe_pm.h"
#include "xe_uc_fw.h"
+#include "xe_bo.h"
+#include "xe_map.h"
+#include "xe_gsc_submit.h"
don't append includes here, please follow the alphabetical order.
+
+#define HECI_MEADDRESS_HDCP 18
+
+struct intel_hdcp_gsc_message {
+ struct xe_bo *hdcp_bo;
+ u64 hdcp_cmd_in;
+ u64 hdcp_cmd_out;
+};
+
+#define HDCP_GSC_HEADER_SIZE sizeof(struct intel_gsc_mtl_header)
bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
@@ -45,19 +62,194 @@ bool intel_hdcp_gsc_check_status(struct xe_device *xe)
return ret;
}
+/*This function helps allocate memory for the command that we will send to gsc
cs */
+static int intel_hdcp_gsc_initialize_message(struct xe_device *xe,
+struct intel_hdcp_gsc_message
*hdcp_message)
+{
+ struct xe_bo *bo = NULL;
+ u64 cmd_in, cmd_out;
+ int ret = 0;
+
+ /* allocate object of two page for HDCP command memory and store it */
+ xe_device_mem_access_get(xe);
+ bo = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe), NULL,
PAGE_SIZE * 2,
+ ttm_bo_type_kernel,
+ XE_BO_CREATE_SYSTEM_BIT |
+ XE_BO_CREATE_GGTT_BIT);
+
+ if (IS_ERR(bo)) {
+ drm_err(>drm, "Failed to allocate bo for HDCP streaming
command!\n");
+ ret = PTR_ERR(bo);
+ goto out;
+ }
+
+ cmd_in = xe_bo_ggtt_addr(bo);
+ cmd_out = cmd_in + PAGE_SIZE;
+ xe_map_memset(xe, >vmap, 0, 0, bo->size);
+
+ hdcp_message->hdcp_bo = bo;
+ hdcp_message->hdcp_cmd_in = cmd_in;
+ hdcp_message->hdcp_cmd_out = cmd_out;
+out:
+ xe_device_mem_access_put(xe);
+ return ret;
+}
+
+static int intel_hdcp_gsc_hdcp2_init(struct xe_device *xe)
+{
+ struct intel_hdcp_gsc_message *hdcp_message;
+ int ret;
+
+ hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
+
+ if (!hdcp_message)
+ return -ENOMEM;
+
+ /*
+* NOTE: No need to lock the comp mutex here as it is already
+* going to be taken before this function called
+*/
+ ret = intel_hdcp_gsc_initialize_message(xe, hdcp_message);
+ if (ret) {
+ drm_err(>drm, "Could not initialize hdcp_message\n");
+ kfree(hdcp_message);
+ return ret;
+ }
+
+ xe->display.hdcp.hdcp_message = hdcp_message;
+ return ret;
+}
+
+static const struct i915_hdcp_ops gsc_hdcp_ops = {
+ .initiate_hdcp2_session = intel_hdcp_gsc_initiate_session,
+
Re: [PATCH 8/8] drm/xe/lnl: Enable display support
On Mon, Mar 04, 2024 at 03:30:27PM -0300, Gustavo Sousa wrote:
From: Balasubramani Vivekanandan
Enable display support for Lunar Lake.
Signed-off-by: Balasubramani Vivekanandan
Signed-off-by: Lucas De Marchi
Signed-off-by: Gustavo Sousa
Reviewed-by: Lucas De Marchi
No need to merge this through drm-xe. Since we require all the other
patches in this series on the i915 side, let's just make our lives
easier and merge this one through drm-intel.
Lucas De Marchi
---
drivers/gpu/drm/xe/xe_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 5b5c29761c5d..42ba2ea62c1e 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -333,6 +333,7 @@ static const struct xe_device_desc mtl_desc = {
static const struct xe_device_desc lnl_desc = {
PLATFORM(XE_LUNARLAKE),
+ .has_display = true,
.require_force_probe = true,
};
--
2.44.0
Re: [PATCH 7/8] drm/i915/xe2lpd: Load DMC
On Mon, Mar 04, 2024 at 03:30:26PM -0300, Gustavo Sousa wrote:
From: Balasubramani Vivekanandan
Load DMC for Xe2LPD. The value 0x8000 is the maximum payload size for
any Xe2LPD DMC firmware.
Signed-off-by: Balasubramani Vivekanandan
Signed-off-by: Dnyaneshwar Bhadane
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 835781624482..54c5909de293 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -89,10 +89,14 @@ static struct intel_dmc *i915_to_dmc(struct
drm_i915_private *i915)
__stringify(major) "_"\
__stringify(minor) ".bin"
+#define XE2LPD_MAX_FW_SIZE 0x8000
^ missing DMC_ here to be like the other macros below?
other than that, Reviewed-by: Lucas De Marchi
Lucas De Marchi
#define XELPDP_DMC_MAX_FW_SIZE 0x7000
#define DISPLAY_VER13_DMC_MAX_FW_SIZE 0x2
#define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define XE2LPD_DMC_PATHDMC_PATH(xe2lpd)
+MODULE_FIRMWARE(XE2LPD_DMC_PATH);
+
#define MTL_DMC_PATHDMC_PATH(mtl)
MODULE_FIRMWARE(MTL_DMC_PATH);
@@ -987,7 +991,10 @@ void intel_dmc_init(struct drm_i915_private *i915)
INIT_WORK(>work, dmc_load_work_fn);
- if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0)) {
+ if (DISPLAY_VER_FULL(i915) == IP_VER(20, 0)) {
+ dmc->fw_path = XE2LPD_DMC_PATH;
+ dmc->max_fw_size = XE2LPD_MAX_FW_SIZE;
+ } else if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0)) {
dmc->fw_path = MTL_DMC_PATH;
dmc->max_fw_size = XELPDP_DMC_MAX_FW_SIZE;
} else if (IS_DG2(i915)) {
--
2.44.0
[PULL] drm-xe-next-fixes
Hi Dave and Sima, A few xe fixes for 6.9. drm-xe-next-fixes-2024-03-04: Driver Changes: - Fix kunit link failure with built-in xe - Fix one more 32-bit build failure with ARM compiler - Fix initialization order of topology struct - Cleanup unused fields in struct xe_vm - Fix xe_vm leak when handling page fault on a VM not in fault mode - Drop use of "grouped target" feature in Makefile since that's only available in make >= 4.3 thanks, Lucas De Marchi The following changes since commit c6d6a82d8a9f8f9326b760accaa532b839b80140: Merge tag 'drm-misc-next-fixes-2024-02-29' of https://anongit.freedesktop.org/git/drm/drm-misc into drm-next (2024-03-01 19:38:13 +1000) are available in the Git repository at: ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-fixes-2024-03-04 for you to fetch changes up to e62d2e00780b4a465c77d2229837495fcbc480d3: drm/xe: Replace 'grouped target' in Makefile with pattern rule (2024-03-04 08:41:28 -0600) Driver Changes: - Fix kunit link failure with built-in xe - Fix one more 32-bit build failure with ARM compiler - Fix initialization order of topology struct - Cleanup unused fields in struct xe_vm - Fix xe_vm leak when handling page fault on a VM not in fault mode - Drop use of "grouped target" feature in Makefile since that's only available in make >= 4.3 Arnd Bergmann (2): drm/xe/kunit: fix link failure with built-in xe drm/xe/xe2: fix 64-bit division in pte_update_size Dafna Hirschfeld (1): drm/xe: Replace 'grouped target' in Makefile with pattern rule Matthew Brost (1): drm/xe: Fix ref counting leak on page fault Mika Kuoppala (1): drm/xe: Remove obsolete async_ops from struct xe_vm Zhanjun Dong (1): drm/xe/guc: Fix missing topology init drivers/gpu/drm/xe/Kconfig | 1 + drivers/gpu/drm/xe/Kconfig.debug | 1 - drivers/gpu/drm/xe/Makefile | 9 ++--- drivers/gpu/drm/xe/xe_gt.c | 3 +-- drivers/gpu/drm/xe/xe_gt_pagefault.c | 6 -- drivers/gpu/drm/xe/xe_migrate.c | 2 +- drivers/gpu/drm/xe/xe_vm_types.h | 24 7 files changed, 13 insertions(+), 33 deletions(-)
Re: [PATCH] drm/i915: fix applying placement flag
On Fri, Mar 01, 2024 at 05:06:16PM +0100, Christian König wrote:
Am 01.03.24 um 17:04 schrieb Lucas De Marchi:
On Thu, Feb 29, 2024 at 02:01:05PM +0100, Christian König wrote:
Gentle ping. Can I get an rb for that?
Thanks,
Christian.
Reviewed-by: Lucas De Marchi
Thanks!
For some reason CI failed, but can't be related with this change.
I re-triggered it to see if we can get a green run before merging.
Do you want to pick it into a i915 branch or should I push it to
drm-misc-next(-fixes) then?
You can push it through drm-misc since that's where a78a8da51b36 came
from. If we feel like waiting CI to come back, let's wait a few hours.
Such an obvious fix for a build breakage that I'm not opposed to simply
letting it through though.
Lucas De Marchi
Christian.
thanks
Lucas De Marchi
Am 26.02.24 um 15:27 schrieb Christian König:
Switching from a separate list to flags introduced a bug here.
We were accidentially ORing the flag before initailizing the placement
and not after. So this code didn't do nothing except producing a
warning.
Signed-off-by: Christian König
Reported-by: Stephen Rothwell
Fixes: a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index a6b0aaf30cbe..7264fb08eee8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -162,10 +162,10 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
unsigned int flags = obj->flags;
unsigned int i;
- places[0].flags |= TTM_PL_FLAG_DESIRED;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
obj->mm.region, [0], obj->bo_offset,
obj->base.size, flags);
+ places[0].flags |= TTM_PL_FLAG_DESIRED;
/* Cache this on object? */
for (i = 0; i < num_allowed; ++i) {
