Re: [PATCH v3 20/21] drm/i915/display: perform transient flush
On Mon, Apr 15, 2024 at 10:07:32AM -0700, Matt Roper wrote: > On Mon, Apr 15, 2024 at 01:44:22PM +0530, Balasubramani Vivekanandan 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 > > Has the IGT patch for this been sent yet? If not, we should probably > make sure that happens soon, and then use the CI Test-with: thing if > there winds up being another revision of this series so that this will > be included in the CI results. Oh, it looks like this test already landed back in early March; I just didn't look back far enough in the git history originally. You can ignore this comment. Matt > > Anyway, the changes here look good to me, > > Reviewed-by: Matt Roper > > > Signed-off-by: Matthew Auld > > Signed-off-by: Balasubramani Vivekanandan > > > > Acked-by: Nirmoy Das > > --- > > 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 67697d9a559c..4fc46edcb4ad 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -110,6 +110,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" > > @@ -7242,6 +7243,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 int
Re: [PATCH v3 20/21] drm/i915/display: perform transient flush
On Mon, Apr 15, 2024 at 01:44:22PM +0530, Balasubramani Vivekanandan 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
Has the IGT patch for this been sent yet? If not, we should probably
make sure that happens soon, and then use the CI Test-with: thing if
there winds up being another revision of this series so that this will
be included in the CI results.
Anyway, the changes here look good to me,
Reviewed-by: Matt Roper
> Signed-off-by: Matthew Auld
> Signed-off-by: Balasubramani Vivekanandan
>
> Acked-by: Nirmoy Das
> ---
> 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 67697d9a559c..4fc46edcb4ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -110,6 +110,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"
> @@ -7242,6 +7243,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 6015c9e41f24..97a8674cdd76 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -198,7 +198,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/dri
Re: [PATCH v3 19/21] drm/xe/device: implement transient flush
On Mon, Apr 15, 2024 at 01:44:21PM +0530, Balasubramani Vivekanandan 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.
>
> CC: Matt Roper
> Signed-off-by: Nirmoy Das
> Co-developed-by: Matthew Auld
> Signed-off-by: Matthew Auld
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> 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 | 2 ++
> 3 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> index 8fe811ea404a..65719a712807 100644
> --- a/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_gt_regs.h
> @@ -318,6 +318,9 @@
>
> #define XE2LPM_L3SQCREG5 XE_REG_MCR(0xb658)
>
> +#define XE2_TDF_CTRL XE_REG(0xb418)
> +#define TRANSIENT_FLUSH_REQUESTREG_BIT(0)
> +
> #define XEHP_MERT_MOD_CTRL XE_REG_MCR(0xcf28)
> #define RENDER_MOD_CTRL XE_REG_MCR(0xcf2c)
> #define COMP_MOD_CTRLXE_REG_MCR(0xcf30)
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index d85a2ba0a057..22e6422c7b8e 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -717,6 +717,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. 64us,
> + * 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))
Comment (64us) doesn't seem to match code (150us).
Aside from that,
Reviewed-by: Matt Roper
Matt
> + 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 d413bc2c6be5..d3430f4b820a 100644
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -176,4 +176,6 @@ void xe_device_snapshot_print(struct xe_device *xe,
> struct drm_printer *p);
> u64 xe_device_canonicalize_addr(struct xe_device *xe, u64 address);
> u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64 address);
>
> +void xe_device_td_flush(struct xe_device *xe);
> +
> #endif
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 14/21] drm/i915/xe2hpd: Do not program MBUS_DBOX BW credits
On Mon, Apr 15, 2024 at 01:44:16PM +0530, Balasubramani Vivekanandan wrote:
> From: José Roberto de Souza
>
> No display IP beyond Xe_LPD+ has "BW credits" bits in MBUS_DBOX_CTL
> register. Restrict the programming only to Xe_LPD+.
>
> BSpec: 49213
> CC: Matt Roper
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 8436af8525da..baa4b5ad96b7 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3604,7 +3604,7 @@ static void intel_mbus_dbox_update(struct
> intel_atomic_state *state)
> for_each_intel_crtc_in_pipe_mask(>drm, crtc,
> new_dbuf_state->active_pipes) {
> u32 pipe_val = val;
>
> - if (DISPLAY_VER(i915) >= 14) {
> + if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0)) {
> if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
>
> new_dbuf_state->active_pipes))
> pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 11/21] drm/i915/xe2hpd: Add display info
On Mon, Apr 15, 2024 at 01:44:13PM +0530, Balasubramani Vivekanandan wrote:
> From: Lucas De Marchi
>
> Add initial display info for xe2hpd. It is similar to xelpdp, but with no
> PORT_B.
>
> v2: Inherit from XE_LPDP_FEATURES instead of XE_LPD_FEATURES
>
> Bspec: 67066
> CC: Matt Roper
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index b8903bd0e82a..2740ccaeb086 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -771,6 +771,12 @@ static const struct intel_display_device_info
> xe2_lpd_display = {
> BIT(INTEL_FBC_C) | BIT(INTEL_FBC_D),
> };
>
> +static const struct intel_display_device_info xe2_hpd_display = {
> + XE_LPDP_FEATURES,
> + .__runtime_defaults.port_mask = BIT(PORT_A) |
> + BIT(PORT_TC1) | BIT(PORT_TC2) | BIT(PORT_TC3) | BIT(PORT_TC4),
> +};
> +
> __diag_pop();
>
> /*
> @@ -852,6 +858,7 @@ static const struct {
> const struct intel_display_device_info *display;
> } gmdid_display_map[] = {
> { 14, 0, _lpdp_display },
> + { 14, 1, _hpd_display },
> { 20, 0, _lpd_display },
> };
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 04/21] drm/i915/xe2hpd: Skip CCS modifiers
On Mon, Apr 15, 2024 at 01:44:06PM +0530, Balasubramani Vivekanandan wrote:
> Framebuffer format modifiers are used to indicate the existence of
> auxillary surface in the plane, containing the CCS data. But on
s/auxillary/auxiliary/ in a few places in this commit message. Although
I don't think this statement is 100% true. DG2 use FlatCCS rather than
AuxCCS, but still needs to use framebuffer modifiers because the region
of the FlatCCS that corresponds to the buffer may not be
initialized/correct if the buffer contents were generated in a
non-compressed manner. We have to use framebuffer modifiers to pass
information through the software stack as to whether the FlatCCS data
for the buffer is usable and should be consulted by consumers of the
buffer.
As I understand it, the big change in Xe2, is that compression is now
controlled by the PAT setting in the PTEs and even in cases where an
"uncompressed" PAT index is used to generate content in the buffers, the
corresponding FlatCCS area still gets initialized to whatever metadata
code corresponds to "this bloc is uncompressed." So that means that
it's always safe for consumers like display to treat the buffer as if it
were compressed (e.g., setting the decompression flag in PLANE_CTL) ---
the CCS metadata for ever single block in the buffer will properly
indicate that no compression is actually present.
Matt
> Xe2_HPD, the CCS data is stored in a fixed reserved memory area and not
> part of the plane. It contains no auxillary surface.
> Also in Xe2, the compression is configured via PAT settings in the
> pagetable mappings. Decompression is enabled by default in the
> PLANE_CTL. Based on whether valid CCS data exists for the plane, display
> hardware decides whether compression is necessary or not.
> So there is no need for format modifiers to indicate if compression is
> enabled or not.
>
> v2:
> * Improved the commit description with more details
> * Removed the redundant display IP version check for 20. Display version
> check for each modifier above would take care of it.
>
> CC: Juha-Pekka Heikkilä
> CC: Matt Roper
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 86b443433e8b..7234ce36b6a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -431,9 +431,19 @@ static bool plane_has_modifier(struct drm_i915_private
> *i915,
>* Separate AuxCCS and Flat CCS modifiers to be run only on platforms
>* where supported.
>*/
> - if (intel_fb_is_ccs_modifier(md->modifier) &&
> - HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
> - return false;
> + if (intel_fb_is_ccs_modifier(md->modifier)) {
> +
> + /*
> + * There is no need for CCS format modifiers for Xe2_HPD, as
> + * there is no support of AuxCCS and the FlatCCS is configured
> + * usign PAT index in the page table mappings
> + */
> + if (DISPLAY_VER_FULL(i915) == IP_VER(14, 1))
> + return false;
> +
> + if (HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
> + return false;
> + }
>
> return true;
> }
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 02/21] drm/i915/display: Enable RM timeout detection
On Mon, Apr 15, 2024 at 01:44:04PM +0530, Balasubramani Vivekanandan wrote:
> From: Mitul Golani
>
> Enable RM timeout interrupt to detect any hang during display engine
> register access.
> Current default timeout is 2ms.
>
> v2:
> * Modified the IP version check to apply on all versions starting from
> 14
> * Improved the print log
>
> Bspec: 50110
> CC: Suraj Kandpal
> CC: Matt Roper
> CC: Jani Nikula
> Signed-off-by: Mitul Golani
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 10 ++
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index c337e0597541..9c65e9e32fca 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -852,6 +852,13 @@ gen8_de_misc_irq_handler(struct drm_i915_private
> *dev_priv, u32 iir)
> {
> bool found = false;
>
> + if (iir & GEN8_DE_RM_TIMEOUT) {
> + u32 val = intel_uncore_read(_priv->uncore,
> + RMTIMEOUTREG_CAPTURE);
> + drm_warn(_priv->drm, "Register access timeout for offset =
> 0x%x\n", val);
Have we ever actually encountered an error that caused a register read
to timeout? If so, was it a one-off error or did it cause a stream of
errors? This seems like the kind of thing that might trigger repeatedly
once hardware goes off the rails, so we might want to use either the
rate-limited or once form of dmesg logging.
> + found = true;
> + }
> +
> if (DISPLAY_VER(dev_priv) >= 14) {
> if (iir & (XELPDP_PMDEMAND_RSP |
> XELPDP_PMDEMAND_RSPTOUT_ERR)) {
> @@ -1667,6 +1674,9 @@ void gen8_de_irq_postinstall(struct drm_i915_private
> *dev_priv)
> de_port_masked |= DSI0_TE | DSI1_TE;
> }
>
> + if (DISPLAY_VER(dev_priv) >= 14)
> + de_misc_masked |= GEN8_DE_RM_TIMEOUT;
> +
> de_pipe_enables = de_pipe_masked |
> GEN8_PIPE_VBLANK |
> gen8_de_pipe_underrun_mask(dev_priv) |
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3f34efcd7d6c..a8cdabd07b04 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4225,6 +4225,8 @@
> #define RM_TIMEOUT _MMIO(0x42060)
> #define MMIO_TIMEOUT_US(us) ((us) << 0)
>
> +#define RMTIMEOUTREG_CAPTURE _MMIO(0x420e0)
> +
> /* interrupts */
> #define DE_MASTER_IRQ_CONTROL (1 << 31)
> #define DE_SPRITEB_FLIP_DONE(1 << 29)
> @@ -4411,6 +4413,7 @@
> #define GEN8_DE_MISC_IMR _MMIO(0x44464)
> #define GEN8_DE_MISC_IIR _MMIO(0x44468)
> #define GEN8_DE_MISC_IER _MMIO(0x4446c)
> +#define GEN8_DE_RM_TIMEOUT REG_BIT(29)
The "GEN8" prefix here isn't appropriate. This bit didn't show up in
hardware until Xe_LPD+.
Actually this whole patch should probably be titled "drm/i915/xelpdp:"
to make it clear that this change applies to Xe_LPD+. This patch
probably should have been sent a long time ago and not mixed into the
BMG work...
Matt
> #define XELPDP_PMDEMAND_RSPTOUT_ERR REG_BIT(27)
> #define GEN8_DE_MISC_GSEREG_BIT(27)
> #define GEN8_DE_EDP_PSR REG_BIT(19)
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 01/21] drm/xe/display: Lane reversal requires writes to both context lanes
On Mon, Apr 15, 2024 at 01:44:03PM +0530, Balasubramani Vivekanandan wrote:
> From: Clint Taylor
>
> Write both CX0 Lanes for Context Toggle for all except TC pin assignment D.
>
> Bspec: 64539
> CC: Jani Nikula
> Signed-off-by: Clint Taylor
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
Does this commit need a Fixes: too?
Matt
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index a2c4bf33155f..5cf5d9b59708 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2337,7 +2337,7 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
> {
> const struct intel_c20pll_state *pll_state =
> _state->cx0pll_state.c20;
> bool dp = false;
> - int lane = crtc_state->lane_count > 2 ? INTEL_CX0_BOTH_LANES :
> INTEL_CX0_LANE0;
> + u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(encoder);
> u32 clock = crtc_state->port_clock;
> bool cntx;
> int i;
> @@ -2402,19 +2402,19 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
> }
>
> /* 4. Program custom width to match the link protocol */
> - intel_cx0_rmw(encoder, lane, PHY_C20_VDR_CUSTOM_WIDTH,
> + intel_cx0_rmw(encoder, owned_lane_mask, PHY_C20_VDR_CUSTOM_WIDTH,
> PHY_C20_CUSTOM_WIDTH_MASK,
> PHY_C20_CUSTOM_WIDTH(intel_get_c20_custom_width(clock,
> dp)),
> MB_WRITE_COMMITTED);
>
> /* 5. For DP or 6. For HDMI */
> if (dp) {
> - intel_cx0_rmw(encoder, lane, PHY_C20_VDR_CUSTOM_SERDES_RATE,
> + intel_cx0_rmw(encoder, owned_lane_mask,
> PHY_C20_VDR_CUSTOM_SERDES_RATE,
> BIT(6) | PHY_C20_CUSTOM_SERDES_MASK,
> BIT(6) |
> PHY_C20_CUSTOM_SERDES(intel_c20_get_dp_rate(clock)),
> MB_WRITE_COMMITTED);
> } else {
> - intel_cx0_rmw(encoder, lane, PHY_C20_VDR_CUSTOM_SERDES_RATE,
> + intel_cx0_rmw(encoder, owned_lane_mask,
> PHY_C20_VDR_CUSTOM_SERDES_RATE,
> BIT(7) | PHY_C20_CUSTOM_SERDES_MASK,
> is_hdmi_frl(clock) ? BIT(7) : 0,
> MB_WRITE_COMMITTED);
> @@ -2428,7 +2428,7 @@ static void intel_c20_pll_program(struct
> drm_i915_private *i915,
>* 7. Write Vendor specific registers to toggle context setting to load
>* the updated programming toggle context bit
>*/
> - intel_cx0_rmw(encoder, lane, PHY_C20_VDR_CUSTOM_SERDES_RATE,
> + intel_cx0_rmw(encoder, owned_lane_mask, PHY_C20_VDR_CUSTOM_SERDES_RATE,
> BIT(0), cntx ? 0 : 1, MB_WRITE_COMMITTED);
> }
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [v2] drm/i915: Implement Audio WA_14020863754
On Fri, Apr 12, 2024 at 03:25:23AM -0700, Shankar, Uma wrote: > > > > -Original Message- > > From: Roper, Matthew D > > Sent: Friday, April 12, 2024 4:07 AM > > To: Shankar, Uma > > Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org; Borah, > > Chaitanya Kumar ; > > jani.nik...@linux.intel.com > > Subject: Re: [v2] drm/i915: Implement Audio WA_14020863754 > > > > On Wed, Apr 10, 2024 at 07:20:46PM +0530, Uma Shankar wrote: > > > WA_14020863754: Corner case with Min Hblank Fix can cause audio hang > > > > > > Issue: Previously a fix was made to avoid issues with extremely small > > > hblanks, called the "Min Hblank Fix". However, this can potentially > > > cause an audio hang. > > > > > > Workaround : > > > During "Audio Programming Sequence" Audio Enabling - When DP mode is > > > enabled Set mmio offset 0x65F1C bit 18 = 1b, before step #1 "Enable > > > audio Presence Detect" > > > > > > During "Audio Programming Sequence" Audio Disabling - When DP mode is > > > enabled Clear mmio offset 0x65F1C bit 18 = 0b, after step #6 "Disable > > > Audio PD (Presence Detect)" > > > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = > > > 1b) > > > > > > v2: Update the platform checks (Jani Nikula) > > > > > > Signed-off-by: Uma Shankar > > > --- > > > drivers/gpu/drm/i915/display/intel_audio.c | 14 ++ > > > drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++ > > > 2 files changed, 17 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > > > b/drivers/gpu/drm/i915/display/intel_audio.c > > > index 07e0c73204f3..61df5115c970 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_audio.c > > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > > > @@ -512,6 +512,13 @@ static void hsw_audio_codec_disable(struct > > intel_encoder *encoder, > > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > >AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0); > > > > > > + /* > > > + * WA_14020863754: Implement Audio Workaround > > > + * Corner case with Min Hblank Fix can cause audio hang > > > + */ > > > + if (DISPLAY_VER(i915) >= 20) > > > > The workaround is currently listed as applying to both Xe2_LPD (20.00) and > > Xe2_HPD (14.01). So we should match on those precise IP versions for now. > > Future platforms and/or refreshes may or may not need this workaround and we > > don't want to just assume the workaround will carry forward forever, so the > > condition may get updated further as new platforms/IP versions are added to > > the > > driver. > > Hi Matt, > Yes, agree to limit till platforms where we have visibility. > > Should I just keep it for LNL and add BMG later once the PE changes get > merged and the > macros become available? You should probably sync with Bala on that and see what he thinks. I suspect that changes here won't conflict with anything else in the BMG enablement series, so it's probably okay to include 14.01 in the condition right away, even before that series lands, but Bala would know best. Matt > Also, will add the helper as you suggested. > > Regards, > Uma Shankar > > > > > Matt > > > > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, > > CHICKEN3_SPARE18, 0); > > > + > > > mutex_unlock(>display.audio.mutex); > > > } > > > > > > @@ -637,6 +644,13 @@ static void hsw_audio_codec_enable(struct > > intel_encoder *encoder, > > > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP)) > > > enable_audio_dsc_wa(encoder, crtc_state); > > > > > > + /* > > > + * WA_14020863754: Implement Audio Workaround > > > + * Corner case with Min Hblank Fix can cause audio hang > > > + */ > > > + if (DISPLAY_VER(i915) >= 20) > > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0, > > CHICKEN3_SPARE18); > > > + > > > /* Enable audio presence detect */ > > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder)); > > > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > > b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > > index 616e7b1275c4..6f8d33299ecd 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > > @@ -148,4 +148,7 @@ > > > #define HBLANK_START_COUNT_964 > > > #define HBLANK_START_COUNT_128 5 > > > > > > +#define AUD_CHICKENBIT_REG3 _MMIO(0x65F1C) > > > +#define CHICKEN3_SPARE18REG_BIT(18) > > > + > > > #endif /* __INTEL_AUDIO_REGS_H__ */ > > > -- > > > 2.42.0 > > > > > > > -- > > Matt Roper > > Graphics Software Engineer > > Linux GPU Platform Enablement > > Intel Corporation -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [v2] drm/i915: Implement Audio WA_14020863754
On Thu, Apr 11, 2024 at 03:36:37PM -0700, Matt Roper wrote: > On Wed, Apr 10, 2024 at 07:20:46PM +0530, Uma Shankar wrote: > > WA_14020863754: Corner case with Min Hblank Fix can cause > > audio hang > > > > Issue: Previously a fix was made to avoid issues with extremely > > small hblanks, called the "Min Hblank Fix". However, this can > > potentially cause an audio hang. > > > > Workaround : > > During "Audio Programming Sequence" Audio Enabling - > > When DP mode is enabled Set mmio offset 0x65F1C bit 18 = 1b, > > before step #1 "Enable audio Presence Detect" > > > > During "Audio Programming Sequence" Audio Disabling - > > When DP mode is enabled Clear mmio offset 0x65F1C bit 18 = 0b, > > after step #6 "Disable Audio PD (Presence Detect)" > > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = 1b) > > > > v2: Update the platform checks (Jani Nikula) > > > > Signed-off-by: Uma Shankar > > --- > > drivers/gpu/drm/i915/display/intel_audio.c | 14 ++ > > drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > > b/drivers/gpu/drm/i915/display/intel_audio.c > > index 07e0c73204f3..61df5115c970 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio.c > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > > @@ -512,6 +512,13 @@ static void hsw_audio_codec_disable(struct > > intel_encoder *encoder, > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + if (DISPLAY_VER(i915) >= 20) > > The workaround is currently listed as applying to both Xe2_LPD (20.00) > and Xe2_HPD (14.01). So we should match on those precise IP versions > for now. Future platforms and/or refreshes may or may not need this > workaround and we don't want to just assume the workaround will carry > forward forever, so the condition may get updated further as new > platforms/IP versions are added to the driver. Also, since this is a workaround that requires logic in multiple spots and already applies to multiple IP versions, it may be a good idea to separate out the condition into a helper function so that if/when new versions get added to the list in the future we can update a single place rather than tracking down multiple 'if' statements. Matt > > > Matt > > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, CHICKEN3_SPARE18, 0); > > + > > mutex_unlock(>display.audio.mutex); > > } > > > > @@ -637,6 +644,13 @@ static void hsw_audio_codec_enable(struct > > intel_encoder *encoder, > > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP)) > > enable_audio_dsc_wa(encoder, crtc_state); > > > > + /* > > +* WA_14020863754: Implement Audio Workaround > > +* Corner case with Min Hblank Fix can cause audio hang > > +*/ > > + if (DISPLAY_VER(i915) >= 20) > > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0, CHICKEN3_SPARE18); > > + > > /* Enable audio presence detect */ > > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, > > 0, AUDIO_OUTPUT_ENABLE(cpu_transcoder)); > > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > index 616e7b1275c4..6f8d33299ecd 100644 > > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h > > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h > > @@ -148,4 +148,7 @@ > > #define HBLANK_START_COUNT_96 4 > > #define HBLANK_START_COUNT_128 5 > > > > +#define AUD_CHICKENBIT_REG3_MMIO(0x65F1C) > > +#define CHICKEN3_SPARE18 REG_BIT(18) > > + > > #endif /* __INTEL_AUDIO_REGS_H__ */ > > -- > > 2.42.0 > > > > -- > Matt Roper > Graphics Software Engineer > Linux GPU Platform Enablement > Intel Corporation -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [v2] drm/i915: Implement Audio WA_14020863754
On Wed, Apr 10, 2024 at 07:20:46PM +0530, Uma Shankar wrote: > WA_14020863754: Corner case with Min Hblank Fix can cause > audio hang > > Issue: Previously a fix was made to avoid issues with extremely > small hblanks, called the "Min Hblank Fix". However, this can > potentially cause an audio hang. > > Workaround : > During "Audio Programming Sequence" Audio Enabling - > When DP mode is enabled Set mmio offset 0x65F1C bit 18 = 1b, > before step #1 "Enable audio Presence Detect" > > During "Audio Programming Sequence" Audio Disabling - > When DP mode is enabled Clear mmio offset 0x65F1C bit 18 = 0b, > after step #6 "Disable Audio PD (Presence Detect)" > If not clearing PD bit, must also not clear 0x65F1C bit 18 (leave = 1b) > > v2: Update the platform checks (Jani Nikula) > > Signed-off-by: Uma Shankar > --- > drivers/gpu/drm/i915/display/intel_audio.c | 14 ++ > drivers/gpu/drm/i915/display/intel_audio_regs.h | 3 +++ > 2 files changed, 17 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c > b/drivers/gpu/drm/i915/display/intel_audio.c > index 07e0c73204f3..61df5115c970 100644 > --- a/drivers/gpu/drm/i915/display/intel_audio.c > +++ b/drivers/gpu/drm/i915/display/intel_audio.c > @@ -512,6 +512,13 @@ static void hsw_audio_codec_disable(struct intel_encoder > *encoder, > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, >AUDIO_OUTPUT_ENABLE(cpu_transcoder), 0); > > + /* > + * WA_14020863754: Implement Audio Workaround > + * Corner case with Min Hblank Fix can cause audio hang > + */ > + if (DISPLAY_VER(i915) >= 20) The workaround is currently listed as applying to both Xe2_LPD (20.00) and Xe2_HPD (14.01). So we should match on those precise IP versions for now. Future platforms and/or refreshes may or may not need this workaround and we don't want to just assume the workaround will carry forward forever, so the condition may get updated further as new platforms/IP versions are added to the driver. Matt > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, CHICKEN3_SPARE18, 0); > + > mutex_unlock(>display.audio.mutex); > } > > @@ -637,6 +644,13 @@ static void hsw_audio_codec_enable(struct intel_encoder > *encoder, > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP)) > enable_audio_dsc_wa(encoder, crtc_state); > > + /* > + * WA_14020863754: Implement Audio Workaround > + * Corner case with Min Hblank Fix can cause audio hang > + */ > + if (DISPLAY_VER(i915) >= 20) > + intel_de_rmw(i915, AUD_CHICKENBIT_REG3, 0, CHICKEN3_SPARE18); > + > /* Enable audio presence detect */ > intel_de_rmw(i915, HSW_AUD_PIN_ELD_CP_VLD, >0, AUDIO_OUTPUT_ENABLE(cpu_transcoder)); > diff --git a/drivers/gpu/drm/i915/display/intel_audio_regs.h > b/drivers/gpu/drm/i915/display/intel_audio_regs.h > index 616e7b1275c4..6f8d33299ecd 100644 > --- a/drivers/gpu/drm/i915/display/intel_audio_regs.h > +++ b/drivers/gpu/drm/i915/display/intel_audio_regs.h > @@ -148,4 +148,7 @@ > #define HBLANK_START_COUNT_964 > #define HBLANK_START_COUNT_128 5 > > +#define AUD_CHICKENBIT_REG3 _MMIO(0x65F1C) > +#define CHICKEN3_SPARE18REG_BIT(18) > + > #endif /* __INTEL_AUDIO_REGS_H__ */ > -- > 2.42.0 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v2 19/25] drm/i915/xe2hpd: Do not program MBUS_DBOX BW credits
On Wed, Apr 03, 2024 at 04:52:47PM +0530, Balasubramani Vivekanandan wrote:
> From: José Roberto de Souza
>
> Xe2_HPD doesn't have DBOX BW credits, so here programing it with
> zero.
>
> BSpec: 49213
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index bc341abcab2f..22ae782e89f4 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3733,7 +3733,7 @@ void intel_mbus_dbox_update(struct intel_atomic_state
> *state)
> if (!new_crtc_state->hw.active)
> continue;
>
> - if (DISPLAY_VER(i915) >= 14) {
> + if (DISPLAY_VER(i915) >= 14 && !IS_BATTLEMAGE(i915)) {
It looks like the "BW Credits" field from MBUS_DBOX_CTL doesn't exist on
any platform past Xe_LPD+. I.e., it isn't there on Xe2_LPD (version 20)
either. So we should probably make this block an exact match on version
14.0 only.
if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0))
so that it doesn't execute on anything else.
Matt
> if (xelpdp_is_only_pipe_per_dbuf_bank(crtc->pipe,
>
> new_dbuf_state->active_pipes))
> pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 13/25] drm/i915/xe2hpd: Add display info
On Wed, Apr 03, 2024 at 04:52:41PM +0530, Balasubramani Vivekanandan wrote:
> From: Lucas De Marchi
>
> Add initial display info for xe2hpd. It is similar to xelpd, but with no
> PORT_B.
>
> Bspec: 67066
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> .../gpu/drm/i915/display/intel_display_device.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index b8903bd0e82a..0a26012041e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -771,6 +771,21 @@ static const struct intel_display_device_info
> xe2_lpd_display = {
> BIT(INTEL_FBC_C) | BIT(INTEL_FBC_D),
> };
>
> +static const struct intel_display_device_info xe2_hpd_display = {
> + XE_LPD_FEATURES,
Don't we want to derive from XE_LPDP_FEATURES rather than
XE_LPD_FEATURES? If so, that takes care of initializing most of this
structure, aside from port_mask.
> + .has_cdclk_crawl = 1,
> + .has_cdclk_squash = 1,
> +
> + .__runtime_defaults.ip.ver = 14,
> + .__runtime_defaults.ip.rel = 1,
We're not supposed to have version numbers in these structures for
platforms that have GMD_ID (there might not even be just one version
number associated with the IP). The gmdid_display_map[] is the only
place where we need to map one or more version numbers to an info
structure.
Matt
> + .__runtime_defaults.fbc_mask = BIT(INTEL_FBC_A) | BIT(INTEL_FBC_B),
> + .__runtime_defaults.cpu_transcoder_mask =
> + BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> + .__runtime_defaults.port_mask = BIT(PORT_A) |
> + BIT(PORT_TC1) | BIT(PORT_TC2) | BIT(PORT_TC3) | BIT(PORT_TC4),
> +};
> +
> __diag_pop();
>
> /*
> @@ -852,6 +867,7 @@ static const struct {
> const struct intel_display_device_info *display;
> } gmdid_display_map[] = {
> { 14, 0, _lpdp_display },
> + { 14, 1, _hpd_display },
> { 20, 0, _lpd_display },
> };
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 14/25] drm/i915/xe2hpd: Add missing chicken bit register programming
On Wed, Apr 03, 2024 at 04:52:42PM +0530, Balasubramani Vivekanandan wrote: > From: Anusha Srivatsa > > Add step 9 from initialize display sequence. > > Bpsec: 49189 > Signed-off-by: Anusha Srivatsa > Signed-off-by: Balasubramani Vivekanandan > I think the title here is misleading since "missing" makes it sound like we overlooked something previously, whereas in reality this is just a new required step on Xe2_HPD. A title like "Configure CHICKEN_MISC_2 before enabling planes" would probably be more accurate. With updated wording, Reviewed-by: Matt Roper Matt > --- > drivers/gpu/drm/i915/display/intel_display_power.c | 4 > drivers/gpu/drm/i915/i915_reg.h| 1 + > 2 files changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index 6fd4fa52253a..bf9685acf75a 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1694,6 +1694,10 @@ static void icl_display_core_init(struct > drm_i915_private *dev_priv, > if (IS_DG2(dev_priv)) > intel_snps_phy_wait_for_calibration(dev_priv); > > + /* 9. XE2_HPD: Program CHICKEN_MISC_2 before any cursor or planes are > enabled */ > + if (DISPLAY_VER_FULL(dev_priv) == IP_VER(14, 1)) > + intel_de_rmw(dev_priv, CHICKEN_MISC_2, > BMG_DARB_HALF_BLK_END_BURST, 1); > + > if (resume) > intel_dmc_load_program(dev_priv); > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 58f3e4bfe254..875d76fb8cd0 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -4548,6 +4548,7 @@ > > #define CHICKEN_MISC_2 _MMIO(0x42084) > #define CHICKEN_MISC_DISABLE_DPT REG_BIT(30) /* adl,dg2 */ > +#define BMG_DARB_HALF_BLK_END_BURSTREG_BIT(27) > #define KBL_ARB_FILL_SPARE_14 REG_BIT(14) > #define KBL_ARB_FILL_SPARE_13 REG_BIT(13) > #define GLK_CL2_PWR_DOWN REG_BIT(12) > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v2 12/25] drm/i915/xe2hpd: update pll values in sync with Bspec
On Wed, Apr 03, 2024 at 04:52:40PM +0530, Balasubramani Vivekanandan wrote:
> From: Ravi Kumar Vodapalli
>
> DP/eDP and HDMI pll values are updated for Xe2_HPD platform
>
> Bspec: 74165
> Signed-off-by: Ravi Kumar Vodapalli
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 47 +++-
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index d948035f07ad..20035be015c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -1109,6 +1109,42 @@ static const struct intel_c20pll_state * const
> xe2hpd_c20_edp_tables[] = {
> NULL,
> };
>
> +static const struct intel_c20pll_state xe2hpd_c20_dp_uhbr13_5 = {
> + .clock = 135, /* 13.5 Gbps */
> + .tx = { 0xbea0, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x015f, /* mpllb cfg0 */
> + 0x2205, /* mpllb cfg1 */
> + 0x1b17, /* mpllb cfg2 */
> + 0xffc1, /* mpllb cfg3 */
> + 0xbd00, /* mpllb cfg4 */
> + 0x9ec3, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x4800, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state * const xe2hpd_c20_dp_tables[] = {
> + _c20_dp_rbr,
> + _c20_dp_hbr1,
> + _c20_dp_hbr2,
> + _c20_dp_hbr3,
> + _c20_dp_uhbr10,
> + _c20_dp_uhbr13_5,
> + _c20_dp_uhbr20,
According to bspec 67066, I don't think we need the UHBR20 table for
Xe2_HPD (even though there are data values given on page 74165).
Otherwise,
Reviewed-by: Matt Roper
Matt
> + NULL,
> +};
> +
> /*
> * HDMI link rates with 38.4 MHz reference clock.
> */
> @@ -2225,13 +2261,20 @@ static const struct intel_c20pll_state * const *
> intel_c20_pll_tables_get(struct intel_crtc_state *crtc_state,
>struct intel_encoder *encoder)
> {
> - if (intel_crtc_has_dp_encoder(crtc_state))
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + if (intel_crtc_has_dp_encoder(crtc_state)) {
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP))
> return xe2hpd_c20_edp_tables;
> +
> + if (DISPLAY_VER_FULL(i915) == IP_VER(14, 1))
> + return xe2hpd_c20_dp_tables;
> else
> return mtl_c20_dp_tables;
> - else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> +
> + } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> return mtl_c20_hdmi_tables;
> + }
>
> MISSING_CASE(encoder->type);
> return NULL;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 11/25] drm/i915/xe2hpd: Add support for eDP PLL configuration
On Wed, Apr 03, 2024 at 04:52:39PM +0530, Balasubramani Vivekanandan wrote:
> Tables for eDP PHY PLL configuration for different link rates added for
> Xe2_HPD. Previous platforms were using C10 PHY for eDP port whereas
> Xe2_HPD has C20 PHY.
>
> Bpsec: 64568
I think 74165 would be more accurate?
Otherwise the tables below match the current spec, so
Reviewed-by: Matt Roper
>
> CC: Clint Taylor
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 147 ++-
> 1 file changed, 146 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 6e4647859fc6..d948035f07ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -967,6 +967,148 @@ static const struct intel_c20pll_state * const
> mtl_c20_dp_tables[] = {
> NULL,
> };
>
> +/*
> + * eDP link rates with 38.4 MHz reference clock.
> + */
> +
> +static const struct intel_c20pll_state xe2hpd_c20_edp_r216 = {
> + .clock = 216000,
> + .tx = { 0xbe88,
> + 0x4800,
> + 0x,
> + },
> + .cmn = { 0x0500,
> + 0x0005,
> + 0x,
> + 0x,
> + },
> + .mpllb = { 0x50e1,
> +0x2120,
> +0x8e18,
> +0xbfc1,
> +0x9000,
> +0x78f6,
> +0x,
> +0x,
> +0x,
> +0x,
> +0x,
> + },
> +};
> +
> +static const struct intel_c20pll_state xe2hpd_c20_edp_r243 = {
> + .clock = 243000,
> + .tx = { 0xbe88,
> + 0x4800,
> + 0x,
> + },
> + .cmn = { 0x0500,
> + 0x0005,
> + 0x,
> + 0x,
> + },
> + .mpllb = { 0x50fd,
> +0x2120,
> +0x8f18,
> +0xbfc1,
> +0xa200,
> +0x8814,
> +0x2000,
> +0x0001,
> +0x1000,
> +0x,
> +0x,
> + },
> +};
> +
> +static const struct intel_c20pll_state xe2hpd_c20_edp_r324 = {
> + .clock = 324000,
> + .tx = { 0xbe88,
> + 0x4800,
> + 0x,
> + },
> + .cmn = { 0x0500,
> + 0x0005,
> + 0x,
> + 0x,
> + },
> + .mpllb = { 0x30a8,
> +0x2110,
> +0xcd9a,
> +0xbfc1,
> +0x6c00,
> +0x5ab8,
> +0x2000,
> +0x0001,
> +0x6000,
> +0x,
> +0x,
> + },
> +};
> +
> +static const struct intel_c20pll_state xe2hpd_c20_edp_r432 = {
> + .clock = 432000,
> + .tx = { 0xbe88,
> + 0x4800,
> + 0x,
> + },
> + .cmn = { 0x0500,
> + 0x0005,
> + 0x,
> + 0x,
> + },
> + .mpllb = { 0x30e1,
> +0x2110,
> +0x8e18,
> +0xbfc1,
> +0x9000,
> +0x78f6,
> +0x,
> +0x,
> +0x,
> +0x,
> +0x,
> + },
> +};
> +
> +static const struct intel_c20pll_state xe2hpd_c20_edp_r675 = {
> + .clock = 675000,
> + .tx = { 0xbe88,
> + 0x4800,
> + 0x,
> + },
> + .cmn = { 0x0500,
> + 0x0005,
> + 0x,
> + 0x,
> + },
> + .mpllb = { 0x10af,
> +0x2108,
> +0xce1a,
> +0xbfc1,
> +0x7080,
> +0x5e80,
> +0x2000,
> +0x0001,
> +0x6400,
> +0x,
> +0x,
> + },
> +};
> +
> +static const struct intel_c20pll_state * const xe2hpd_c20_edp_tables[] = {
> + _c20_dp_rbr,
> + _c20_edp_r216,
> + _c20_edp_r243,
> + _c20_dp_hbr1,
> + _c20_edp_r324,
> + _c20_edp_r432,
> + _c20_dp_hbr2,
> + _c20_edp_r675,
> + _c20_dp_hbr3,
> + NULL,
> +};
> +
> /*
Re: [PATCH v2 09/25] drm/i915/xe2hpd: Properly disable power in port A
On Wed, Apr 03, 2024 at 04:52:37PM +0530, Balasubramani Vivekanandan wrote:
> From: José Roberto de Souza
>
> Xe2_HPD has a different value to power down port A.
>
> BSpec: 65450
> CC: Matt Roper
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 13a2e3db2812..caaae5d3758e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2921,17 +2921,28 @@ void intel_mtl_pll_enable(struct intel_encoder
> *encoder,
> intel_cx0pll_enable(encoder, crtc_state);
> }
>
> +static u8 cx0_power_control_disable_val(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + if (intel_encoder_is_c10phy(encoder))
> + return CX0_P2PG_STATE_DISABLE;
> +
> + if (IS_BATTLEMAGE(i915) && encoder->port == PORT_A)
> + return CX0_P2PG_STATE_DISABLE;
> +
> + return CX0_P4PG_STATE_DISABLE;
> +}
> +
> static void intel_cx0pll_disable(struct intel_encoder *encoder)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> enum phy phy = intel_encoder_to_phy(encoder);
> - bool is_c10 = intel_encoder_is_c10phy(encoder);
> intel_wakeref_t wakeref = intel_cx0_phy_transaction_begin(encoder);
>
> /* 1. Change owned PHY lane power to Disable state. */
> intel_cx0_powerdown_change_sequence(encoder, INTEL_CX0_BOTH_LANES,
> - is_c10 ? CX0_P2PG_STATE_DISABLE :
> - CX0_P4PG_STATE_DISABLE);
> +
> cx0_power_control_disable_val(encoder));
>
> /*
>* 2. Follow the Display Voltage Frequency Switching Sequence Before
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 08/25] drm/i915/bmg: Extend DG2 tc check to future
On Wed, Apr 03, 2024 at 04:52:36PM +0530, Balasubramani Vivekanandan wrote:
> From: Radhakrishna Sripada
>
> Discrete cards use the Port numbers TC1-4 for the offsets. The regular
> flow for type-c subsystem port initialization can be skipped. This check
> is present in DG2. Extend this to future discrete products.
>
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 614e60420a29..aed25890b6f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1861,11 +1861,10 @@ bool intel_phy_is_combo(struct drm_i915_private
> *dev_priv, enum phy phy)
> bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> {
> /*
> - * DG2's "TC1", although TC-capable output, doesn't share the same flow
> - * as other platforms on the display engine side and rather rely on the
> - * SNPS PHY, that is programmed separately
> + * Discrete GPU phy's are not attached to FIA's to support TC
> + * subsystem Legacy or non-legacy, and only support native DP/HDMI
>*/
> - if (IS_DG2(dev_priv))
> + if (IS_DGFX(dev_priv))
> return false;
>
> if (DISPLAY_VER(dev_priv) >= 13)
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 07/25] Revert "drm/i915/dgfx: DGFX uses direct VBT pin mapping"
On Wed, Apr 03, 2024 at 04:52:35PM +0530, Balasubramani Vivekanandan wrote:
> From: Ankit Nautiyal
>
> This reverts commit 562f33836f519a235e5c5e71bcc723ab1faccd2f.
> For BMG it seems that the VBT to DDI mapping does not follow DG1, and
> DG2, but follows ADLP mapping given in Bspec:20124.
>
> Signed-off-by: Ankit Nautiyal
> Signed-off-by: Balasubramani Vivekanandan
>
Matches our experimental findings, so
Reviewed-by: Matt Roper
I've pinged the internal ticket to try to get the documentation for this
clarified.
BTW, if you send another version of this series it might make more sense
to re-order this to be after patch #20, since that's where we define
which south display (i.e., "fake pch") is used on BMG.
Matt
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 2abd2d7ceda2..03fbd6c73f3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2238,15 +2238,14 @@ static u8 map_ddc_pin(struct drm_i915_private *i915,
> u8 vbt_pin)
> const u8 *ddc_pin_map;
> int i, n_entries;
>
> - if (IS_DGFX(i915))
> - return vbt_pin;
> -
> if (INTEL_PCH_TYPE(i915) >= PCH_MTL || IS_ALDERLAKE_P(i915)) {
> ddc_pin_map = adlp_ddc_pin_map;
> n_entries = ARRAY_SIZE(adlp_ddc_pin_map);
> } else if (IS_ALDERLAKE_S(i915)) {
> ddc_pin_map = adls_ddc_pin_map;
> n_entries = ARRAY_SIZE(adls_ddc_pin_map);
> + } else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
> + return vbt_pin;
> } else if (IS_ROCKETLAKE(i915) && INTEL_PCH_TYPE(i915) == PCH_TGP) {
> ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
> n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 06/25] drm/i915/xe2hpd: Initial cdclk table
On Wed, Apr 03, 2024 at 04:52:34PM +0530, Balasubramani Vivekanandan wrote:
> From: Clint Taylor
>
> Add Xe2_HPD specific CDCLK table and use MTL Funcs.
>
> Bspec: 65243
> Cc: Matt Roper
> CC: Lucas De Marchi
> Signed-off-by: Clint Taylor
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 31aaa9780dfc..da16c308670f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1444,6 +1444,14 @@ static const struct intel_cdclk_vals
> xe2lpd_cdclk_table[] = {
> {}
> };
>
> +/*
> + * Xe2_HPD always uses the minimal cdclk table from Wa_15015413771
> + */
> +static const struct intel_cdclk_vals xe2hpd_cdclk_table[] = {
> + { .refclk = 38400, .cdclk = 652800, .ratio = 34, .waveform = 0x },
> + {}
> +};
> +
> static const int cdclk_squash_len = 16;
>
> static int cdclk_squash_divider(u16 waveform)
> @@ -3768,6 +3776,9 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 20) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = xe2lpd_cdclk_table;
> + } else if (DISPLAY_VER_FULL(dev_priv) >= IP_VER(14, 1)) {
> + dev_priv->display.funcs.cdclk = _cdclk_funcs;
> + dev_priv->display.cdclk.table = xe2hpd_cdclk_table;
> } else if (DISPLAY_VER(dev_priv) >= 14) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = mtl_cdclk_table;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 05/25] drm/i915/xe2: Skip CCS modifiers for Xe2 platforms
On Wed, Apr 03, 2024 at 04:52:33PM +0530, Balasubramani Vivekanandan wrote:
> Xe2 platforms doesn't support Aux CCS and the Flat CCS is enabled
> through PAT. No CCS modifiers required for Xe2 platforms.
The change looks correct, but you might want to elaborate on this
description a bit to help clarify why having the compression status of a
buffer in the page table entries (via PAT) allows us to avoid the need
for dedicated framebuffer modifiers.
Matt
>
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 3ea6470d6d92..923e97c3aa6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -431,9 +431,17 @@ static bool plane_has_modifier(struct drm_i915_private
> *i915,
>* Separate AuxCCS and Flat CCS modifiers to be run only on platforms
>* where supported.
>*/
> - if (intel_fb_is_ccs_modifier(md->modifier) &&
> - HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
> - return false;
> + if (intel_fb_is_ccs_modifier(md->modifier)) {
> + /*
> + * No CCS modifiers available on Xe2 platforms as they don't
> + * support Aux CCS and the Flat CCS is enabled via PAT
> + */
> + if ((DISPLAY_VER(i915) >= 20) || IS_BATTLEMAGE(i915))
> + return false;
> +
> + if (HAS_FLAT_CCS(i915) != !md->ccs.packed_aux_planes)
> + return false;
> + }
>
> return true;
> }
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 04/25] drm/i915/bmg: Define IS_BATTLEMAGE macro
On Wed, Apr 03, 2024 at 04:52:32PM +0530, Balasubramani Vivekanandan wrote:
> Display code uses IS_BATTLEMAGE macro but the platform support doesn't
> still exist in i915. So fake IS_BATTLEMAGE macro defined to enable
I'd drop the "still" here since that wording would incorrectly imply
that i915 had Battlemage support previously.
Otherwise,
Reviewed-by: Matt Roper
Matt
> building i915 code. We should make sure the macro parameter is used in
> the always-false expression so that we don't run into "unused variable"
> warnings from i915 builds if the IS_BATTLEMAGE() check is the only place
> the i915 pointer gets used in a function.
>
> While we're at it, also update the IS_LUNARLAKE macro to include the
> parameter in the false expression for consistency.
>
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index cf52d4adaa20..b41a414079f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -546,7 +546,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_ALDERLAKE_P(i915) IS_PLATFORM(i915, INTEL_ALDERLAKE_P)
> #define IS_DG2(i915) IS_PLATFORM(i915, INTEL_DG2)
> #define IS_METEORLAKE(i915) IS_PLATFORM(i915, INTEL_METEORLAKE)
> -#define IS_LUNARLAKE(i915) 0
> +/*
> + * Display code shared by i915 and Xe relies on macros like IS_LUNARLAKE,
> + * so we need to define these even on platforms that the i915 base driver
> + * doesn't support. Ensure the parameter is used in the definition to
> + * avoid 'unused variable' warnings when compiling the shared display code
> + * for i915.
> + */
> +#define IS_LUNARLAKE(i915) (0 && i915)
> +#define IS_BATTLEMAGE(i915) (0 && i915)
>
> #define IS_DG2_G10(i915) \
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 03/25] drm/xe/bmg: Define IS_BATTLEMAGE macro
On Wed, Apr 03, 2024 at 04:52:31PM +0530, Balasubramani Vivekanandan wrote: > Common display code requires IS_BATTLEMAGE macro. Defined the macro. > > Signed-off-by: Balasubramani Vivekanandan > Reviewed-by: Matt Roper > --- > drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h | 1 + > 1 file changed, 1 insertion(+) > > 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..9161d1fdf239 100644 > --- a/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h > +++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h > @@ -88,6 +88,7 @@ static inline struct drm_i915_private *kdev_to_i915(struct > device *kdev) > #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) > +#define IS_BATTLEMAGE(dev_priv) IS_PLATFORM(dev_priv, XE_BATTLEMAGE) > > #define IS_HASWELL_ULT(dev_priv) (dev_priv && 0) > #define IS_BROADWELL_ULT(dev_priv) (dev_priv && 0) > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v2 18/25] drm/i915/display: Enable RM timeout detection
On Wed, Apr 03, 2024 at 04:52:46PM +0530, Balasubramani Vivekanandan wrote:
> From: Mitul Golani
>
> Enable RM timeout interrupt to detect any hang during display engine
> register access. This interrupt is supported only on Display version 14.
This doesn't seem to be true. Bit 29 of the IIR register is still there
on Xe2_LPD (version 20) and I see no reason to believe it won't continue
to be present after that.
It doesn't seem like this patch should even be part of the BMG series.
This was a new interrupt bit first added back on MTL/ARL and continuing
onward from there. It's basically a "hardware is broken" interrupt that
might be useful for debugging, but we hope to never actually see it show
up. It isn't something that's related to the general enabling of any
specific platform, especially since it's something the hardware already
supports on a few other platforms already present in the Xe driver.
> Current default timeout is 2ms.
>
> WA: 14012195489
As Jani noted, this doesn't belong as a trailer. But it's also untrue;
this isn't related to any kind of workaround and the number here doesn't
reference anything in the workaround database.
> Bspec: 50110
>
> CC: Suraj Kandpal
> Signed-off-by: Mitul Golani
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 10 ++
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index f846c5b108b5..3035b50fcad9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -851,6 +851,13 @@ gen8_de_misc_irq_handler(struct drm_i915_private
> *dev_priv, u32 iir)
> {
> bool found = false;
>
> + if (iir & GEN8_DE_RM_TIMEOUT) {
> + u32 val = intel_uncore_read(_priv->uncore,
> + RMTIMEOUTREG_CAPTURE);
> + drm_warn(_priv->drm, "Register Access Timeout = 0x%x\n",
> val);
> + found = true;
> + }
> +
> if (DISPLAY_VER(dev_priv) >= 14) {
> if (iir & (XELPDP_PMDEMAND_RSP |
> XELPDP_PMDEMAND_RSPTOUT_ERR)) {
> @@ -1666,6 +1673,9 @@ void gen8_de_irq_postinstall(struct drm_i915_private
> *dev_priv)
> de_port_masked |= DSI0_TE | DSI1_TE;
> }
>
> + if (DISPLAY_VER(dev_priv) == 14)
> + de_misc_masked |= GEN8_DE_RM_TIMEOUT;
> +
> de_pipe_enables = de_pipe_masked |
> GEN8_PIPE_VBLANK |
> gen8_de_pipe_underrun_mask(dev_priv) |
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 875d76fb8cd0..d1692b32bb8a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4212,6 +4212,8 @@
> #define RM_TIMEOUT _MMIO(0x42060)
> #define MMIO_TIMEOUT_US(us) ((us) << 0)
>
> +#define RMTIMEOUTREG_CAPTURE _MMIO(0x420e0)
> +
> /* interrupts */
> #define DE_MASTER_IRQ_CONTROL (1 << 31)
> #define DE_SPRITEB_FLIP_DONE(1 << 29)
> @@ -4398,6 +4400,7 @@
> #define GEN8_DE_MISC_IMR _MMIO(0x44464)
> #define GEN8_DE_MISC_IIR _MMIO(0x44468)
> #define GEN8_DE_MISC_IER _MMIO(0x4446c)
> +#define GEN8_DE_RM_TIMEOUT REG_BIT(29)
Given that this was first introduced in Xe_LPD+, the "GEN8" prefix here
is inappropriate.
Matt
> #define XELPDP_PMDEMAND_RSPTOUT_ERR REG_BIT(27)
> #define GEN8_DE_MISC_GSEREG_BIT(27)
> #define GEN8_DE_EDP_PSR REG_BIT(19)
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v7 2/3] drm/i915/gt: Do not generate the command streamer for all the CCS
On Wed, Mar 27, 2024 at 04:56:18PM +0100, Andi Shyti wrote:
> We want a fixed load CCS balancing consisting in all slices
> sharing one single user engine. For this reason do not create the
> intel_engine_cs structure with its dedicated command streamer for
> CCS slices beyond the first.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> Acked-by: Michal Mrozek
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index f553cf4e6449..47c4a69e854c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -908,6 +908,21 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
> info->engine_mask &= ~BIT(GSC0);
> }
>
> + /*
> + * Do not create the command streamer for CCS slices beyond the first.
> + * All the workload submitted to the first engine will be shared among
> + * all the slices.
> + *
> + * Once the user will be allowed to customize the CCS mode, then this
> + * check needs to be removed.
> + */
> + if (IS_DG2(gt->i915)) {
> + intel_engine_mask_t first_ccs = BIT((CCS0 +
> __ffs(CCS_MASK(gt;
> + intel_engine_mask_t all_ccs = CCS_MASK(gt) << CCS0;
> +
> + info->engine_mask &= ~(all_ccs &= ~first_ccs);
Shouldn't the second "&=" just be an "&" since there's no need to modify
the all_ccs variable that never gets used again?
In fact since this is DG2-specific, it seems like it might be more
intuitive to just write the whole thing more directly as
if (IS_DG2(gt->i915)) {
int first_ccs = __ffs(CCS_MASK(gt));
info->engine_mask &= ~GENMASK(CCS3, CCS0);
info->engine_mask |= BIT(_CCS(first_ccs));
}
But up to you; if you just want to remove the unnecessary "=" that's
fine too. Either way,
Reviewed-by: Matt Roper
Matt
> + }
> +
> return info->engine_mask;
> }
>
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: ✗ Fi.CI.BAT: failure for drm/i915: Add new PCI IDs to DG2 platform in driver
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> - bat-dg1-7: NOTRUN -> [SKIP][16] ([i915#4103] / [i915#4213]) +1
> other test skip
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
>
> * igt@kms_dsc@dsc-basic:
> - bat-dg1-7: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#3840])
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_...@dsc-basic.html
>
> * igt@kms_force_connector_basic@force-load-detect:
> - bat-dg1-7: NOTRUN -> [SKIP][18]
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_force_connector_ba...@force-load-detect.html
>
> * igt@kms_hdmi_inject@inject-audio:
> - bat-dg1-7: NOTRUN -> [SKIP][19] ([i915#433])
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_hdmi_inj...@inject-audio.html
>
> * igt@kms_pm_backlight@basic-brightness:
> - bat-dg1-7: NOTRUN -> [SKIP][20] ([i915#5354])
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_pm_backli...@basic-brightness.html
>
> * igt@kms_psr@psr-primary-page-flip:
> - bat-dg1-7: NOTRUN -> [SKIP][21] ([i915#1072] / [i915#9732]) +3
> other tests skip
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_...@psr-primary-page-flip.html
>
> * igt@kms_setmode@basic-clone-single-crtc:
> - bat-dg1-7: NOTRUN -> [SKIP][22] ([i915#3555])
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@kms_setm...@basic-clone-single-crtc.html
>
> * igt@prime_vgem@basic-fence-flip:
> - bat-dg1-7: NOTRUN -> [SKIP][23] ([i915#3708]) +3 other tests
> skip
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@prime_v...@basic-fence-flip.html
>
> * igt@prime_vgem@basic-fence-mmap:
> - bat-dg1-7: NOTRUN -> [SKIP][24] ([i915#3708] / [i915#4077]) +1
> other test skip
>[24]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg1-7/igt@prime_v...@basic-fence-mmap.html
>
>
> Possible fixes
>
> * igt@i915_selftest@live@ring_submission:
> - bat-dg2-14: [ABORT][25] ([i915#10366]) -> [PASS][26]
>[25]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14489/bat-dg2-14/igt@i915_selftest@live@ring_submission.html
>[26]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/bat-dg2-14/igt@i915_selftest@live@ring_submission.html
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [i915#10234]: https://gitlab.freedesktop.org/drm/intel/issues/10234
> [i915#10262]: https://gitlab.freedesktop.org/drm/intel/issues/10262
> [i915#10366]: https://gitlab.freedesktop.org/drm/intel/issues/10366
> [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
> [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
> [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
> [i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
> [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
> [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
> [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
> [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
> [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
> [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
> [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
> [i915#433]: https://gitlab.freedesktop.org/drm/intel/issues/433
> [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
> [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
> [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
> [i915#9732]: https://gitlab.freedesktop.org/drm/intel/issues/9732
>
>
> Build changes
> -
>
> * Linux: CI_DRM_14489 -> Patchwork_131625v1
>
> CI-20190529: 20190529
> CI_DRM_14489: f9c56f1a03b5c35488671e4ffe61e28b12ffe163 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7785: 7785
> Patchwork_131625v1: f9c56f1a03b5c35488671e4ffe61e28b12ffe163 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> ### Linux commits
>
> a50860ce8e96 drm/i915: Add new PCI IDs to DG2 platform in driver
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131625v1/index.html
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v6 2/3] drm/i915/gt: Do not generate the command streamer for all the CCS
On Tue, Mar 26, 2024 at 07:42:34PM +0100, Andi Shyti wrote: > Hi Matt, > > On Tue, Mar 26, 2024 at 09:03:10AM -0700, Matt Roper wrote: > > On Wed, Mar 13, 2024 at 09:19:50PM +0100, Andi Shyti wrote: > > > + /* > > > + * Do not create the command streamer for CCS slices > > > + * beyond the first. All the workload submitted to the > > > + * first engine will be shared among all the slices. > > > + * > > > + * Once the user will be allowed to customize the CCS > > > + * mode, then this check needs to be removed. > > > + */ > > > + if (IS_DG2(i915) && > > > + class == COMPUTE_CLASS && > > > + ccs_instance++) > > > + continue; > > > > Wouldn't it be more intuitive to drop the non-lowest CCS engines in > > init_engine_mask() since that's the function that's dedicated to > > building the list of engines we'll use? Then we don't need to kill the > > assertion farther down either. > > Because we don't check the result of init_engine_mask() while > creating the engine's structure. We check it only after and > indeed I removed the drm_WARN_ON() check. > > I think the whole process of creating the engine's structure in > the intel_engines_init_mmio() can be simplified, but this goes > beyong the scope of the series. > > Or am I missing something? The important part of init_engine_mask isn't the return value, but rather that it's what sets up gt->info.engine_mask. The HAS_ENGINE() check that intel_engines_init_mmio() uses is based on the value stored there, so updating that function will also ensure that we skip the engines we don't want in the loop. Matt > > Thanks, > Andi -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH] drm/i915: Add new PCI IDs to DG2 platform in driver
On Tue, Mar 26, 2024 at 04:02:41PM +0530, Ravi Kumar Vodapalli wrote: > New PCI IDs are added in Bspec for DG2 platform, add them in driver > > Bspec: 44477 > Signed-off-by: Ravi Kumar Vodapalli Reviewed-by: Matt Roper > --- > include/drm/i915_pciids.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index 28a96aa1e08f..85ce33ad6e26 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -711,7 +711,9 @@ > INTEL_VGA_DEVICE(0x5692, info), \ > INTEL_VGA_DEVICE(0x56A0, info), \ > INTEL_VGA_DEVICE(0x56A1, info), \ > - INTEL_VGA_DEVICE(0x56A2, info) > + INTEL_VGA_DEVICE(0x56A2, info), \ > + INTEL_VGA_DEVICE(0x56BE, info), \ > + INTEL_VGA_DEVICE(0x56BF, info) > > #define INTEL_DG2_G11_IDS(info) \ > INTEL_VGA_DEVICE(0x5693, info), \ > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v6 3/3] drm/i915/gt: Enable only one CCS for compute workload
On Wed, Mar 13, 2024 at 09:19:51PM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
>
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 39 +
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 13 +++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7
> 5 files changed, 65 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 3ef6ed41e62b..a6885a1d41a1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -118,6 +118,7 @@ gt-y += \
> gt/intel_ggtt_fencing.o \
> gt/intel_gt.o \
> gt/intel_gt_buffer_pool.o \
> + gt/intel_gt_ccs_mode.o \
> gt/intel_gt_clock_utils.o \
> gt/intel_gt_debugfs.o \
> gt/intel_gt_engines_debugfs.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> new file mode 100644
> index ..044219c5960a
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_gt.h"
> +#include "intel_gt_ccs_mode.h"
> +#include "intel_gt_regs.h"
> +
> +void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +{
> + int cslice;
> + u32 mode = 0;
> + int first_ccs = __ffs(CCS_MASK(gt));
> +
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + /* Build the value for the fixed CCS load balancing */
> + for (cslice = 0; cslice < I915_MAX_CCS; cslice++) {
> + if (CCS_MASK(gt) & BIT(cslice))
> + /*
> + * If available, assign the cslice
> + * to the first available engine...
> + */
> + mode |= XEHP_CCS_MODE_CSLICE(cslice, first_ccs);
> +
> + else
> + /*
> + * ... otherwise, mark the cslice as
> + * unavailable if no CCS dispatches here
> + */
> + mode |= XEHP_CCS_MODE_CSLICE(cslice,
> + XEHP_CCS_MODE_CSLICE_MASK);
> + }
> +
> + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
> +}
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> new file mode 100644
> index ..9e5549caeb26
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2024 Intel Corporation
> + */
> +
> +#ifndef __INTEL_GT_CCS_MODE_H__
> +#define __INTEL_GT_CCS_MODE_H__
> +
> +struct intel_gt;
> +
> +void intel_gt_apply_ccs_mode(struct intel_gt *gt);
> +
> +#endif /* __INTEL_GT_CCS_MODE_H__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 31b102604e3d..743fe3566722 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1480,6 +1480,11 @@
> #define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
>
> +#define XEHP_CCS_MODE_MMIO(0x14804)
> +#define XEHP_CCS_MODE_CSLICE_MASK REG_GENMASK(2, 0) /* CCS0-3 +
> rsvd */
> +#define XEHP_CCS_MODE_CSLICE_WIDTH ilog2(XEHP_CCS_MODE_CSLICE_MASK
> + 1)
> +#define XEHP_CCS_MODE_CSLICE(cslice, ccs) (ccs << (cslice *
> XEHP_CCS_MODE_CSLICE_WIDTH))
> +
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> #define CHV_FGT_DISABLE_SS1(1 << 11)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workar
Re: [PATCH v6 2/3] drm/i915/gt: Do not generate the command streamer for all the CCS
On Wed, Mar 13, 2024 at 09:19:50PM +0100, Andi Shyti wrote:
> We want a fixed load CCS balancing consisting in all slices
> sharing one single user engine. For this reason do not create the
> intel_engine_cs structure with its dedicated command streamer for
> CCS slices beyond the first.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index f553cf4e6449..c4fb31bb6e72 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -966,6 +966,7 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> const unsigned int engine_mask = init_engine_mask(gt);
> unsigned int mask = 0;
> unsigned int i, class;
> + u8 ccs_instance = 0;
> u8 logical_ids[MAX_ENGINE_INSTANCE + 1];
> int err;
>
> @@ -986,6 +987,19 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> !HAS_ENGINE(gt, i))
> continue;
>
> + /*
> + * Do not create the command streamer for CCS slices
> + * beyond the first. All the workload submitted to the
> + * first engine will be shared among all the slices.
> + *
> + * Once the user will be allowed to customize the CCS
> + * mode, then this check needs to be removed.
> + */
> + if (IS_DG2(i915) &&
> + class == COMPUTE_CLASS &&
> + ccs_instance++)
> + continue;
Wouldn't it be more intuitive to drop the non-lowest CCS engines in
init_engine_mask() since that's the function that's dedicated to
building the list of engines we'll use? Then we don't need to kill the
assertion farther down either.
Matt
> +
> err = intel_engine_setup(gt, i,
>logical_ids[instance]);
> if (err)
> @@ -996,11 +1010,9 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> }
>
> /*
> - * Catch failures to update intel_engines table when the new engines
> - * are added to the driver by a warning and disabling the forgotten
> - * engines.
> + * Update the intel_engines table.
>*/
> - if (drm_WARN_ON(>drm, mask != engine_mask))
> + if (mask != engine_mask)
> gt->info.engine_mask = mask;
>
> gt->info.num_engines = hweight32(mask);
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2] drm/i915/xelpg: Add Wa_14020495402
On Mon, Mar 18, 2024 at 02:00:25PM -0700, Radhakrishna Sripada wrote:
> Disable clockgating for TDL SVHS fub.
>
> v2: Implement in general render/compute wa's(MattR)
>
> Bspec: 46045
> Cc: Matt Roper
> Signed-off-by: Radhakrishna Sripada
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..1f778b77f4f8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1215,6 +1215,7 @@
> #define GEN12_DISABLE_EARLY_READ REG_BIT(14)
> #define GEN12_ENABLE_LARGE_GRF_MODEREG_BIT(12)
> #define GEN12_PUSH_CONST_DEREF_HOLD_DISREG_BIT(8)
> +#define XELPG_DISABLE_TDL_SVHS_GATING REG_BIT(1)
> #define GEN12_DISABLE_DOP_GATING REG_BIT(0)
>
> #define RT_CTRL MCR_REG(0xe530)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index b079cbbc1897..d2c63ecc490e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2892,10 +2892,14 @@ 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_B0, STEP_FOREVER) ||
> IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_B0, STEP_FOREVER) ||
> - IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 74), IP_VER(12, 74)))
> + IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 74), IP_VER(12, 74))) {
> /* Wa_14017856879 */
> wa_mcr_masked_en(wal, GEN9_ROW_CHICKEN3,
> MTL_DISABLE_FIX_FOR_EOT_FLUSH);
>
> + /* Wa_14020495402 */
> + wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN2,
> XELPG_DISABLE_TDL_SVHS_GATING);
> + }
> +
> 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))
> /*
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/mtl: Add Wa_14020495402
On Mon, Mar 18, 2024 at 12:35:58PM -0700, Radhakrishna Sripada wrote: > Disable clockgating for TDL SVHS fub. > > Bspec: 46045 > Cc: Matt Roper > Signed-off-by: Radhakrishna Sripada > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 50962cfd1353..860765cd2ad2 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -1215,6 +1215,7 @@ > #define GEN12_DISABLE_EARLY_READ REG_BIT(14) > #define GEN12_ENABLE_LARGE_GRF_MODEREG_BIT(12) > #define GEN12_PUSH_CONST_DEREF_HOLD_DISREG_BIT(8) > +#define MTL_DISABLE_TDL_SVHS_GATINGREG_BIT(1) > #define GEN12_DISABLE_DOP_GATING REG_BIT(0) > > #define RT_CTRL MCR_REG(0xe530) > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index b079cbbc1897..8a82aa93a08d 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -828,6 +828,9 @@ static void xelpg_ctx_workarounds_init(struct > intel_engine_cs *engine, > > /* Wa_14019877138 */ > wa_mcr_masked_en(wal, XEHP_PSS_CHICKEN, FD_END_COLLECT); > + > + /* Wa_14020495402 */ > + wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN2, MTL_DISABLE_TDL_SVHS_GATING); I don't see this register in the LRC. I think this might be in the wrong function? Also, this patch should use an xelpg prefix, not MTL, since this is a workaround for the graphics IP (on any platform it shows up in), not for MTL. Matt > } > > static void fakewa_disable_nestedbb_mode(struct intel_engine_cs *engine, > -- > 2.34.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
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:
> > On Thu, Mar 07, 2024 at 06:01:29PM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > An existing workaround has been extended in both platforms affected
> > > and implementation complexity.
> > >
> > > Signed-off-by: John Harrison
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 3 ++-
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 3 ++-
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++-
> > > 3 files changed, 15 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> > > b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> > > index bebf28e3c4794..3e7060e859794 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> > > @@ -105,7 +105,8 @@ enum {
> > >* Workaround keys:
> > >*/
> > > enum {
> > > - GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE =
> > > 0x9001,
> > > + GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE =
> > > 0x9001, /* Wa_14019159160 */
> > > + GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE =
> > > 0x9006, /* Wa_14019159160 */
> > > };
> > > #endif /* _ABI_GUC_KLVS_ABI_H */
> > > 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?
12.74 / Xe_LPG+ is used in some ARL, which is being officially supported
by i915.
Matt
>
> John.
>
> > now.
> >
> >
> > Matt
> >
> > > + IS_DG2(gt->i915))
> > > flags |= GUC_WA_RCS_CCS_SWITCHOUT;
> > > /*
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > > index 5c9908b56616e..00fe3c21a9b1c 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > > @@ -815,23 +815,23 @@ guc_capture_prep_lists(struct intel_guc *guc)
> > > return PAGE_ALIGN(total_size);
> > > }
> > > -/* Wa_14019159160 */
> > > -static u32 guc_waklv_ra_mode(struct intel_guc *guc, u32 offset, u32
> > > remain)
> > > +static void guc_waklv_enable_simple(struct intel_guc *guc, u32 *offset,
> > > u32 *remain, u32 klv_id)
> > > {
> > > u32 size;
> > > u32 klv_entry[] = {
> > > /* 16:16 key/length */
> > > - FIELD_PREP(GUC_KLV_0_KEY,
> > > GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE) |
> > > + FIELD_PREP(GUC_KLV_0_KEY, klv_id) |
> > > FIELD_PREP(GUC_KLV_0_LEN, 0),
> > > /* 0 dwords data */
> > > };
> > > size = sizeof(klv_entry);
> > > - GEM_BUG_ON(remain < size);
> > > + GEM_BUG_ON(*remain < size);
> > > - iosys_map_memcpy_to(>ads_map, offset, klv_entry, size);
> > > + iosys_map_memcpy_to(>ads_map, *offset, klv_entry, size);
> > > - return size;
> > > + *offset += size;
> > > + *remain -= size;
> > > }
> > > static void guc_waklv_init(struct intel_guc *guc)
> > > @@ -850,10 +850,11 @@ static void guc_waklv_init(struct intel_guc *guc)
> > > remain = guc_ads_waklv_size(guc);
> > > /* Wa_14019159160 */
> > > - if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))) {
> > > - size = guc_waklv_ra_mode(guc, offset, remain);
> > > - offset += size;
> > > - remain -= size;
> > > + if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
> > > IS_DG2(gt->i915)) {
> > > + guc_waklv_enable_simple(guc, , ,
> > > + GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE);
> > > + guc_waklv_enable_simple(guc, , ,
> > > +
> > > GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE);
> > > }
> > > size = guc_ads_waklv_size(guc) - remain;
> > > --
> > > 2.43.0
> > >
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 6/6] drm/i915: Remove special handling for !RCS_MASK()
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; But either way, Reviewed-by: Matt Roper > > /* 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_SWITCHOUT BIT(17) > #define GUC_WA_POLLCS BIT(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_FEATURE 2 > -- > 2.43.0 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH v2 3/6] drm/i915: Stop inheriting IP_VER(12, 50)
On Tue, Mar 12, 2024 at 04:51:42PM -0700, Lucas De Marchi wrote:
> 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
Reviewed-by: Matt Roper
> ---
> 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
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 2/6] drm/i915: Remove XEHP_FWRANGES()
On Tue, Mar 12, 2024 at 04:51:41PM -0700, Lucas De Marchi wrote:
> 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
Reviewed-by: Matt Roper
> ---
> 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
Re: [PATCH] drm/i915: remove platform checks in platform-specific handlers
On Wed, Mar 13, 2024 at 07:27:36PM +0300, Nikita Kiryushin wrote: > > Remove IS_KABYLAKE and IS_SKYLAKE in special handlers for > skylake and kabylake: the checks are done at hook initialization and are > always true in corresponding handlers. > > Signed-off-by: Nikita Kiryushin Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +++--- > drivers/gpu/drm/i915/intel_clock_gating.c | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 3eacbc50caf8..8eff6be9d74c 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -601,7 +601,7 @@ static void kbl_ctx_workarounds_init(struct > intel_engine_cs *engine, > gen9_ctx_workarounds_init(engine, wal); > /* WaToEnableHwFixForPushConstHWBug:kbl */ > - if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER)) > + if (IS_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER)) > wa_masked_en(wal, COMMON_SLICE_CHICKEN2, >GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION); > @@ -1169,7 +1169,7 @@ skl_gt_workarounds_init(struct intel_gt *gt, struct > i915_wa_list *wal) > GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE); > /* WaInPlaceDecompressionHang:skl */ > - if (IS_SKYLAKE(gt->i915) && IS_GRAPHICS_STEP(gt->i915, STEP_A0, > STEP_H0)) > + if (IS_GRAPHICS_STEP(gt->i915, STEP_A0, STEP_H0)) > wa_write_or(wal, > GEN9_GAMT_ECO_REG_RW_IA, > GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS); > @@ -1181,7 +1181,7 @@ kbl_gt_workarounds_init(struct intel_gt *gt, struct > i915_wa_list *wal) > gen9_gt_workarounds_init(gt, wal); > /* WaDisableDynamicCreditSharing:kbl */ > - if (IS_KABYLAKE(gt->i915) && IS_GRAPHICS_STEP(gt->i915, 0, STEP_C0)) > + if (IS_GRAPHICS_STEP(gt->i915, 0, STEP_C0)) > wa_write_or(wal, > GAMT_CHKN_BIT_REG, > GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING); > diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c > b/drivers/gpu/drm/i915/intel_clock_gating.c > index 9c21ce69bd98..977251bcbf42 100644 > --- a/drivers/gpu/drm/i915/intel_clock_gating.c > +++ b/drivers/gpu/drm/i915/intel_clock_gating.c > @@ -413,12 +413,12 @@ static void kbl_init_clock_gating(struct > drm_i915_private *i915) > intel_uncore_rmw(>uncore, FBC_LLC_READ_CTRL, 0, > FBC_LLC_FULLY_OPEN); > /* WaDisableSDEUnitClockGating:kbl */ > - if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, 0, STEP_C0)) > + if (IS_GRAPHICS_STEP(i915, 0, STEP_C0)) > intel_uncore_rmw(>uncore, GEN8_UCGCTL6, >0, GEN8_SDEUNIT_CLOCK_GATE_DISABLE); > /* WaDisableGamClockGating:kbl */ > - if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, 0, STEP_C0)) > + if (IS_GRAPHICS_STEP(i915, 0, STEP_C0)) > intel_uncore_rmw(>uncore, GEN6_UCGCTL1, >0, GEN6_GAMUNIT_CLOCK_GATE_DISABLE); > -- 2.34.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv
On Wed, Mar 06, 2024 at 11:36:40AM -0800, Lucas De Marchi wrote:
> PCI IDs for XEHPSDV were never added and platform always marked with
> force_probe. Drop what's not used and rename some places to either be
> xehp or dg2, depending on the platform/IP checks.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
>
> Potential problem here that needs a deeper look, the changes in
> __gen12_fw_ranges. Some ranges had comments saying they were XEHPSDV so
> I removed them, but it needs to be double checked with spec and CI
> results.
>
...
> 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.
> 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.
Matt
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/5] drm/i915: Drop WA 16015675438
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
Matt
> ---
> 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
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v5 2/4] drm/i915/gt: Refactor uabi engine class/instance list creation
On Fri, Mar 08, 2024 at 09:22:17PM +0100, Andi Shyti wrote:
> For the upcoming changes we need a cleaner way to build the list
> of uabi engines.
>
> Suggested-by: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> Cc: # v6.2+
I don't really see why we need patches 2 & 3 in this series. If we want
to restrict the platform to a single CCS engine for now (and give that
single engine access to all of the cslices), it would be much simpler to
only create a single intel_engine_cs which which would then cause both
i915 and userspace to only consider a single engine, even if more than
one is physically present. That could be done with a simple adjustment
to engine_mask_apply_compute_fuses() to mask off extra bits from the
engine mask such that only a single CCS can get returned rather than the
mask of all CCSs that are present.
Managing all of the engines in the KMD but only exposing one (some) of
them to userspace might be something we need if you want to add extra
functionality down to road to "hotplug" extra engines, or to allow
userspace to explicitly request multi-CCS mode. But none of that seems
necessary for this series, especially for something you're backporting
to stable kernels.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 833987015b8b..11cc06c0c785 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -203,7 +203,7 @@ static void engine_rename(struct intel_engine_cs *engine,
> const char *name, u16
>
> void intel_engines_driver_register(struct drm_i915_private *i915)
> {
> - u16 name_instance, other_instance = 0;
> + u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 2] = { };
> struct legacy_ring ring = {};
> struct list_head *it, *next;
> struct rb_node **p, *prev;
> @@ -214,6 +214,8 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> prev = NULL;
> p = >uabi_engines.rb_node;
> list_for_each_safe(it, next, ) {
> + u16 uabi_class;
> +
> struct intel_engine_cs *engine =
> container_of(it, typeof(*engine), uabi_list);
>
> @@ -222,15 +224,14 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
>
> GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
> engine->uabi_class = uabi_classes[engine->class];
> - if (engine->uabi_class == I915_NO_UABI_CLASS) {
> - name_instance = other_instance++;
> - } else {
> - GEM_BUG_ON(engine->uabi_class >=
> -ARRAY_SIZE(i915->engine_uabi_class_count));
> - name_instance =
> -
> i915->engine_uabi_class_count[engine->uabi_class]++;
> - }
> - engine->uabi_instance = name_instance;
> +
> + if (engine->uabi_class == I915_NO_UABI_CLASS)
> + uabi_class = I915_LAST_UABI_ENGINE_CLASS + 1;
> + else
> + uabi_class = engine->uabi_class;
> +
> + GEM_BUG_ON(uabi_class >= ARRAY_SIZE(class_instance));
> + engine->uabi_instance = class_instance[uabi_class]++;
>
> /*
>* Replace the internal name with the final user and log facing
> @@ -238,11 +239,15 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
>*/
> engine_rename(engine,
> intel_engine_class_repr(engine->class),
> - name_instance);
> + engine->uabi_instance);
>
> - if (engine->uabi_class == I915_NO_UABI_CLASS)
> + if (uabi_class > I915_LAST_UABI_ENGINE_CLASS)
> continue;
>
> + GEM_BUG_ON(uabi_class >=
> +ARRAY_SIZE(i915->engine_uabi_class_count));
> + i915->engine_uabi_class_count[uabi_class]++;
> +
> rb_link_node(>uabi_node, prev, p);
> rb_insert_color(>uabi_node, >uabi_engines);
>
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v5 1/4] drm/i915/gt: Disable HW load balancing for CCS
On Fri, Mar 08, 2024 at 09:22:16PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 23 +++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
Nitpick: we usually order register bits in descending order. Aside from
that,
Reviewed-by: Matt Roper
although I still hope our architects will push through a formal
documentation update for this.
Matt
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 25413809b9dc..4865eb5ca9c9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -51,7 +51,8 @@
> * registers belonging to BCS, VCS or VECS should be implemented in
> * xcs_engine_wa_init(). Workarounds for registers not belonging to a
> specific
> * engine's MMIO range but that are part of of the common RCS/CCS reset
> domain
> - * should be implemented in general_render_compute_wa_init().
> + * should be implemented in general_render_compute_wa_init(). The settings
> + * about the CCS load balancing should be added in ccs_engine_wa_mode().
> *
> * - GT workarounds: the list of these WAs is applied whenever these
> registers
> * revert to their default values: on GPU reset, suspend/resume [1]_, etc.
> @@ -2854,6 +2855,22 @@ add_render_compute_tuning_settings(struct intel_gt *gt,
> wa_write_clr(wal, GEN8_GARBCNTL, GEN12_BUS_HASH_CTL_BIT_EXC);
> }
>
> +static void ccs_engine_wa_mode(struct intel_engine_cs *engine, struct
> i915_wa_list *wal)
> +{
> + struct intel_gt *gt = engine->gt;
> +
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + /*
> + * Wa_14019159160: This workaround, along with others, leads to
> + * significant challenges in utilizing load balancing among the
> + * CCS slices. Consequently, an architectural decision has been
> + * made to completely disable automatic CCS load balancing.
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> +}
> +
> /*
> * The workarounds in this function apply to shared registers in
> * the general render reset domain that aren't tied to a
> @@ -3004,8 +3021,10 @@ engine_init_workarounds(struct intel_engine_cs
> *engine, struct i915_wa_list *wal
>* to a single RCS/CCS engine's workaround list since
>* they're reset as part of the general render domain reset.
>*/
> - if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE)
> + if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE) {
> general_render_compute_wa_init(engine, wal);
> + ccs_engine_wa_mode(engine, wal);
> + }
>
> if (engine->class == COMPUTE_CLASS)
> ccs_engine_wa_init(engine, wal);
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 5/8] drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state
On Tue, Mar 12, 2024 at 01:45:32PM -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2024-03-12 13:36:36-03:00)
> >Xe2LPD always selects the CDCLK PLL as source for the MDCLK. Because of
> >that, the ratio between MDCLK and CDCLK is not be constant anymore. As
> >such, make sure to have the current ratio available in intel_dbuf_state
> >so that it can be used during dbuf programming.
> >
> >Note that we write-lock the global state instead of serializing to a
> >hardware commit because a change in the ratio should be rather handled
> >in the CDCLK change sequence, which will need to take care of updating
> >the necessary registers in that case. We will implement that in upcoming
> >changes.
> >
> >That said, changes in the MBus joining state should be handled by the
> >DBUF/MBUS logic, just like it is already done, but the logic will need
> >to know the ratio to properly update the registers.
> >
> >v2:
> > - Make first sentence of commit message more intelligible. (Matt)
> >
> >Reviewed-by: Matt Roper
> >Signed-off-by: Gustavo Sousa
> >---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 20
> > drivers/gpu/drm/i915/display/intel_cdclk.h | 2 ++
> > drivers/gpu/drm/i915/display/skl_watermark.c | 18 +-
> > drivers/gpu/drm/i915/display/skl_watermark.h | 3 +++
> > 4 files changed, 42 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >index 354a9dba6440..4e143082dca1 100644
> >--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >@@ -39,6 +39,7 @@
> > #include "intel_pcode.h"
> > #include "intel_psr.h"
> > #include "intel_vdsc.h"
> >+#include "skl_watermark.h"
> > #include "vlv_sideband.h"
> >
> > /**
> >@@ -1889,6 +1890,16 @@ static u32 xe2lpd_mdclk_source_sel(struct
> >drm_i915_private *i915)
> > return MDCLK_SOURCE_SEL_CD2XCLK;
> > }
> >
> >+u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> >+ const struct intel_cdclk_config *cdclk_config)
> >+{
> >+if (mdclk_source_is_cdclk_pll(i915))
> >+return DIV_ROUND_UP(cdclk_config->vco, cdclk_config->cdclk);
> >+
> >+/* Otherwise, source for MDCLK is CD2XCLK. */
> >+return 2;
>
> Matt, this function was updated as a result of updating the second patch
> (now "drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()").
>
> Since the update here is functionally equivalent to v1, I took the
> liberty of carrying your r-b over. Please let me know if you have
> concerns here.
No concerns; you can keep my r-b.
Matt
>
> --
> Gustavo Sousa
>
> >+}
> >+
> > static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> > *i915,
> > const struct
> > intel_cdclk_config *old_cdclk_config,
> > const struct
> > intel_cdclk_config *new_cdclk_config,
> >@@ -3278,6 +3289,15 @@ int intel_modeset_calc_cdclk(struct
> >intel_atomic_state *state)
> > "Modeset required for cdclk change\n");
> > }
> >
> >+if (intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual) !=
> >+intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual)) {
> >+u8 ratio = intel_mdclk_cdclk_ratio(dev_priv,
> >_cdclk_state->actual);
> >+
> >+ret = intel_dbuf_state_set_mdclk_cdclk_ratio(state, ratio);
> >+if (ret)
> >+return ret;
> >+}
> >+
> > drm_dbg_kms(_priv->drm,
> > "New cdclk calculated to be logical %u kHz, actual %u
> > kHz\n",
> > new_cdclk_state->logical.cdclk,
> >diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> >b/drivers/gpu/drm/i915/display/intel_cdclk.h
> >index fa301495e7f1..8e6e302bd599 100644
> >--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> >+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> >@@ -62,6 +62,8 @@ void intel_update_cdclk(struct drm_i915_private *dev_priv);
> > u32 intel_read_rawclk(struct drm_i915_private *dev_priv);
> > bool intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
> >const stru
Re: [PATCH v2 2/8] drm/i915/cdclk: Add and use mdclk_source_is_cdclk_pll()
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
and beyond should always use the CDCLK PLL as the MDCLK source (rather
than the CD2X which would still be the register field's default value if
we didn't touch it).
Reviewed-by: Matt Roper
> Cc: Matt Roper
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 15 ++-
> drivers/gpu/drm/i915/i915_reg.h| 4 +++-
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index be268c6abe21..ad0f03e51e4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1876,6 +1876,19 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
> return vco == ~0;
> }
>
> +static bool mdclk_source_is_cdclk_pll(struct drm_i915_private *i915)
> +{
> + return DISPLAY_VER(i915) >= 20;
> +}
> +
> +static u32 xe2lpd_mdclk_source_sel(struct drm_i915_private *i915)
> +{
> + if (mdclk_source_is_cdclk_pll(i915))
> + return MDCLK_SOURCE_SEL_CDCLK_PLL;
> +
> + return MDCLK_SOURCE_SEL_CD2XCLK;
> +}
> +
> static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> const struct
> intel_cdclk_config *old_cdclk_config,
> const struct
> intel_cdclk_config *new_cdclk_config,
> @@ -1980,7 +1993,7 @@ static u32 bxt_cdclk_ctl(struct drm_i915_private *i915,
> val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
>
> if (DISPLAY_VER(i915) >= 20)
> - val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
> + val |= xe2lpd_mdclk_source_sel(i915);
> else
> val |= skl_cdclk_decimal(cdclk);
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8823531b8770..d6193c858a74 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5891,7 +5891,9 @@ enum skl_power_gate {
> #define CDCLK_FREQ_540 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 1)
> #define CDCLK_FREQ_337_308 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 2)
> #define CDCLK_FREQ_675_617 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 3)
> -#define MDCLK_SOURCE_SEL_CDCLK_PLL REG_BIT(25)
> +#define MDCLK_SOURCE_SEL_MASK REG_GENMASK(25, 25)
> +#define MDCLK_SOURCE_SEL_CD2XCLKREG_FIELD_PREP(MDCLK_SOURCE_SEL_MASK, 0)
> +#define MDCLK_SOURCE_SEL_CDCLK_PLL REG_FIELD_PREP(MDCLK_SOURCE_SEL_MASK, 1)
> #define BXT_CDCLK_CD2X_DIV_SEL_MASK REG_GENMASK(23, 22)
> #define BXT_CDCLK_CD2X_DIV_SEL_1
> REG_FIELD_PREP(BXT_CDCLK_CD2X_DIV_SEL_MASK, 0)
> #define BXT_CDCLK_CD2X_DIV_SEL_1_5
> REG_FIELD_PREP(BXT_CDCLK_CD2X_DIV_SEL_MASK, 1)
> --
> 2.44.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/guc: Update w/a 14019159160
On Thu, Mar 07, 2024 at 06:01:29PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> An existing workaround has been extended in both platforms affected
> and implementation complexity.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 3 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 3 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++-
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> index bebf28e3c4794..3e7060e859794 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
> @@ -105,7 +105,8 @@ enum {
> * Workaround keys:
> */
> enum {
> - GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE =
> 0x9001,
> + GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE =
> 0x9001, /* Wa_14019159160 */
> + GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE =
> 0x9006, /* Wa_14019159160 */
> };
>
> #endif /* _ABI_GUC_KLVS_ABI_H */
> 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)
now.
Matt
> + IS_DG2(gt->i915))
> flags |= GUC_WA_RCS_CCS_SWITCHOUT;
>
> /*
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 5c9908b56616e..00fe3c21a9b1c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -815,23 +815,23 @@ guc_capture_prep_lists(struct intel_guc *guc)
> return PAGE_ALIGN(total_size);
> }
>
> -/* Wa_14019159160 */
> -static u32 guc_waklv_ra_mode(struct intel_guc *guc, u32 offset, u32 remain)
> +static void guc_waklv_enable_simple(struct intel_guc *guc, u32 *offset, u32
> *remain, u32 klv_id)
> {
> u32 size;
> u32 klv_entry[] = {
> /* 16:16 key/length */
> - FIELD_PREP(GUC_KLV_0_KEY,
> GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE) |
> + FIELD_PREP(GUC_KLV_0_KEY, klv_id) |
> FIELD_PREP(GUC_KLV_0_LEN, 0),
> /* 0 dwords data */
> };
>
> size = sizeof(klv_entry);
> - GEM_BUG_ON(remain < size);
> + GEM_BUG_ON(*remain < size);
>
> - iosys_map_memcpy_to(>ads_map, offset, klv_entry, size);
> + iosys_map_memcpy_to(>ads_map, *offset, klv_entry, size);
>
> - return size;
> + *offset += size;
> + *remain -= size;
> }
>
> static void guc_waklv_init(struct intel_guc *guc)
> @@ -850,10 +850,11 @@ static void guc_waklv_init(struct intel_guc *guc)
> remain = guc_ads_waklv_size(guc);
>
> /* Wa_14019159160 */
> - if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))) {
> - size = guc_waklv_ra_mode(guc, offset, remain);
> - offset += size;
> - remain -= size;
> + if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
> IS_DG2(gt->i915)) {
> + guc_waklv_enable_simple(guc, , ,
> + GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE);
> + guc_waklv_enable_simple(guc, , ,
> +
> GUC_WORKAROUND_KLV_AVOID_GFX_CLEAR_WHILE_ACTIVE);
> }
>
> size = guc_ads_waklv_size(guc) - remain;
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v4 3/3] drm/i915/gt: Enable only one CCS for compute workload
On Wed, Mar 06, 2024 at 02:22:47AM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
>
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Requires: 97aba5e46038 ("drm/i915/gt: Refactor uabi engine class/instance
> list creation")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++
> drivers/gpu/drm/i915/gt/intel_gt.c | 23 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> 3 files changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 11cc06c0c785..9ef1c4ce252d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -208,6 +208,7 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> struct list_head *it, *next;
> struct rb_node **p, *prev;
> LIST_HEAD(engines);
> + u16 uabi_ccs = 0;
>
> sort_engines(i915, );
>
> @@ -244,6 +245,16 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> if (uabi_class > I915_LAST_UABI_ENGINE_CLASS)
> continue;
>
> + /*
> + * The load is balanced among all the available compute
> + * slices. Expose only the first instance of the compute
> + * engine.
> + */
> + if (IS_DG2(i915) &&
> + uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> + uabi_ccs++)
> + continue;
> +
> GEM_BUG_ON(uabi_class >=
> ARRAY_SIZE(i915->engine_uabi_class_count));
> i915->engine_uabi_class_count[uabi_class]++;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index a425db5ed3a2..0aac97439552 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -168,6 +168,26 @@ static void init_unused_rings(struct intel_gt *gt)
> }
> }
>
> +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +{
> + u32 mode;
> + int cslice;
> +
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + /* Set '0' as a default CCS id to all the cslices */
> + mode = 0;
> +
> + for (cslice = 0; cslice < hweight32(CCS_MASK(gt)); cslice++)
> + /* Write 0x7 if no CCS context dispatches to this cslice */
> + if (!(CCS_MASK(gt) & BIT(cslice)))
> + mode |= XEHP_CCS_MODE_CSLICE(cslice,
> + XEHP_CCS_MODE_CSLICE_MASK);
> +
> + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
This is still going to hook all available cslices up to hardware engine
ccs0. But what you actually want is to hook them all up to what
userspace sees as CCS0 (i.e., the first CCS engine that wasn't fused
off). Hardware's engine numbering and userspace's numbering aren't the
same.
Also, if you have a part that only has hardware ccs1/cslice1 for
example, you're not going to set cslices 2 & 3 to 0x7 properly.
So probably what you want is something like this (untested):
static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
{
u32 mode = 0;
int first_ccs = __ffs(CCS_MASK(gt));
/*
* Re-assign every present cslice to the first available CCS
* engine; mark unavailable cslices as unused.
*/
for (int cslice = 0; cslice < 4; cslice++) {
if (CCS_MASK(gt) & BIT(cslice))
mode |= XEHP_CCS_MODE_CSLICE(cslice, first_ccs);
else
mode |= XEHP_CCS_MODE_CSLICE(cslice,
XEHP_CCS_MODE_CSLICE_MASK);
}
intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
}
> +}
> +
> int intel_gt_init_hw(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> @@ -195,6 +215,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
>
> intel_gt_init_swizzling(gt);
>
> + /* Configure CCS mode */
> + intel_gt_apply_ccs_mode(gt);
This is only setting this once during init. The value gets lost on
every RCS/CCS reset, so we need to make sure it ge
Re: [PATCH v4 1/3] drm/i915/gt: Disable HW load balancing for CCS
On Wed, Mar 06, 2024 at 02:22:45AM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..a2e78cf0b5f5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2945,6 +2945,11 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
>
> /* Wa_18028616096 */
> wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW,
> UGM_FRAGMENT_THRESHOLD_TO_3);
> +
> + /*
> + * Wa_14019159160: disable the automatic CCS load balancing
I'm still a bit concerned that this doesn't really match what this
specific workaround is asking us to do. There seems to be an agreement
on various internal email threads that we need to disable load
balancing, but there's no single specific workaround that officially
documents that decision.
This specific workaround asks us to do a bunch of different things, and
the third item it asks for is to disable load balancing in very specific
cases (i.e., while the RCS is active at the same time as one or more CCS
engines). Taking this workaround in isolation, it would be valid to
keep load balancing active if you were just using the CCS engines and
leaving the RCS idle, or if balancing was turned on/off by the GuC
scheduler according to engine use at the moment, as the documented
workaround seems to assume will be the case.
So in general I think we do need to disable load balancing based on
other offline discussion, but blaming that entire change on
Wa_14019159160 seems a bit questionable since it's not really what this
specific workaround is asking us to do and someone may come back and try
to "correct" the implementation of this workaround in the future without
realizing there are other factors too. It would be great if we could
get hardware teams to properly document this expectation somewhere
(either in a separate dedicated workaround, or in the MMIO tuning guide)
so that we'll have a more direct and authoritative source for such a
large behavioral change.
Matt
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE,
> XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> }
>
> if (IS_DG2_G11(i915)) {
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v3 2/4] drm/i915/gt: Do not exposed fused off engines.
On Fri, Mar 01, 2024 at 12:28:57AM +0100, Andi Shyti wrote:
> Some of the CCS engines are disabled. They should not be listed
> in the uabi_engine list, that is the list of engines that the
> user can see.
Fused off engines already aren't visible to userspace (or to the kernel
for that matter). For CCS engines engine_mask_apply_compute_fuses()
removes the fused off engines from the runtime engine mask; other engine
types are handled in similar functions. Any engine that doesn't appear
in the filtered down engine_mask won't even have a 'struct
intel_engine_cs' allocated for it.
Matt
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Requires: 4e4f77d74878 ("drm/i915/gt: Refactor uabi engine class/instance
> list creation")
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index cf8f24ad88f6..ec5bcd1c1ec4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -244,6 +244,18 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> if (uabi_class > I915_LAST_UABI_ENGINE_CLASS)
> continue;
>
> + /*
> + * If the CCS engine is fused off, the corresponding bit
> + * in the engine mask is disabled. Do not expose it
> + * to the user.
> + *
> + * By default at least one engine is enabled (check
> + * the engine_mask_apply_compute_fuses() function.
> + */
> + if (!(engine->gt->info.engine_mask &
> + BIT(_CCS(engine->uabi_instance
> + continue;
> +
> GEM_BUG_ON(uabi_class >=
> ARRAY_SIZE(i915->engine_uabi_class_count));
> i915->engine_uabi_class_count[uabi_class]++;
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 5/8] drm/i915: Add mdclk_cdclk_ratio to intel_dbuf_state
On Mon, Mar 04, 2024 at 03:30:24PM -0300, Gustavo Sousa wrote:
> CDCLK programming Xe2LPD always selects the CDCLK PLL as source for the
I think something got a bit muddled while rewriting this sentence.
Maybe the first two words were supposed to be dropped?
Otherwise,
Reviewed-by: Matt Roper
> MDCLK. Because of that, the ratio between MDCLK and CDCLK is not be
> constant anymore. As such, make sure to have the current ratio available
> in intel_dbuf_state so that it can be used during dbuf programming.
>
> Note that we write-lock the global state instead of serializing to a
> hardware commit because a change in the ratio should be rather handled
> in the CDCLK change sequence, which will need to take care of updating
> the necessary registers in that case. We will implement that in upcoming
> changes.
>
> That said, changes in the MBus joining state should be handled by the
> DBUF/MBUS logic, just like it is already done, but the logic will need
> to know the ratio to properly update the registers.
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 26
> drivers/gpu/drm/i915/display/intel_cdclk.h | 2 ++
> drivers/gpu/drm/i915/display/skl_watermark.c | 18 +-
> drivers/gpu/drm/i915/display/skl_watermark.h | 3 +++
> 4 files changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index cdf3ae766f9e..04a6e9806254 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -39,6 +39,7 @@
> #include "intel_pcode.h"
> #include "intel_psr.h"
> #include "intel_vdsc.h"
> +#include "skl_watermark.h"
> #include "vlv_sideband.h"
>
> /**
> @@ -1891,6 +1892,22 @@ static u32 xe2lpd_mdclk_source_sel(struct
> drm_i915_private *i915)
> return MDCLK_SOURCE_SEL_CD2XCLK;
> }
>
> +u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> +const struct intel_cdclk_config *cdclk_config)
> +{
> + u32 source_sel = xe2lpd_mdclk_source_sel(i915);
> +
> + switch (source_sel) {
> + case MDCLK_SOURCE_SEL_CD2XCLK:
> + return 2;
> + case MDCLK_SOURCE_SEL_CDCLK_PLL:
> + return DIV_ROUND_UP(cdclk_config->vco, cdclk_config->cdclk);
> + default:
> + MISSING_CASE(source_sel);
> + return 2;
> + }
> +}
> +
> static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> const struct
> intel_cdclk_config *old_cdclk_config,
> const struct
> intel_cdclk_config *new_cdclk_config,
> @@ -3281,6 +3298,15 @@ int intel_modeset_calc_cdclk(struct intel_atomic_state
> *state)
> "Modeset required for cdclk change\n");
> }
>
> + if (intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual) !=
> + intel_mdclk_cdclk_ratio(dev_priv, _cdclk_state->actual)) {
> + u8 ratio = intel_mdclk_cdclk_ratio(dev_priv,
> _cdclk_state->actual);
> +
> + ret = intel_dbuf_state_set_mdclk_cdclk_ratio(state, ratio);
> + if (ret)
> + return ret;
> + }
> +
> drm_dbg_kms(_priv->drm,
> "New cdclk calculated to be logical %u kHz, actual %u
> kHz\n",
> new_cdclk_state->logical.cdclk,
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index fa301495e7f1..8e6e302bd599 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -62,6 +62,8 @@ void intel_update_cdclk(struct drm_i915_private *dev_priv);
> u32 intel_read_rawclk(struct drm_i915_private *dev_priv);
> bool intel_cdclk_clock_changed(const struct intel_cdclk_config *a,
> const struct intel_cdclk_config *b);
> +u8 intel_mdclk_cdclk_ratio(struct drm_i915_private *i915,
> +const struct intel_cdclk_config *cdclk_config);
> void intel_set_cdclk_pre_plane_update(struct intel_atomic_state *state);
> void intel_set_cdclk_post_plane_update(struct intel_atomic_state *state);
> void intel_cdclk_dump_config(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index d9e49cd60d3a..4410e21888ad 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/driv
Re: [PATCH 4/8] drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update()
On Mon, Mar 04, 2024 at 03:30:23PM -0300, Gustavo Sousa wrote:
> As of Xe2LPD, it is now possible to select the source of the MDCLK
> as either the CD2XCLK or the CDCLK PLL.
>
> Previous display IPs were hardcoded to use the CD2XCLK. For those, the
> ratio between MDCLK and CDCLK remained constant, namely 2. For Xe2LPD,
> when we select the CDCLK PLL as the source, the ratio will vary
> according to the squashing configuration (since the cd2x divisor is
> fixed for all supported configurations).
>
> To help the transition to supporting changes in the ratio, extract the
> function intel_dbuf_mdclk_cdclk_ratio_update() from the existing logic
> and call it using 2 as hardcoded ratio. Upcoming changes will use that
> function for updates in the ratio due to CDCLK changes.
>
> Bspec: 50057, 69445, 49213, 68868
> Signed-off-by: Gustavo Sousa
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 30 +---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index c6b9be80d83c..d9e49cd60d3a 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -3530,6 +3530,21 @@ int intel_dbuf_init(struct drm_i915_private *i915)
> return 0;
> }
>
> +static void intel_dbuf_mdclk_cdclk_ratio_update(struct drm_i915_private
> *i915,
> + u8 ratio,
> + bool joined_mbus)
> +{
> + enum dbuf_slice slice;
> +
> + if (joined_mbus)
> + ratio *= 2;
> +
> + for_each_dbuf_slice(i915, slice)
> + intel_de_rmw(i915, DBUF_CTL_S(slice),
> + DBUF_MIN_TRACKER_STATE_SERVICE_MASK,
> + DBUF_MIN_TRACKER_STATE_SERVICE(ratio - 1));
> +}
> +
> /*
> * Configure MBUS_CTL and all DBUF_CTL_S of each slice to join_mbus state
> before
> * update the request state of all DBUS slices.
> @@ -3537,8 +3552,7 @@ int intel_dbuf_init(struct drm_i915_private *i915)
> static void update_mbus_pre_enable(struct intel_atomic_state *state)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> - u32 mbus_ctl, dbuf_min_tracker_val;
> - enum dbuf_slice slice;
> + u32 mbus_ctl;
> const struct intel_dbuf_state *dbuf_state =
> intel_atomic_get_new_dbuf_state(state);
>
> @@ -3549,24 +3563,18 @@ static void update_mbus_pre_enable(struct
> intel_atomic_state *state)
>* TODO: Implement vblank synchronized MBUS joining changes.
>* Must be properly coordinated with dbuf reprogramming.
>*/
> - if (dbuf_state->joined_mbus) {
> + if (dbuf_state->joined_mbus)
> mbus_ctl = MBUS_HASHING_MODE_1x4 | MBUS_JOIN |
> MBUS_JOIN_PIPE_SELECT_NONE;
> - dbuf_min_tracker_val = DBUF_MIN_TRACKER_STATE_SERVICE(3);
> - } else {
> + else
> mbus_ctl = MBUS_HASHING_MODE_2x2 |
> MBUS_JOIN_PIPE_SELECT_NONE;
> - dbuf_min_tracker_val = DBUF_MIN_TRACKER_STATE_SERVICE(1);
> - }
>
> intel_de_rmw(i915, MBUS_CTL,
>MBUS_HASHING_MODE_MASK | MBUS_JOIN |
>MBUS_JOIN_PIPE_SELECT_MASK, mbus_ctl);
>
> - for_each_dbuf_slice(i915, slice)
> - intel_de_rmw(i915, DBUF_CTL_S(slice),
> - DBUF_MIN_TRACKER_STATE_SERVICE_MASK,
> - dbuf_min_tracker_val);
> + intel_dbuf_mdclk_cdclk_ratio_update(i915, 2, dbuf_state->joined_mbus);
> }
>
> void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
> --
> 2.44.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 3/8] drm/i915/cdclk: Only compute squash waveform when necessary
On Mon, Mar 04, 2024 at 03:30:22PM -0300, Gustavo Sousa wrote:
> It is no use computing the squash waveform if we are not going to use
> it. Move the call to cdclk_squash_waveform() inside the block guarded by
> HAS_CDCLK_SQUASH(dev_priv).
>
> Signed-off-by: Gustavo Sousa
You could also move the 'u32 waveform' declaration from the top of the
function inside the block too to help prevent any future mistakes of
using it unitialized.
Either way,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index bf84bf27213f..cdf3ae766f9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2023,10 +2023,11 @@ static void _bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> } else
> bxt_cdclk_pll_update(dev_priv, vco);
>
> - waveform = cdclk_squash_waveform(dev_priv, cdclk);
> + if (HAS_CDCLK_SQUASH(dev_priv)) {
> + waveform = cdclk_squash_waveform(dev_priv, cdclk);
>
> - if (HAS_CDCLK_SQUASH(dev_priv))
> dg2_cdclk_squash_program(dev_priv, waveform);
> + }
>
> intel_de_write(dev_priv, CDCLK_CTL, bxt_cdclk_ctl(dev_priv,
> cdclk_config, pipe));
>
> --
> 2.44.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 2/8] drm/i915/cdclk: Add and use xe2lpd_mdclk_source_sel()
On Mon, Mar 04, 2024 at 03:30:21PM -0300, Gustavo Sousa wrote:
> There will be future changes that rely on the source of the MDCLK. Let's
> have xe2lpd_mdclk_source_sel() as the function responsible for reporting
> that information.
>
> Bspec: 69090
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 17 -
> drivers/gpu/drm/i915/i915_reg.h| 4 +++-
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 407bd541eb46..bf84bf27213f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1876,6 +1876,21 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
> return vco == ~0;
> }
>
> +static u32 xe2lpd_mdclk_source_sel(struct drm_i915_private *i915)
> +{
> + if (DISPLAY_VER(i915) >= 20)
> + return MDCLK_SOURCE_SEL_CDCLK_PLL;
> +
> + /*
> + * Earlier display IPs do not provide means of selecting the
> + * MDCLK source, but MDCLK_SOURCE_SEL_CD2XCLK is a nice default,
> + * since it reflects the source used for those and allows
> + * xe2lpd_mdclk_source_sel() to be used in logic that depends on
> + * it.
> + */
> + return MDCLK_SOURCE_SEL_CD2XCLK;
At the moment this function only gets called on Xe2 and beyond where the
register field exists; if that's going to change soon, then wouldn't it
be more natural to just use an early exit to highlight that there's
nothing we need to OR into the CDCLK_CTL for earlier platforms?
/* Not configurable for older platforms; they always use CD2XCLK */
if (DISPLAY_VER(i915) < 20)
return 0;
Functionally it's the same, but it feels more intuitive to me.
If we aren't expecting to call this from common codepaths that aren't
already protected by a display version check, then we could make this a
drm_WARN_ON() to assert that we haven't deviated from expected behavior.
Matt
> +}
> +
> static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> const struct
> intel_cdclk_config *old_cdclk_config,
> const struct
> intel_cdclk_config *new_cdclk_config,
> @@ -1980,7 +1995,7 @@ static u32 bxt_cdclk_ctl(struct drm_i915_private *i915,
> val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
>
> if (DISPLAY_VER(i915) >= 20)
> - val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
> + val |= xe2lpd_mdclk_source_sel(i915);
> else
> val |= skl_cdclk_decimal(cdclk);
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e00557e1a57f..eb953ed1f113 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5900,7 +5900,9 @@ enum skl_power_gate {
> #define CDCLK_FREQ_540 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 1)
> #define CDCLK_FREQ_337_308 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 2)
> #define CDCLK_FREQ_675_617 REG_FIELD_PREP(CDCLK_FREQ_SEL_MASK, 3)
> -#define MDCLK_SOURCE_SEL_CDCLK_PLL REG_BIT(25)
> +#define MDCLK_SOURCE_SEL_MASK REG_GENMASK(25, 25)
> +#define MDCLK_SOURCE_SEL_CD2XCLKREG_FIELD_PREP(MDCLK_SOURCE_SEL_MASK, 0)
> +#define MDCLK_SOURCE_SEL_CDCLK_PLL REG_FIELD_PREP(MDCLK_SOURCE_SEL_MASK, 1)
> #define BXT_CDCLK_CD2X_DIV_SEL_MASK REG_GENMASK(23, 22)
> #define BXT_CDCLK_CD2X_DIV_SEL_1
> REG_FIELD_PREP(BXT_CDCLK_CD2X_DIV_SEL_MASK, 0)
> #define BXT_CDCLK_CD2X_DIV_SEL_1_5
> REG_FIELD_PREP(BXT_CDCLK_CD2X_DIV_SEL_MASK, 1)
> --
> 2.44.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/8] drm/i915/cdclk: Rename lnl_cdclk_table to xe2lpd_cdclk_table
On Mon, Mar 04, 2024 at 03:30:20PM -0300, Gustavo Sousa wrote:
> The CDCLK table is tied to Xe2LPD display and not to the platform. Let's
> rename lnl_cdclk_table to xe2lpd_cdclk_table in order to reflect that.
>
> Signed-off-by: Gustavo Sousa
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 22473c55b899..407bd541eb46 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1417,7 +1417,7 @@ static const struct intel_cdclk_vals mtl_cdclk_table[]
> = {
> {}
> };
>
> -static const struct intel_cdclk_vals lnl_cdclk_table[] = {
> +static const struct intel_cdclk_vals xe2lpd_cdclk_table[] = {
> { .refclk = 38400, .cdclk = 153600, .ratio = 16, .waveform = 0x },
> { .refclk = 38400, .cdclk = 172800, .ratio = 16, .waveform = 0xad5a },
> { .refclk = 38400, .cdclk = 192000, .ratio = 16, .waveform = 0xb6b6 },
> @@ -3710,7 +3710,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> {
> if (DISPLAY_VER(dev_priv) >= 20) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> - dev_priv->display.cdclk.table = lnl_cdclk_table;
> + dev_priv->display.cdclk.table = xe2lpd_cdclk_table;
> } else if (DISPLAY_VER(dev_priv) >= 14) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = mtl_cdclk_table;
> --
> 2.44.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: ✓ Fi.CI.IGT: success for drm/i915/cdclk: Document CDCLK components (rev2)
On Thu, Feb 22, 2024 at 05:23:47AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/cdclk: Document CDCLK components (rev2) > URL : https://patchwork.freedesktop.org/series/130016/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_14311_full -> Patchwork_130016v2_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Applied to drm-intel-next. Thanks for the patch and review. Matt > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/index.html > > Participating hosts (8 -> 7) > -- > > Missing(1): shard-glk-0 > > Known issues > > > Here are the changes found in Patchwork_130016v2_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@api_intel_bb@object-reloc-keep-cache: > - shard-dg2: NOTRUN -> [SKIP][1] ([i915#8411]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-dg2-2/igt@api_intel...@object-reloc-keep-cache.html > > * igt@device_reset@unbind-cold-reset-rebind: > - shard-dg2: NOTRUN -> [SKIP][2] ([i915#7701]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-dg2-1/igt@device_re...@unbind-cold-reset-rebind.html > > * igt@drm_fdinfo@busy-idle@vecs0: > - shard-mtlp: NOTRUN -> [SKIP][3] ([i915#8414]) +7 other tests > skip >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@drm_fdinfo@busy-i...@vecs0.html > > * igt@drm_fdinfo@idle@rcs0: > - shard-rkl: [PASS][4] -> [FAIL][5] ([i915#7742]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html > > * igt@gem_bad_reloc@negative-reloc-bltcopy: > - shard-mtlp: NOTRUN -> [SKIP][6] ([i915#3281]) +7 other tests > skip >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@gem_bad_re...@negative-reloc-bltcopy.html > > * igt@gem_busy@semaphore: > - shard-dg2: NOTRUN -> [SKIP][7] ([i915#3936]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-dg2-1/igt@gem_b...@semaphore.html > > * igt@gem_ccs@block-multicopy-inplace: > - shard-mtlp: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#9323]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@gem_...@block-multicopy-inplace.html > > * igt@gem_ccs@ctrl-surf-copy-new-ctx: > - shard-tglu: NOTRUN -> [SKIP][9] ([i915#9323]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-tglu-6/igt@gem_...@ctrl-surf-copy-new-ctx.html > > * igt@gem_ccs@suspend-resume: > - shard-rkl: NOTRUN -> [SKIP][10] ([i915#9323]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-rkl-4/igt@gem_...@suspend-resume.html > - shard-mtlp: NOTRUN -> [SKIP][11] ([i915#9323]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@gem_...@suspend-resume.html > > * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-lmem0-lmem0: > - shard-dg2: NOTRUN -> [INCOMPLETE][12] ([i915#10137] / > [i915#7297]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-lmem0-lmem0.html > > * igt@gem_create@create-ext-cpu-access-big: > - shard-dg2: NOTRUN -> [ABORT][13] ([i915#10183]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-dg2-1/igt@gem_cre...@create-ext-cpu-access-big.html > > * igt@gem_ctx_exec@basic-nohangcheck: > - shard-tglu: [PASS][14] -> [FAIL][15] ([i915#6268]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14311/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-tglu-3/igt@gem_ctx_e...@basic-nohangcheck.html > > * igt@gem_ctx_param@set-priority-not-supported: > - shard-mtlp: NOTRUN -> [SKIP][16] ([fdo#109314]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@gem_ctx_pa...@set-priority-not-supported.html > > * igt@gem_ctx_persistence@heartbeat-stop: > - shard-mtlp: NOTRUN -> [SKIP][17] ([i915#8555]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-7/igt@gem_ctx_persiste...@heartbeat-stop.html > > * igt@gem_ctx_sseu@engines: > - shard-mtlp: NOTRUN -> [SKIP][18] ([i915#280]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130016v2/shard-mtlp-4/igt@gem_ctx_s...@engines.html > > * igt@gem_exec_balancer@bonded-false-hang:
Re: ✗ Fi.CI.IGT: failure for drm/i915/cdclk: Rename intel_cdclk_needs_modeset to intel_cdclk_clock_changed (rev2)
On Mon, Feb 19, 2024 at 08:30:00PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/cdclk: Rename intel_cdclk_needs_modeset to > intel_cdclk_clock_changed (rev2) > URL : https://patchwork.freedesktop.org/series/129908/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_14296_full -> Patchwork_129908v2_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_129908v2_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_129908v2_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 -> 7) > -- > > Missing(1): shard-glk-0 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_129908v2_full: > > ### IGT changes ### > > Possible regressions > > * igt@sysfs_heartbeat_interval@mixed@vcs0: > - shard-mtlp: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-mtlp-5/igt@sysfs_heartbeat_interval@mi...@vcs0.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129908v2/shard-mtlp-4/igt@sysfs_heartbeat_interval@mi...@vcs0.html Unrelated incomplete on a GT test. Unrelated to the display function rename here. Applied to drm-intel-next. Thanks for the patch and review. Matt > > > Known issues > > > Here are the changes found in Patchwork_129908v2_full that come from known > issues: > > ### CI changes ### > > Issues hit > > * boot: > - shard-rkl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], > [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], > [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], > [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], > [PASS][25], [PASS][26]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], > [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], > [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], > [PASS][43], [PASS][44], [PASS][45], [FAIL][46], [PASS][47], [PASS][48], > [PASS][49], [PASS][50]) ([i915#8293]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-1/boot.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-1/boot.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-1/boot.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-1/boot.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-1/boot.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-2/boot.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-2/boot.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-3/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-3/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-4/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-4/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-4/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-4/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-4/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-5/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-5/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-5/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-5/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-6/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-6/boot.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-7/boot.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-7/boot.html >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-7/boot.html >[26]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14296/shard-rkl-7/boot.html >[27]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129908v2/shard-rkl-1/boot.html >[28]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129908v2/shard-rkl-1/boot.html >[29]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129908v2/shard-rkl-1/boot.html >[30]: >
Re: [PATCH V2] drm/i915/mtl: Update workaround 14018575942
On Wed, Feb 28, 2024 at 04:07:38PM +0530, Tejas Upadhyay wrote:
> Applying WA 14018575942 only on Compute engine has impact on
> some apps like chrome. Updating this WA to apply on Render
> engine as well as it is helping with performance on Chrome.
>
> Note: There is no concern from media team thus not applying
> WA on media engines. We will revisit if any issues reported
> from media team.
>
> V2(Matt):
> - Use correct WA number
>
> Fixes: 668f37e1ee11 ("drm/i915/mtl: Update workaround 14018778641")
> Signed-off-by: Tejas Upadhyay
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..25413809b9dc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1653,6 +1653,7 @@ static void
> xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> /* Wa_14018575942 / Wa_18018781329 */
> + wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_22016670082 */
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On Thu, Feb 22, 2024 at 11:03:27PM +0100, Andi Shyti wrote:
> Hi Matt,
>
> first of all thanks a lot for the observations you are raising.
>
> On Wed, Feb 21, 2024 at 12:51:04PM -0800, Matt Roper wrote:
> > On Wed, Feb 21, 2024 at 01:12:18AM +0100, Andi Shyti wrote:
> > > On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> > > > On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
>
> ...
>
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > > > index a425db5ed3a2..e19df4ef47f6 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > > > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt
> > > > > *gt)
> > > > > }
> > > > > }
> > > > >
> > > > > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > > > > +{
> > > > > + if (!IS_DG2(gt->i915))
> > > > > + return;
> > > > > +
> > > > > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
> > > >
> > > > This doesn't look right to me. A value of 0 means every cslice gets
> > > > associated with CCS0.
> > >
> > > Yes, that's what I'm trying to do. The behavior I'm looking for
> > > is this one:
> > >
> > >/*
> > > ...
> > > * With 1 engine (ccs0):
> > > * slice 0, 1, 2, 3: ccs0
> > > *
> > > * With 2 engines (ccs0, ccs1):
> > > * slice 0, 2: ccs0
> > > * slice 1, 3: ccs1
> > > *
> > > * With 4 engines (ccs0, ccs1, ccs2, ccs3):
> > > * slice 0: ccs0
> > > * slice 1: ccs1
> > > * slice 2: ccs2
> > > * slice 3: ccs3
> > > ...
> > > */
> > >
> > > where the user can configure runtime the mode, making sure that
> > > no client is connected to i915.
> > >
> > > But, this needs to be written
> > >
> > > As we are now forcing mode '1', then all cslices are connected
> > > with ccs0.
> >
> > Right --- and that's what I'm pointing out as illegal. I think that
> > code comment above was taken out of context from a different RFC series;
> > that's not an accurate description of the behavior we want here.
> >
> > First, the above comment is using ccs# to refer to userspace engines,
> > not hardware engines. As a simple example, DG2-G11 only ever has a
> > single CCS which userspace sees as "instance 0" but which is actually
> > CCS1 at the hardware level. If you try to follow the comment above when
> > programming CCS_MODE, you've assigned all of the cslices to a
> > non-existent engine and assigned no cslices to the CCS engine that
> > actually exists. For DG2-G10 (and I think DG2-G12), there are different
> > combinations of fused-off / not-fused-off engines that will always show
> > up in userspace as CCS0-CCSn, even if those don't match the hardware
> > IDs.
> >
> > Second, the above comment is assuming that you have a part with a
> > maximum fusing config (i.e., all cslices present). Using DG2-G11 again
> > as an example, there's also only a single cslice (cslice1), so if you
> > tell CCS1 that it's allowed to use EUs from non-existent cslice0,
> > cslice2, and cslice3, you might not get the behavior you were hoping
> > for.
>
> if the hardware slices are fused off we wouldn't see them in a
> first place, right? And that's anyway a permanent configuration
> that wouldn't affect the patch.
There are physically four possible cslices in the IP design. The
presence/absence of each of those cslices can vary both by SKU and by
part-specific fusing. Some SKUs (DG2-G11) wind up only ever having a
single possible configuration as far as I know, but the larger SKUs have
more part-to-part variation in terms of exactly which specific subset of
DSS (and by extension cslices) are present/absent. The KMD determines
the configuration at runtime by reading the DSS fuse registers and
deriving the cslice presence/absence from that.
The register you're writing in this patch tells the CCS engine which
cslice(s) it can use to execute work. If the KMD already knows that
cslice doesn't exist, but it tells CCS that it can go ahead and
use it anyway, things probably won't work properly. That's why the spec
Re: [PATCH] drm/i915/mtl: Update workaround 14018778641
On Thu, Feb 22, 2024 at 07:27:15PM +0530, Tejas Upadhyay wrote:
> Applying WA 14018778641 only on Compute engine has impact on
14018778641 is not a workaround number. The only lineage numbers that
are relevant to this programming are Wa_18018781329 (for DG2) and
Wa_14018575942 (for MTL/ARL). Even though other things like internal
tickets and work tracking records have similar numbers we should not be
mixing those up with the actual workaround (lineage) numbers.
Matt
> some apps like chrome. Updating this WA to apply on Render
> engine as well as it is helping with performance on Chrome.
>
> Note: There is no concern from media team thus not applying
> WA on media engines. We will revisit if any issues reported
> from media team.
>
> Fixes: 668f37e1ee11 ("drm/i915/mtl: Update workaround 14018778641")
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..46607aefc026 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1652,7 +1652,8 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> static void
> xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> - /* Wa_14018575942 / Wa_18018781329 */
> + /* Wa_14018575942 / Wa_14018778641 / Wa_18018781329 */
> + wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_22016670082 */
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On Wed, Feb 21, 2024 at 01:12:18AM +0100, Andi Shyti wrote:
> Hi Matt,
>
> thanks a lot for looking into this.
>
> On Tue, Feb 20, 2024 at 03:39:18PM -0800, Matt Roper wrote:
> > On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
>
> [...]
>
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > index 833987015b8b..7041acc77810 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> > > drm_i915_private *i915)
> > > if (engine->uabi_class == I915_NO_UABI_CLASS)
> > > continue;
> > >
> > > + /*
> > > + * Do not list and do not count CCS engines other than the first
> > > + */
> > > + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> > > + engine->uabi_instance > 0) {
> > > + i915->engine_uabi_class_count[engine->uabi_class]--;
> > > + continue;
> > > + }
> >
> > Wouldn't it be simpler to just add a workaround to the end of
> > engine_mask_apply_compute_fuses() if we want to ensure only a single
> > compute engine gets exposed? Then both the driver internals and uapi
> > will agree that's there's just one CCS (and on which one there is).
> >
> > If we want to do something fancy with "hotplugging" a new engine later
> > on or whatever, that can be handled in the future series (although as
> > noted on the previous patch, it sounds like these changes might not
> > actually be aligned with the workaround we were trying to address).
>
> The hotplugging capability is one of the features I was looking
> for, actually.
>
> I have done some more refactoring in this piece of code in
> upcoming patches.
>
> Will check, though, if I can do something with compute_fuses(),
> even though, the other cslices are not really fused off (read
> below).
>
> > > +
> > > rb_link_node(>uabi_node, prev, p);
> > > rb_insert_color(>uabi_node, >uabi_engines);
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > index a425db5ed3a2..e19df4ef47f6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> > > }
> > > }
> > >
> > > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > > +{
> > > + if (!IS_DG2(gt->i915))
> > > + return;
> > > +
> > > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
> >
> > This doesn't look right to me. A value of 0 means every cslice gets
> > associated with CCS0.
>
> Yes, that's what I'm trying to do. The behavior I'm looking for
> is this one:
>
>/*
> ...
> * With 1 engine (ccs0):
> * slice 0, 1, 2, 3: ccs0
> *
> * With 2 engines (ccs0, ccs1):
> * slice 0, 2: ccs0
> * slice 1, 3: ccs1
> *
> * With 4 engines (ccs0, ccs1, ccs2, ccs3):
> * slice 0: ccs0
> * slice 1: ccs1
> * slice 2: ccs2
> * slice 3: ccs3
> ...
> */
>
> where the user can configure runtime the mode, making sure that
> no client is connected to i915.
>
> But, this needs to be written
>
> As we are now forcing mode '1', then all cslices are connected
> with ccs0.
Right --- and that's what I'm pointing out as illegal. I think that
code comment above was taken out of context from a different RFC series;
that's not an accurate description of the behavior we want here.
First, the above comment is using ccs# to refer to userspace engines,
not hardware engines. As a simple example, DG2-G11 only ever has a
single CCS which userspace sees as "instance 0" but which is actually
CCS1 at the hardware level. If you try to follow the comment above when
programming CCS_MODE, you've assigned all of the cslices to a
non-existent engine and assigned no cslices to the CCS engine that
actually exists. For DG2-G10 (and I think DG2-G12), there are different
combinations of fused-off / not-fused-off engines that will always show
up in userspace as CCS0-CCSn, even if those don't match the hardware
IDs.
Second, the ab
Re: [PATCH v2 2/2] drm/i915/gt: Enable only one CCS for compute workload
On Tue, Feb 20, 2024 at 03:35:26PM +0100, Andi Shyti wrote:
> Enable only one CCS engine by default with all the compute sices
> allocated to it.
>
> While generating the list of UABI engines to be exposed to the
> user, exclude any additional CCS engines beyond the first
> instance.
>
> This change can be tested with igt i915_query.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 9 +
> drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> drivers/gpu/drm/i915/i915_query.c | 1 +
> 4 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 833987015b8b..7041acc77810 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -243,6 +243,15 @@ void intel_engines_driver_register(struct
> drm_i915_private *i915)
> if (engine->uabi_class == I915_NO_UABI_CLASS)
> continue;
>
> + /*
> + * Do not list and do not count CCS engines other than the first
> + */
> + if (engine->uabi_class == I915_ENGINE_CLASS_COMPUTE &&
> + engine->uabi_instance > 0) {
> + i915->engine_uabi_class_count[engine->uabi_class]--;
> + continue;
> + }
Wouldn't it be simpler to just add a workaround to the end of
engine_mask_apply_compute_fuses() if we want to ensure only a single
compute engine gets exposed? Then both the driver internals and uapi
will agree that's there's just one CCS (and on which one there is).
If we want to do something fancy with "hotplugging" a new engine later
on or whatever, that can be handled in the future series (although as
noted on the previous patch, it sounds like these changes might not
actually be aligned with the workaround we were trying to address).
> +
> rb_link_node(>uabi_node, prev, p);
> rb_insert_color(>uabi_node, >uabi_engines);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index a425db5ed3a2..e19df4ef47f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> }
> }
>
> +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +{
> + if (!IS_DG2(gt->i915))
> + return;
> +
> + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
This doesn't look right to me. A value of 0 means every cslice gets
associated with CCS0. On a DG2-G11 platform, that will flat out break
compute since CCS0 is never present (G11 only has a single CCS and it's
always the hardware's CCS1). Even on a G10 or G12 this could also break
things depending on the fusing of your card if the hardware CCS0 happens
to be missing.
Also, the register says that we need a field value of 0x7 for each
cslice that's fused off. By passing 0, we're telling the CCS engine
that it can use cslices that may not actually exist.
> +}
> +
> int intel_gt_init_hw(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> @@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
>
> intel_gt_init_swizzling(gt);
>
> + /* Configure CCS mode */
> + intel_gt_apply_ccs_mode(gt);
> +
> /*
>* At least 830 can leave some of the unused rings
>* "active" (ie. head != tail) after resume which
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index cf709f6c05ae..c148113770ea 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1605,6 +1605,8 @@
> #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> #define GEN12_CAGF_MASKREG_GENMASK(19, 11)
>
> +#define XEHP_CCS_MODE _MMIO(0x14804)
Nitpick: this doesn't seem to be in the proper place and also breaks
the file's convention of using tabs to move over to column 48 for the
definition value.
Matt
> +
> #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
> #define GEN11_CSME (31)
> #define GEN12_HECI_2 (30)
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/
Re: [PATCH v2 1/2] drm/i915/gt: Disable HW load balancing for CCS
On Tue, Feb 20, 2024 at 03:35:25PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_14019159160 recommends disabling it across all
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..9126b37186fc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
>GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> }
> +
> + /*
> + * Wa_14019159160: disable the CCS load balancing
> + * indiscriminately for all the platforms
The database's description of this workaround is a bit confusing since
it's been modified a few times, but if I'm reading it correctly it
doesn't sound like this is what it's asking us to do. What I see says
that load balancing shouldn't be allowed specifically while the RCS is
active. If the RCS is sitting idle, I believe you're free to use as
many CCS engines as you like, with load balancing still active.
We already have other workarounds that prevent different address spaces
from executing on the RCS/CCS engines at the same time, so the part
about "same address space" in the description should already be
satisfied. It sounds like the issues now are if 2+ CCS's are in use and
something new shows up to run on the previously-idle RCS, or if
something's already running on the RCS and 1 CCS, and something new
shows up to run on an additional CCS. The workaround details make it
sound like it's supposed to be the GuC's responsibility to prevent the
new work from getting scheduled onto the additional engine while we're
already in one of those two situations, so I don't see anything asking
us to change the hardware-level load balance enable/disable (actually
the spec specifically tells us *not* to do this). Aren't we supposed to
be just setting a GuC workaround flag for this?
Matt
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> }
>
> static void
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/2] drm/i915/gt: Disable HW load balancing for CCS
On Thu, Feb 15, 2024 at 02:59:23PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_16016805146 recommends disabling it across all
Is this the right workaround number? When I check the database, this
workaround was rejected on both DG2-G10 and DG2-G11, and doesn't even
have an entry for DG2-G12.
There are other workarounds that sound somewhat related to load
balancing (e.g., part 3 of Wa_14019159160), but what's asked there is
more involved than just setting one register bit and conflicts a bit
with the second patch of this series.
Matt
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..7f42c8015f71 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
>GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> }
> +
> + /*
> + * Wa_16016805146: disable the CCS load balancing
> + * indiscriminately for all the platforms
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> }
>
> static void
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915: Update ADL-N PCI IDs
On Wed, Feb 14, 2024 at 03:05:42PM +, Bhadane, Dnyaneshwar wrote: > > > > -Original Message- > > From: Intel-gfx On Behalf Of > > Gustavo Sousa > > Sent: Wednesday, February 14, 2024 8:17 PM > > To: intel-gfx@lists.freedesktop.org > > Subject: [PATCH] drm/i915: Update ADL-N PCI IDs > > > > Extend the list of ADL-N PCI IDs to contain two new entries. > > > > Bspec: 68397 > > Signed-off-by: Gustavo Sousa > > Looks good to me, > Thanks for the patch. > > Reviewed-by: Dnyaneshwar Bhadane Applied to drm-intel-next. Thanks for the patch and review. Matt > > Dnyaneshwar > > --- > > include/drm/i915_pciids.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > > 07779a11758e..28a96aa1e08f 100644 > > --- a/include/drm/i915_pciids.h > > +++ b/include/drm/i915_pciids.h > > @@ -672,7 +672,9 @@ > > #define INTEL_ADLN_IDS(info) \ > > INTEL_VGA_DEVICE(0x46D0, info), \ > > INTEL_VGA_DEVICE(0x46D1, info), \ > > - INTEL_VGA_DEVICE(0x46D2, info) > > + INTEL_VGA_DEVICE(0x46D2, info), \ > > + INTEL_VGA_DEVICE(0x46D3, info), \ > > + INTEL_VGA_DEVICE(0x46D4, info) > > > > /* RPL-S */ > > #define INTEL_RPLS_IDS(info) \ > > -- > > 2.43.0 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: ✗ Fi.CI.IGT: failure for drm/i915/display: update pll values in sync with Bspec for MTL (rev2)
On Wed, Feb 14, 2024 at 10:50:20AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: update pll values in sync with Bspec for MTL (rev2) > URL : https://patchwork.freedesktop.org/series/129878/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_14268_full -> Patchwork_129878v2_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_129878v2_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_129878v2_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 -> 9) > -- > > Additional (1): shard-snb-0 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_129878v2_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_vblank@ts-continuation-suspend@pipe-b-hdmi-a-1: > - shard-rkl: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-4/igt@kms_vblank@ts-continuation-susp...@pipe-b-hdmi-a-1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-rkl-4/igt@kms_vblank@ts-continuation-susp...@pipe-b-hdmi-a-1.html This RKL suspend issue is https://gitlab.freedesktop.org/drm/intel/-/issues/2787 and is not related to this patch. Applied to drm-intel-next. Thanks for the patch and review. Matt > > > Known issues > > > Here are the changes found in Patchwork_129878v2_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@drm_fdinfo@busy-hang@bcs0: > - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8414]) +23 other tests > skip >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-10/igt@drm_fdinfo@busy-h...@bcs0.html > > * igt@gem_create@create-ext-cpu-access-big: > - shard-dg2: NOTRUN -> [ABORT][4] ([i915#10183]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-2/igt@gem_cre...@create-ext-cpu-access-big.html > > * igt@gem_create@create-ext-cpu-access-sanity-check: > - shard-rkl: NOTRUN -> [SKIP][5] ([i915#6335]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-rkl-1/igt@gem_cre...@create-ext-cpu-access-sanity-check.html > > * igt@gem_ctx_exec@basic-nohangcheck: > - shard-rkl: [PASS][6] -> [FAIL][7] ([i915#6268]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-rkl-3/igt@gem_ctx_e...@basic-nohangcheck.html > > * igt@gem_ctx_persistence@heartbeat-close: > - shard-dg2: NOTRUN -> [SKIP][8] ([i915#8555]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-1/igt@gem_ctx_persiste...@heartbeat-close.html > > * igt@gem_ctx_sseu@engines: > - shard-dg2: NOTRUN -> [SKIP][9] ([i915#280]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-10/igt@gem_ctx_s...@engines.html > > * igt@gem_eio@unwedge-stress: > - shard-dg1: [PASS][10] -> [FAIL][11] ([i915#5784]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-dg1-18/igt@gem_...@unwedge-stress.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg1-12/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_balancer@bonded-dual: > - shard-dg2: NOTRUN -> [SKIP][12] ([i915#4771]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-10/igt@gem_exec_balan...@bonded-dual.html > > * igt@gem_exec_fair@basic-none-rrul: > - shard-dg2: NOTRUN -> [SKIP][13] ([i915#3539] / [i915#4852]) +2 > other tests skip >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-dg2-10/igt@gem_exec_f...@basic-none-rrul.html > > * igt@gem_exec_fair@basic-none-share@rcs0: > - shard-glk: NOTRUN -> [FAIL][14] ([i915#2842]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-glk9/igt@gem_exec_fair@basic-none-sh...@rcs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) +2 other > tests fail >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14268/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129878v2/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > - shard-rkl: [PASS][17]
Re: [PATCH 1/3] drm/i915/bios: bump expected child device size
On Wed, Jan 31, 2024 at 08:48:39PM +0200, Jani Nikula wrote:
> VBT versions since 256 have an extra byte for EFP index.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 5f04e495fd27..2805ad701fe4 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2736,8 +2736,10 @@ parse_general_definitions(struct drm_i915_private
> *i915)
> expected_size = 37;
> } else if (i915->display.vbt.version <= 215) {
> expected_size = 38;
> - } else if (i915->display.vbt.version <= 250) {
> + } else if (i915->display.vbt.version <= 255) {
> expected_size = 39;
> + } else if (i915->display.vbt.version <= 256) {
> + expected_size = 40;
> } else {
> expected_size = sizeof(*child);
> BUILD_BUG_ON(sizeof(*child) < 39);
Should this size be updated as well?
Matt
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index a9f44abfc9fc..648934fcd123 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -485,6 +485,7 @@ struct child_device_config {
> u8 hdmi_iboost_level:4; /* 196+ */
> u8 dp_max_link_rate:3; /* 216+ */
> u8 dp_max_link_rate_reserved:5; /* 216+ */
> + u8 efp_index; /* 256+ */
> } __packed;
>
> struct bdb_general_definitions {
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 2/4] drm/xe: add bind time pat index to xe_bo structure
On Tue, Jan 30, 2024 at 09:36:50PM +0200, Juha-Pekka Heikkila wrote:
> Add BO bind time pat index member to xe_bo structure and store
> pat index from xe_vma to xe_bo.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/xe/xe_bo_types.h | 12
> drivers/gpu/drm/xe/xe_pt.c | 22 ++
> 2 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo_types.h
> b/drivers/gpu/drm/xe/xe_bo_types.h
> index 14ef13b7b421..6d599f1e846b 100644
> --- a/drivers/gpu/drm/xe/xe_bo_types.h
> +++ b/drivers/gpu/drm/xe/xe_bo_types.h
> @@ -91,6 +91,18 @@ struct xe_bo {
>
> /** @vram_userfault_link: Link into @mem_access.vram_userfault.list */
> struct list_head vram_userfault_link;
> +
> + /**
> + * @pat_index: The pat index requested when bind this BO
> + */
> + u16 pat_index;
> +
> + /**
> + * @has_sealed_pat_index: The pat index is sealed because this BO is
> + * pinned as framebuffer. This is to prevent flipping compression
> + * on/off from framebuffers while in use.
> + */
> + bool has_sealed_pat_index;
> };
>
> #define intel_bo_to_drm_bo(bo) (&(bo)->ttm.base)
> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index de1030a47588..c72cb75d993c 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -1208,10 +1208,11 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma
> *vma, struct xe_exec_queue
> struct dma_fence *fence;
> struct invalidation_fence *ifence = NULL;
> struct xe_range_fence *rfence;
> + struct xe_bo *bo = xe_vma_bo(vma);
> int err;
>
> bind_pt_update.locked = false;
> - xe_bo_assert_held(xe_vma_bo(vma));
> + xe_bo_assert_held(bo);
> xe_vm_assert_held(vm);
>
> vm_dbg(_vma_vm(vma)->xe->drm,
> @@ -1252,8 +1253,21 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma
> *vma, struct xe_exec_queue
> return ERR_PTR(-ENOMEM);
> }
>
> + /*
> + * On Xe2 BO which was pinned as framebuffer before with different
> + * PAT index cannot be bound with different PAT index. This is
> + * to prevent switching CCS on/off from framebuffers on the fly
> + * with Xe2.
> + */
I haven't been following all the discussion here, but why is switching
it on/off a problem? On Xe2 can't we just always turn on decompression
(assuming they were 4-tile)?
Even if a content producer puts data into the buffer using a
non-compression PAT index, my understanding is that the FlatCCS metadata
for that part of the buffer still gets updated appropriately (to or
whatever the code is for "uncompressed block"). If the decompression
bit in PLANE_CTL basically translates to "pay attention to FlatCCS" vs
"ignore FlatCCS" it shouldn't matter whether the data is truly
compressed or not, right? Since the FlatCCS area that corresponds to a
buffer is still correct even when non-compressed PAT is used (I think),
is there a reason to turn off decompression for 4-tile?
Am I overlooking something?
Matt
> + if (bo) {
> + if (bo->has_sealed_pat_index && bo->pat_index != vma->pat_index)
> + return ERR_PTR(-EINVAL);
> +
> + bo->pat_index = vma->pat_index;
> + }
> +
> fence = xe_migrate_update_pgtables(tile->migrate,
> -vm, xe_vma_bo(vma), q,
> +vm, bo, q,
> entries, num_entries,
> syncs, num_syncs,
> _pt_update.base);
> @@ -1287,8 +1301,8 @@ __xe_pt_bind_vma(struct xe_tile *tile, struct xe_vma
> *vma, struct xe_exec_queue
> DMA_RESV_USAGE_KERNEL :
> DMA_RESV_USAGE_BOOKKEEP);
>
> - if (!xe_vma_has_no_bo(vma) && !xe_vma_bo(vma)->vm)
> - dma_resv_add_fence(xe_vma_bo(vma)->ttm.base.resv, fence,
> + if (!xe_vma_has_no_bo(vma) && !bo->vm)
> + dma_resv_add_fence(bo->ttm.base.resv, fence,
> DMA_RESV_USAGE_BOOKKEEP);
> xe_pt_commit_bind(vma, entries, num_entries, rebind,
> bind_pt_update.locked ? : NULL);
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/2] drm/i915/xe2lpd: Move D2D enable/disable
On Fri, Jan 26, 2024 at 02:46:36PM -0800, Lucas De Marchi wrote:
> Bits to enable/disable and check state for D2D moved from
> XELPDP_PORT_BUF_CTL1 to DDI_BUF_CTL (now named DDI_CTL_DE in the spec).
> Make the functions mtl_ddi_disable_d2d() and mtl_ddi_enable_d2d generic
> to work with multiple reg location and bitfield layout.
>
> v2: Set/Clear XE2LPD_DDI_BUF_D2D_LINK_ENABLE in saved_port_bits when
> enabling/disabling D2D so DDI_BUF_CTL is correctly programmed in
> other places without overriding these bits (Clint)
> v3: Leave saved_port_bits alone as those bits are not meant to be
> modified outside of the port initialization. Rather propagate the
> additional bit in DDI_BUF_CTL to be set when that register is
> written again after D2D is enabled.
>
> Cc: Matt Roper
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 44 ++--
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 12a29363e5df..188c537dbb5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2429,13 +2429,22 @@ mtl_ddi_enable_d2d(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = encoder->port;
> + i915_reg_t reg;
> + u32 set_bits, wait_bits;
>
> - intel_de_rmw(dev_priv, XELPDP_PORT_BUF_CTL1(port), 0,
> - XELPDP_PORT_BUF_D2D_LINK_ENABLE);
> + if (DISPLAY_VER(dev_priv) >= 20) {
> + reg = DDI_BUF_CTL(port);
> + set_bits = XE2LPD_DDI_BUF_D2D_LINK_ENABLE;
> + wait_bits = XE2LPD_DDI_BUF_D2D_LINK_STATE;
> + } else {
> + reg = XELPDP_PORT_BUF_CTL1(port);
> + set_bits = XELPDP_PORT_BUF_D2D_LINK_ENABLE;
> + wait_bits = XELPDP_PORT_BUF_D2D_LINK_STATE;
> + }
>
> - if (wait_for_us((intel_de_read(dev_priv, XELPDP_PORT_BUF_CTL1(port)) &
> - XELPDP_PORT_BUF_D2D_LINK_STATE), 100)) {
> - drm_err(_priv->drm, "Timeout waiting for D2D Link enable
> for PORT_BUF_CTL %c\n",
> + intel_de_rmw(dev_priv, reg, 0, set_bits);
> + if (wait_for_us(intel_de_read(dev_priv, reg) & wait_bits, 100)) {
> + drm_err(_priv->drm, "Timeout waiting for D2D Link enable
> for DDI/PORT_BUF_CTL %c\n",
> port_name(port));
> }
> }
> @@ -2898,13 +2907,22 @@ mtl_ddi_disable_d2d_link(struct intel_encoder
> *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = encoder->port;
> + i915_reg_t reg;
> + u32 clr_bits, wait_bits;
>
> - intel_de_rmw(dev_priv, XELPDP_PORT_BUF_CTL1(port),
> - XELPDP_PORT_BUF_D2D_LINK_ENABLE, 0);
> + if (DISPLAY_VER(dev_priv) >= 20) {
> + reg = DDI_BUF_CTL(port);
> + clr_bits = XE2LPD_DDI_BUF_D2D_LINK_ENABLE;
> + wait_bits = XE2LPD_DDI_BUF_D2D_LINK_STATE;
> + } else {
> + reg = XELPDP_PORT_BUF_CTL1(port);
> + clr_bits = XELPDP_PORT_BUF_D2D_LINK_ENABLE;
> + wait_bits = XELPDP_PORT_BUF_D2D_LINK_STATE;
> + }
>
> - if (wait_for_us(!(intel_de_read(dev_priv, XELPDP_PORT_BUF_CTL1(port)) &
> - XELPDP_PORT_BUF_D2D_LINK_STATE), 100))
> - drm_err(_priv->drm, "Timeout waiting for D2D Link disable
> for PORT_BUF_CTL %c\n",
> + intel_de_rmw(dev_priv, reg, clr_bits, 0);
> + if (wait_for_us(!(intel_de_read(dev_priv, reg) & wait_bits), 100))
> + drm_err(_priv->drm, "Timeout waiting for D2D Link disable
> for DDI/PORT_BUF_CTL %c\n",
> port_name(port));
> }
>
> @@ -3323,6 +3341,9 @@ static void intel_enable_ddi_hdmi(struct
> intel_atomic_state *state,
>XELPDP_PORT_WIDTH_MASK | XELPDP_PORT_REVERSAL,
> port_buf);
>
> buf_ctl |= DDI_PORT_WIDTH(lane_count);
> +
> + if (DISPLAY_VER(dev_priv) >= 20)
> +buf_ctl |= XE2LPD_DDI_BUF_D2D_LINK_ENABLE;
> } else if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) {
> drm_WARN_ON(_priv->drm,
> !intel_tc_port_in_legacy_mode(dig_port));
> buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
> @@ -3543,6 +3564,9 @@ static void mtl_ddi_prepare_link_retrain(struct
> intel_dp *intel_dp,
&g
Re: [PATCH] drm/i915/mtl: Wake GT before sending H2G message
On Thu, Jan 18, 2024 at 05:21:23PM -0800, Belgaumkar, Vinay wrote:
>
> On 1/18/2024 3:50 PM, Matt Roper wrote:
> > On Thu, Jan 18, 2024 at 03:17:28PM -0800, Vinay Belgaumkar wrote:
> > > Instead of waiting until the interrupt reaches GuC, we can grab a
> > > forcewake while triggering the H2G interrupt. GEN11_GUC_HOST_INTERRUPT
> > > is inside an "always on" domain with respect to RC6. However, there
> > A bit of a nitpick, but technically "always on" is a description of GT
> > register ranges that never get powered down. GEN11_GUC_HOST_INTERRUPT
> > isn't inside the GT at all, but rather is an sgunit register and thus
> > isn't affected by forcewake. This is just a special case where the
> > sgunit register forwards a message back to the GT's GuC, and the
> > workaround wants us to make sure the GT is awake before that message
> > gets there.
> True, can modify the description to reflect this.
> >
> > > could be some delays when platform is entering/exiting some higher
> > > level platform sleep states and a H2G is triggered. A forcewake
> > > ensures those sleep states have been fully exited and further
> > > processing occurs as expected.
> > Based on this description, is adding implicit forcewake to this register
> > really enough? Implicit forcewake powers up before a read/write, but
> > also allows it to power back down as soon as the MMIO operation is
> > complete. If the GuC is a bit slow to notice the interrupt, then we
> > could wind up with a sequence like
> >
> > - Driver grabs forcewake and GT powers up
> > - Driver writes 0x1901f0 to trigger GuC interrupt
> > - Driver releases forcewake and GT powers down
> > - GuC notices interrupt (or maybe fails to notice it because the GT
> > powered down before it had a chance to process it?)
> >
> > which I'm guessing isn't actually going to satisfy this workaround. Do
> > we actually need to keep the GT awake not just through the register
> > operation, but also through the GuC's processing of the interrupt? If
> > so, then we probably want to do an explicit forcewake get/put to ensure
> > the hardware stays powered up long enough.
>
> The issue being addressed here is not GT entering C6, but the higher
> platform sleep states. Once we force wake GT while writing to the H2G
> register, that should bring us out of sleep. After clearing the forcewake
> (which would happen after the write for 0x1901f0 goes through), we still
> have C6 hysteresis and the hysteresis counters for the higher platform sleep
> states which should give GuC enough time to process the interrupt before we
> enter C6 and then subsequently these higher sleep states.
Okay, makes sense. Hopefully the finalize the workaround details and
documentation soon, but this looks reasonable with the information we
have at the moment.
Reviewed-by: Matt Roper
Matt
>
> Thanks,
>
> Vinay.
>
> >
> >
> > Matt
> >
> > > This will have an official WA soon so adding a FIXME in the comments.
> > >
> > > Signed-off-by: Vinay Belgaumkar
> > > ---
> > > drivers/gpu/drm/i915/intel_uncore.c | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > > b/drivers/gpu/drm/i915/intel_uncore.c
> > > index dfefad5a5fec..121458a31886 100644
> > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > @@ -1800,7 +1800,10 @@ static const struct intel_forcewake_range
> > > __mtl_fw_ranges[] = {
> > > GEN_FW_RANGE(0x24000, 0x2ffff, 0), /*
> > > 0x24000 - 0x2407f: always on
> > > 0x24080 - 0x2: reserved */
> > > - GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT)
> > > + GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT),
> > > + GEN_FW_RANGE(0x4, 0x1901ec, 0),
> > > + GEN_FW_RANGE(0x1901f0, 0x1901f0, FORCEWAKE_GT)
> > > + /* FIXME: WA to wake GT while triggering H2G */
> > > };
> > > /*
> > > --
> > > 2.38.1
> > >
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/mtl: Wake GT before sending H2G message
On Thu, Jan 18, 2024 at 03:17:28PM -0800, Vinay Belgaumkar wrote:
> Instead of waiting until the interrupt reaches GuC, we can grab a
> forcewake while triggering the H2G interrupt. GEN11_GUC_HOST_INTERRUPT
> is inside an "always on" domain with respect to RC6. However, there
A bit of a nitpick, but technically "always on" is a description of GT
register ranges that never get powered down. GEN11_GUC_HOST_INTERRUPT
isn't inside the GT at all, but rather is an sgunit register and thus
isn't affected by forcewake. This is just a special case where the
sgunit register forwards a message back to the GT's GuC, and the
workaround wants us to make sure the GT is awake before that message
gets there.
> could be some delays when platform is entering/exiting some higher
> level platform sleep states and a H2G is triggered. A forcewake
> ensures those sleep states have been fully exited and further
> processing occurs as expected.
Based on this description, is adding implicit forcewake to this register
really enough? Implicit forcewake powers up before a read/write, but
also allows it to power back down as soon as the MMIO operation is
complete. If the GuC is a bit slow to notice the interrupt, then we
could wind up with a sequence like
- Driver grabs forcewake and GT powers up
- Driver writes 0x1901f0 to trigger GuC interrupt
- Driver releases forcewake and GT powers down
- GuC notices interrupt (or maybe fails to notice it because the GT
powered down before it had a chance to process it?)
which I'm guessing isn't actually going to satisfy this workaround. Do
we actually need to keep the GT awake not just through the register
operation, but also through the GuC's processing of the interrupt? If
so, then we probably want to do an explicit forcewake get/put to ensure
the hardware stays powered up long enough.
Matt
>
> This will have an official WA soon so adding a FIXME in the comments.
>
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index dfefad5a5fec..121458a31886 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1800,7 +1800,10 @@ static const struct intel_forcewake_range
> __mtl_fw_ranges[] = {
> GEN_FW_RANGE(0x24000, 0x2, 0), /*
> 0x24000 - 0x2407f: always on
> 0x24080 - 0x2: reserved */
> - GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT)
> + GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x4, 0x1901ec, 0),
> + GEN_FW_RANGE(0x1901f0, 0x1901f0, FORCEWAKE_GT)
> + /* FIXME: WA to wake GT while triggering H2G */
> };
>
> /*
> --
> 2.38.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: ✗ Fi.CI.IGT: failure for Extend ARL support
On Mon, Jan 08, 2024 at 03:37:29PM -, Patchwork wrote: > == Series Details == > > Series: Extend ARL support > URL : https://patchwork.freedesktop.org/series/128322/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_14092_full -> Patchwork_128322v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_128322v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_128322v1_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_128322v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@i915_pipe_stress@stress-xrgb-untiled: > - shard-snb: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-snb6/igt@i915_pipe_str...@stress-xrgb-untiled.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128322v1/shard-snb5/igt@i915_pipe_str...@stress-xrgb-untiled.html > > * igt@i915_suspend@basic-s3-without-i915: > - shard-snb: [PASS][3] -> [INCOMPLETE][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-snb2/igt@i915_susp...@basic-s3-without-i915.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128322v1/shard-snb4/igt@i915_susp...@basic-s3-without-i915.html > > * igt@kms_flip@flip-vs-blocking-wf-vblank@c-hdmi-a1: > - shard-tglu: [PASS][5] -> [INCOMPLETE][6] >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-tglu-9/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a1.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128322v1/shard-tglu-9/igt@kms_flip@flip-vs-blocking-wf-vbl...@c-hdmi-a1.html > > * igt@sysfs_heartbeat_interval@mixed@ccs1: > - shard-dg2: [PASS][7] -> [INCOMPLETE][8] >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-dg2-2/igt@sysfs_heartbeat_interval@mi...@ccs1.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128322v1/shard-dg2-7/igt@sysfs_heartbeat_interval@mi...@ccs1.html None of these failures are related to the ARL PCI IDs or graphics version 12.74 workarounds added in this series. First patch applied to drm-intel-next (after adding Haridhar's missing s-o-b line as we discussed offline) and the other two applied to drm-intel-gt-next. Thanks for the patches and reviews. Matt > > > Known issues > > > Here are the changes found in Patchwork_128322v1_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-glk: ([PASS][9], [PASS][10], [PASS][11], [PASS][12], > [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], > [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], > [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) > ([i915#8293]) -> ([PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], > [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], > [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], > [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk9/boot.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk8/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk9/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk9/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk9/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk1/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk1/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk1/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk3/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk3/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk3/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk4/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk4/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14092/shard-glk4/boot.html >[23]: >
Re: ✗ Fi.CI.IGT: failure for Resolve suspend-resume racing with GuC destroy-context-worker (rev13)
On Thu, Jan 04, 2024 at 05:39:16PM +, Teres Alexis, Alan Previn wrote: > On Thu, 2024-01-04 at 10:57 +, Patchwork wrote: > > Patch Details > > Series: Resolve suspend-resume racing with GuC destroy-context-worker > > (rev13) > > URL:https://patchwork.freedesktop.org/series/121916/ > > State: failure > > Details: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v13/index.html > > CI Bug Log - changes from CI_DRM_14076_full -> Patchwork_121916v13_full > > Summary > > > > FAILURE > alan:snip > > > > Here are the unknown changes that may have been introduced in > > Patchwork_121916v13_full: > > > > IGT changes > > Possible regressions > > > > * igt@gem_eio@wait-wedge-immediate: > > * shard-mtlp: > > PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14076/shard-mtlp-3/igt@gem_...@wait-wedge-immediate.html> > > -> > > ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v13/shard-mtlp-4/igt@gem_...@wait-wedge-immediate.html> > > > alan: from the code and dmesg, this is unrelated to guc context destruction > flows. > Its reading an MCR register that times out. Additionally, i believe this > error is occuring during post-reset-init flows. > So its definitely not doing any context destruction at this point (as reset > would have happenned sooner). Yeah, the MCR timeouts are due to these CI machines running an outdated IFWI, so they're missing an important workaround in the firmware. Series applies to drm-intel-gt-next. Thanks for the patches and reviews. Matt > > Known issues > > > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: ✗ Fi.CI.IGT: failure for Update bxt_sanitize_cdclk() for Xe2_LPD (rev3)
On Mon, Jan 08, 2024 at 10:35:56AM -0300, Gustavo Sousa wrote: > Quoting Patchwork (2024-01-05 21:14:37-03:00) > >== Series Details == > > > >Series: Update bxt_sanitize_cdclk() for Xe2_LPD (rev3) > >URL : https://patchwork.freedesktop.org/series/128175/ > >State : failure > > > >== Summary == > > > >CI Bug Log - changes from CI_DRM_14080_full -> Patchwork_128175v3_full > > > > > >Summary > >--- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_128175v3_full absolutely > > need to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_128175v3_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_128175v3_full: > > > >### IGT changes ### > > > > Possible regressions > > > > * igt@kms_vblank@query-busy-hang@pipe-c-hdmi-a-2: > >- shard-glk: [PASS][1] -> [INCOMPLETE][2] > > [1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk6/igt@kms_vblank@query-busy-h...@pipe-c-hdmi-a-2.html > > [2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128175v3/shard-glk7/igt@kms_vblank@query-busy-h...@pipe-c-hdmi-a-2.html > > The dmesg output do not provide conclusive data for the INCOMPLETE status and > I > believe the issue is unrelated, since the real functional change is on the > driver initialization path. > > However, for sanity sake, as GLK takes the bxt_sanitize_cdclk() path during > initialization, could we re-report, please? Since this failure was in the shards rather than BAT, it didn't block any other tests from executing. It looks like this was just one of the random incompletes that sometimes pop up (probably due to network or power hiccups in the lab) I've gone ahead and applied the series to drm-intel-next. Thanks for the patches. Matt > > -- > Gustavo Sousa > > > > > > >Known issues > > > > > > Here are the changes found in Patchwork_128175v3_full that come from known > > issues: > > > >### CI changes ### > > > > Possible fixes > > > > * boot: > >- shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], > > [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], > > [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [FAIL][18], > > [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], > > [PASS][25]) ([i915#8293]) -> ([PASS][26], [PASS][27], [PASS][28], > > [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], > > [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], > > [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], > > [PASS][47], [PASS][48]) > > [3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk9/boot.html > > [4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk9/boot.html > > [5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk9/boot.html > > [6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk8/boot.html > > [7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk8/boot.html > > [8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk8/boot.html > > [9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk8/boot.html > > [10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk7/boot.html > > [11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk7/boot.html > > [12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk7/boot.html > > [13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk7/boot.html > > [14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk6/boot.html > > [15]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk6/boot.html > > [16]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk6/boot.html > > [17]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk5/boot.html > > [18]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk5/boot.html > > [19]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk4/boot.html > > [20]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk4/boot.html > > [21]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk4/boot.html > > [22]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14080/shard-glk3/boot.html > > [23]: > >
Re: [PATCH v1 2/3] drm/i915/xelpg: Extend driver code of Xe_LPG to Xe_LPG+
On Mon, Jan 08, 2024 at 05:57:37PM +0530, Haridhar Kalvala wrote:
> From: Harish Chegondi
>
> Xe_LPG+ (IP version 12.74) should take the same general code
> paths as Xe_LPG (versions 12.70 and 12.71).
>
> Xe_LPG+'s workaround list will be handled by the next patch.
>
> Signed-off-by: Harish Chegondi
> Signed-off-by: Haridhar Kalvala
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 4 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 40687806d22a..1ade568ffbfa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1190,7 +1190,8 @@ static int intel_engine_init_tlb_invalidation(struct
> intel_engine_cs *engine)
> num = ARRAY_SIZE(xelpmp_regs);
> }
> } else {
> - if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 71) ||
> + if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 74) ||
> + GRAPHICS_VER_FULL(i915) == IP_VER(12, 71) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 70) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 50) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 55)) {
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 353f93baaca0..25c1023eb5f9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -495,7 +495,7 @@ static unsigned int get_mocs_settings(struct
> drm_i915_private *i915,
> memset(table, 0, sizeof(struct drm_i915_mocs_table));
>
> table->unused_entries_index = I915_MOCS_PTE;
> - if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 71))) {
> + if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 74))) {
> table->size = ARRAY_SIZE(mtl_mocs_table);
> table->table = mtl_mocs_table;
> table->n_entries = MTL_NUM_MOCS_ENTRIES;
> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> b/drivers/gpu/drm/i915/gt/intel_rc6.c
> index 7090e4be29cb..8f4b3c8af09c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> @@ -123,7 +123,7 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6)
>* temporary wa and should be removed after fixing real cause
>* of forcewake timeouts.
>*/
> - 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, 74)))
> pg_enable =
> GEN9_MEDIA_PG_ENABLE |
> GEN11_MEDIA_SAMPLER_PG_ENABLE;
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index db99c2ef66db..990eaa029d9c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -147,7 +147,7 @@ static const char *i915_cache_level_str(struct
> drm_i915_gem_object *obj)
> {
> struct drm_i915_private *i915 = obj_to_i915(obj);
>
> - if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 71))) {
> + if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 74))) {
> switch (obj->pat_index) {
> case 0: return " WB";
> case 1: return " WT";
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: ✗ Fi.CI.IGT: failure for drm/i915: Add workaround 14019877138
On Wed, Jan 03, 2024 at 02:52:37PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add workaround 14019877138 > URL : https://patchwork.freedesktop.org/series/128143/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_14072_full -> Patchwork_128143v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_128143v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_128143v1_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. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/index.html > > Participating hosts (8 -> 9) > -- > > Additional (1): shard-snb-0 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_128143v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip@2x-flip-vs-blocking-wf-vblank@ab-vga1-hdmi-a1: > - shard-snb: [PASS][1] -> ([PASS][2], [ABORT][3], [PASS][4]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/shard-snb2/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-snb5/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-snb4/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-snb6/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html > > * igt@kms_flip@flip-vs-suspend-interruptible@d-hdmi-a1: > - shard-tglu: [PASS][5] -> ([PASS][6], [INCOMPLETE][7], [PASS][8]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/shard-tglu-10/igt@kms_flip@flip-vs-suspend-interrupti...@d-hdmi-a1.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-tglu-9/igt@kms_flip@flip-vs-suspend-interrupti...@d-hdmi-a1.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-tglu-6/igt@kms_flip@flip-vs-suspend-interrupti...@d-hdmi-a1.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-tglu-5/igt@kms_flip@flip-vs-suspend-interrupti...@d-hdmi-a1.html There don't seem to be any CI logs for these two failures, but adding a workaround on Xe_LPG wouldn't have any impact on platforms using older IP, so these aren't related. > > * igt@kms_plane@pixel-format-source-clamping@pipe-b: > - shard-mtlp: [PASS][9] -> ([ABORT][10], [PASS][11], [PASS][12]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/shard-mtlp-2/igt@kms_plane@pixel-format-source-clamp...@pipe-b.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-mtlp-2/igt@kms_plane@pixel-format-source-clamp...@pipe-b.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-mtlp-8/igt@kms_plane@pixel-format-source-clamp...@pipe-b.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-mtlp-6/igt@kms_plane@pixel-format-source-clamp...@pipe-b.html <4> [574.849114] i915 :00:02.0: Unclaimed read from register 0x44418 That's DE_PIPE_IIR, which should be a valid register for the platform, so we must have powered down the pipe between the time interrupt was reported and when we got around to handling it. Anyway, that's a display-side problem and wouldn't be caused by this GT workaround. > > * igt@prime_busy@hang-wait@vecs0: > - shard-glk: [PASS][13] -> ([INCOMPLETE][14], [PASS][15]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14072/shard-glk9/igt@prime_busy@hang-w...@vecs0.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-glk6/igt@prime_busy@hang-w...@vecs0.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_128143v1/shard-glk8/igt@prime_busy@hang-w...@vecs0.html No CI logs for this one either, but as above an Xe_LPG workaround couldn't affect a gen9lp platform. Applied to drm-intel-gt-next. Thanks for the patch. Matt > > > New tests > - > > New tests have been introduced between CI_DRM_14072_full and > Patchwork_128143v1_full: > > ### New IGT tests (5) ### > > * igt@kms_flip@flip-vs-expired-vblank@a-dp4: > - Statuses : 1 pass(s) > - Exec time: [7.92] s > > * igt@kms_flip@flip-vs-expired-vblank@b-dp4: > - Statuses : 1 pass(s) > - Exec time: [7.76] s > > * igt@kms_flip@flip-vs-panning-interruptible@a-dp4: > - Statuses : 1 pass(s) > - Exec time:
Re: [PATCH 4/4] drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing
On Fri, Jan 05, 2024 at 11:09:37AM -0300, Gustavo Sousa wrote:
> Quoting Matt Roper (2024-01-04 20:52:32-03:00)
> >On Thu, Jan 04, 2024 at 03:48:34PM -0800, Matt Roper wrote:
> >> On Thu, Jan 04, 2024 at 12:21:50AM -0300, Gustavo Sousa wrote:
> >> > That's the function responsible for deriving that register's value; use
> >> > it.
> >> >
> >> > Signed-off-by: Gustavo Sousa
> >>
> >> Reviewed-by: Matt Roper
> >
> >Forgot to mention...I think it's a bit jarring when the commit message
> >starts out referring to something in the headline ("That's the
> >function..."). It's probably a bit better to just re-state the function
> >name in the commit message again rather than assuming both get read
> >together.
>
> Thanks for the suggestion!
>
> I have sent a v2 updating the body of commit messages, not only for this one
> but
> also for two more patches. I have kept your r-b's. Let me know if that's okay.
Yep, the r-b's still apply. Thanks.
Matt
>
> --
> Gustavo Sousa
>
> >
> >
> >Matt
> >
> >>
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 +++---
> >> > 1 file changed, 3 insertions(+), 23 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> > index fbe9aba41c35..26200ee3e23f 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> > @@ -2051,7 +2051,7 @@ static void bxt_set_cdclk(struct drm_i915_private
> >> > *dev_priv,
> >> > static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
> >> > {
> >> > u32 cdctl, expected;
> >> > -int cdclk, clock, vco;
> >> > +int cdclk, vco;
> >> >
> >> > intel_update_cdclk(dev_priv);
> >> > intel_cdclk_dump_config(dev_priv, _priv->display.cdclk.hw,
> >> > "Current CDCLK");
> >> > @@ -2076,6 +2076,7 @@ static void bxt_sanitize_cdclk(struct
> >> > drm_i915_private *dev_priv)
> >> > * so sanitize this register.
> >> > */
> >> > cdctl = intel_de_read(dev_priv, CDCLK_CTL);
> >> > +expected = bxt_cdclk_ctl(dev_priv, _priv->display.cdclk.hw,
> >> > INVALID_PIPE);
> >> >
> >> > /*
> >> > * Let's ignore the pipe field, since BIOS could have
> >> > configured the
> >> > @@ -2083,28 +2084,7 @@ static void bxt_sanitize_cdclk(struct
> >> > drm_i915_private *dev_priv)
> >> > * (PIPE_NONE).
> >> > */
> >> > cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> >> > -
> >> > -if (DISPLAY_VER(dev_priv) >= 20)
> >> > -expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
> >> > -else
> >> > -expected = skl_cdclk_decimal(cdclk);
> >> > -
> >> > -/* Figure out what CD2X divider we should be using for this
> >> > cdclk */
> >> > -if (HAS_CDCLK_SQUASH(dev_priv))
> >> > -clock = dev_priv->display.cdclk.hw.vco / 2;
> >> > -else
> >> > -clock = dev_priv->display.cdclk.hw.cdclk;
> >> > -
> >> > -expected |= bxt_cdclk_cd2x_div_sel(dev_priv, clock,
> >> > -
> >> > dev_priv->display.cdclk.hw.vco);
> >> > -
> >> > -/*
> >> > - * Disable SSA Precharge when CD clock frequency < 500 MHz,
> >> > - * enable otherwise.
> >> > - */
> >> > -if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
> >> > -dev_priv->display.cdclk.hw.cdclk >= 50)
> >> > -expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> >> > +expected &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> >> >
> >> > if (cdctl == expected)
> >> > /* All well; nothing to sanitize */
> >> > --
> >> > 2.43.0
> >> >
> >>
> >> --
> >> Matt Roper
> >> Graphics Software Engineer
> >> Linux GPU Platform Enablement
> >> Intel Corporation
> >
> >--
> >Matt Roper
> >Graphics Software Engineer
> >Linux GPU Platform Enablement
> >Intel Corporation
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 4/4] drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing
On Thu, Jan 04, 2024 at 03:48:34PM -0800, Matt Roper wrote:
> On Thu, Jan 04, 2024 at 12:21:50AM -0300, Gustavo Sousa wrote:
> > That's the function responsible for deriving that register's value; use
> > it.
> >
> > Signed-off-by: Gustavo Sousa
>
> Reviewed-by: Matt Roper
Forgot to mention...I think it's a bit jarring when the commit message
starts out referring to something in the headline ("That's the
function..."). It's probably a bit better to just re-state the function
name in the commit message again rather than assuming both get read
together.
Matt
>
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 +++---
> > 1 file changed, 3 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fbe9aba41c35..26200ee3e23f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2051,7 +2051,7 @@ static void bxt_set_cdclk(struct drm_i915_private
> > *dev_priv,
> > static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
> > {
> > u32 cdctl, expected;
> > - int cdclk, clock, vco;
> > + int cdclk, vco;
> >
> > intel_update_cdclk(dev_priv);
> > intel_cdclk_dump_config(dev_priv, _priv->display.cdclk.hw, "Current
> > CDCLK");
> > @@ -2076,6 +2076,7 @@ static void bxt_sanitize_cdclk(struct
> > drm_i915_private *dev_priv)
> > * so sanitize this register.
> > */
> > cdctl = intel_de_read(dev_priv, CDCLK_CTL);
> > + expected = bxt_cdclk_ctl(dev_priv, _priv->display.cdclk.hw,
> > INVALID_PIPE);
> >
> > /*
> > * Let's ignore the pipe field, since BIOS could have configured the
> > @@ -2083,28 +2084,7 @@ static void bxt_sanitize_cdclk(struct
> > drm_i915_private *dev_priv)
> > * (PIPE_NONE).
> > */
> > cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> > -
> > - if (DISPLAY_VER(dev_priv) >= 20)
> > - expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
> > - else
> > - expected = skl_cdclk_decimal(cdclk);
> > -
> > - /* Figure out what CD2X divider we should be using for this cdclk */
> > - if (HAS_CDCLK_SQUASH(dev_priv))
> > - clock = dev_priv->display.cdclk.hw.vco / 2;
> > - else
> > - clock = dev_priv->display.cdclk.hw.cdclk;
> > -
> > - expected |= bxt_cdclk_cd2x_div_sel(dev_priv, clock,
> > - dev_priv->display.cdclk.hw.vco);
> > -
> > - /*
> > -* Disable SSA Precharge when CD clock frequency < 500 MHz,
> > -* enable otherwise.
> > -*/
> > - if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
> > - dev_priv->display.cdclk.hw.cdclk >= 50)
> > - expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> > + expected &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> >
> > if (cdctl == expected)
> > /* All well; nothing to sanitize */
> > --
> > 2.43.0
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 4/4] drm/i915/cdclk: Re-use bxt_cdclk_ctl() when sanitizing
On Thu, Jan 04, 2024 at 12:21:50AM -0300, Gustavo Sousa wrote:
> That's the function responsible for deriving that register's value; use
> it.
>
> Signed-off-by: Gustavo Sousa
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 26 +++---
> 1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index fbe9aba41c35..26200ee3e23f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2051,7 +2051,7 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
> {
> u32 cdctl, expected;
> - int cdclk, clock, vco;
> + int cdclk, vco;
>
> intel_update_cdclk(dev_priv);
> intel_cdclk_dump_config(dev_priv, _priv->display.cdclk.hw, "Current
> CDCLK");
> @@ -2076,6 +2076,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
>* so sanitize this register.
>*/
> cdctl = intel_de_read(dev_priv, CDCLK_CTL);
> + expected = bxt_cdclk_ctl(dev_priv, _priv->display.cdclk.hw,
> INVALID_PIPE);
>
> /*
>* Let's ignore the pipe field, since BIOS could have configured the
> @@ -2083,28 +2084,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
>* (PIPE_NONE).
>*/
> cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> -
> - if (DISPLAY_VER(dev_priv) >= 20)
> - expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
> - else
> - expected = skl_cdclk_decimal(cdclk);
> -
> - /* Figure out what CD2X divider we should be using for this cdclk */
> - if (HAS_CDCLK_SQUASH(dev_priv))
> - clock = dev_priv->display.cdclk.hw.vco / 2;
> - else
> - clock = dev_priv->display.cdclk.hw.cdclk;
> -
> - expected |= bxt_cdclk_cd2x_div_sel(dev_priv, clock,
> -dev_priv->display.cdclk.hw.vco);
> -
> - /*
> - * Disable SSA Precharge when CD clock frequency < 500 MHz,
> - * enable otherwise.
> - */
> - if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
> - dev_priv->display.cdclk.hw.cdclk >= 50)
> - expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> + expected &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
>
> if (cdctl == expected)
> /* All well; nothing to sanitize */
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 3/4] drm/i915/cdclk: Reorder bxt_sanitize_cdclk()
On Thu, Jan 04, 2024 at 12:21:49AM -0300, Gustavo Sousa wrote: > Make the sequence of steps more logical by grouping things related to > the check on the value of CDCLK_CTL into a single "block". Also, this > will make an upcoming change replacing that block with a single function > call easier to follow. > > Signed-off-by: Gustavo Sousa Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_cdclk.c | 24 +++--- > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c > b/drivers/gpu/drm/i915/display/intel_cdclk.c > index b9354ad46fee..fbe9aba41c35 100644 > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c > @@ -2060,13 +2060,23 @@ static void bxt_sanitize_cdclk(struct > drm_i915_private *dev_priv) > dev_priv->display.cdclk.hw.cdclk == > dev_priv->display.cdclk.hw.bypass) > goto sanitize; > > - /* DPLL okay; verify the cdclock > - * > + /* Make sure this is a legal cdclk value for the platform */ > + cdclk = bxt_calc_cdclk(dev_priv, dev_priv->display.cdclk.hw.cdclk); > + if (cdclk != dev_priv->display.cdclk.hw.cdclk) > + goto sanitize; > + > + /* Make sure the VCO is correct for the cdclk */ > + vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk); > + if (vco != dev_priv->display.cdclk.hw.vco) > + goto sanitize; > + > + /* >* Some BIOS versions leave an incorrect decimal frequency value and >* set reserved MBZ bits in CDCLK_CTL at least during exiting from S4, >* so sanitize this register. >*/ > cdctl = intel_de_read(dev_priv, CDCLK_CTL); > + > /* >* Let's ignore the pipe field, since BIOS could have configured the >* dividers both synching to an active pipe, or asynchronously > @@ -2074,16 +2084,6 @@ static void bxt_sanitize_cdclk(struct drm_i915_private > *dev_priv) >*/ > cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE); > > - /* Make sure this is a legal cdclk value for the platform */ > - cdclk = bxt_calc_cdclk(dev_priv, dev_priv->display.cdclk.hw.cdclk); > - if (cdclk != dev_priv->display.cdclk.hw.cdclk) > - goto sanitize; > - > - /* Make sure the VCO is correct for the cdclk */ > - vco = bxt_calc_cdclk_pll_vco(dev_priv, cdclk); > - if (vco != dev_priv->display.cdclk.hw.vco) > - goto sanitize; > - > if (DISPLAY_VER(dev_priv) >= 20) > expected = MDCLK_SOURCE_SEL_CDCLK_PLL; > else > -- > 2.43.0 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH 2/4] drm/i915/cdclk: Extract bxt_cdclk_ctl()
On Thu, Jan 04, 2024 at 12:21:48AM -0300, Gustavo Sousa wrote:
> This makes the code better readable and will be used later in
> bxt_sanitize_cdclk().
>
> Signed-off-by: Gustavo Sousa
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 57 +-
> 1 file changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 0012e3171f3f..b9354ad46fee 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1900,15 +1900,47 @@ static bool pll_enable_wa_needed(struct
> drm_i915_private *dev_priv)
> dev_priv->display.cdclk.hw.vco > 0;
> }
>
> +static u32 bxt_cdclk_ctl(struct drm_i915_private *i915,
> + const struct intel_cdclk_config *cdclk_config,
> + enum pipe pipe)
> +{
> + int cdclk = cdclk_config->cdclk;
> + int vco = cdclk_config->vco;
> + int unsquashed_cdclk;
> + u16 waveform;
> + u32 val;
> +
> + waveform = cdclk_squash_waveform(i915, cdclk);
> +
> + unsquashed_cdclk = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
> + cdclk_squash_divider(waveform));
> +
> + val = bxt_cdclk_cd2x_div_sel(i915, unsquashed_cdclk, vco) |
> + bxt_cdclk_cd2x_pipe(i915, pipe);
> +
> + /*
> + * Disable SSA Precharge when CD clock frequency < 500 MHz,
> + * enable otherwise.
> + */
> + if ((IS_GEMINILAKE(i915) || IS_BROXTON(i915)) &&
> + cdclk >= 50)
> + val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> +
> + if (DISPLAY_VER(i915) >= 20)
> + val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
> + else
> + val |= skl_cdclk_decimal(cdclk);
> +
> + return val;
> +}
> +
> static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> {
> int cdclk = cdclk_config->cdclk;
> int vco = cdclk_config->vco;
> - int unsquashed_cdclk;
> u16 waveform;
> - u32 val;
>
> if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
> vco > 0 &&
> !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
> @@ -1925,29 +1957,10 @@ static void _bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
>
> - unsquashed_cdclk = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
> - cdclk_squash_divider(waveform));
> -
> if (HAS_CDCLK_SQUASH(dev_priv))
> dg2_cdclk_squash_program(dev_priv, waveform);
>
> - val = bxt_cdclk_cd2x_div_sel(dev_priv, unsquashed_cdclk, vco) |
> - bxt_cdclk_cd2x_pipe(dev_priv, pipe);
> -
> - /*
> - * Disable SSA Precharge when CD clock frequency < 500 MHz,
> - * enable otherwise.
> - */
> - if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
> - cdclk >= 50)
> - val |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> -
> - if (DISPLAY_VER(dev_priv) >= 20)
> - val |= MDCLK_SOURCE_SEL_CDCLK_PLL;
> - else
> - val |= skl_cdclk_decimal(cdclk);
> -
> - intel_de_write(dev_priv, CDCLK_CTL, val);
> + intel_de_write(dev_priv, CDCLK_CTL, bxt_cdclk_ctl(dev_priv,
> cdclk_config, pipe));
>
> if (pipe != INVALID_PIPE)
> intel_crtc_wait_for_next_vblank(intel_crtc_for_pipe(dev_priv,
> pipe));
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/4] drm/i915/xe2lpd: Update bxt_sanitize_cdclk()
On Thu, Jan 04, 2024 at 12:21:47AM -0300, Gustavo Sousa wrote:
> With Xe2_LPD, there were changes to the way CDCLK_CTL must be
> programmed. Those were reflected on _bxt_set_cdclk() with commit
> 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL"), but
> bxt_sanitize_cdclk() was left out.
>
> This was causing some issues when loading the driver with a pre-existing
> active display configuration: the driver would mistakenly take the
> current value of CDCLK_CTL as wrong and the sanitization would be
> triggered.
>
> In a scenario where the display was already configured with a high
> CDCLKC and had plane(s) enabled, FIFO underrun errors were reported,
> because the current sanitization code selects the minimum possible
> CDCLK.
>
> Fix that by updating bxt_sanitize_cdclk() to match the changes made in
> _bxt_set_cdclk(). Ideally, we would have a common function to derive the
> value for CDCLK_CTL, but that can be done in a future change.
>
> Signed-off-by: Gustavo Sousa
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index c5fecde7afa8..0012e3171f3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2071,7 +2071,10 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> if (vco != dev_priv->display.cdclk.hw.vco)
> goto sanitize;
>
> - expected = skl_cdclk_decimal(cdclk);
> + if (DISPLAY_VER(dev_priv) >= 20)
> + expected = MDCLK_SOURCE_SEL_CDCLK_PLL;
> + else
> + expected = skl_cdclk_decimal(cdclk);
>
> /* Figure out what CD2X divider we should be using for this cdclk */
> if (HAS_CDCLK_SQUASH(dev_priv))
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/5] drm/i915/irq: use DISPLAY_VER instead of GRAPHICS_VER
On Thu, Jan 04, 2024 at 07:43:46PM +0200, Jani Nikula wrote:
> Display code should not care about graphics version.
>
> Signed-off-by: Jani Nikula
For the series:
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index 6964f4b95865..99843883cef7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -1587,7 +1587,7 @@ void ilk_de_irq_postinstall(struct drm_i915_private
> *i915)
> struct intel_uncore *uncore = >uncore;
> u32 display_mask, extra_mask;
>
> - if (GRAPHICS_VER(i915) >= 7) {
> + if (DISPLAY_VER(i915) >= 7) {
> display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE_IVB |
> DE_PCH_EVENT_IVB | DE_AUX_CHANNEL_A_IVB);
> extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [V2] drm/i915: Add workaround 14019877138
On Wed, Jan 03, 2024 at 11:01:11AM +0530, Tejas Upadhyay wrote: > WA 14019877138 needed for Graphics 12.70/71 both Also needed for 12.74 (which is on the mailing list but hasn't landed yet). But this change will automatically cover that too once it lands. You might want to make the prefix "drm/i915/xelpg:" since that's the specific IP that we're adding this for (we already have this workaround for DG2). But otherwise, Reviewed-by: Matt Roper > > V2(Jani): > - Use drm/i915 > > Signed-off-by: Tejas Upadhyay > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 3eacbc50caf8..270b56fc85e2 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -820,6 +820,9 @@ static void xelpg_ctx_workarounds_init(struct > intel_engine_cs *engine, > > /* Wa_18019271663 */ > wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE); > + > + /* Wa_14019877138 */ > + wa_mcr_masked_en(wal, XEHP_PSS_CHICKEN, FD_END_COLLECT); > } > > static void fakewa_disable_nestedbb_mode(struct intel_engine_cs *engine, > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: ✓ Fi.CI.BAT: success for drm/i915/mtl: Add fake PCH for Meteor Lake (rev2)
On Tue, Dec 19, 2023 at 07:46:41PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/mtl: Add fake PCH for Meteor Lake (rev2)
> URL : https://patchwork.freedesktop.org/series/127963/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14045 -> Patchwork_127963v2
>
>
> Summary
> ---
>
> **SUCCESS**
Shards results never showed up on the mailing list, but they've
visible in patchwork; neither of the failures reported there (one
on SNB, one on DG2) are related to this MTL PCH change (the SNB failure
is a lock issue outside the DRM subsystem, and the DG2 failure is a
random timeout on a GT-specific test).
Applied to drm-intel-next. Thanks for the patch.
Matt
>
> No regressions found.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/index.html
>
> Participating hosts (38 -> 37)
> --
>
> Additional (1): fi-pnv-d510
> Missing(2): bat-rpls-2 fi-snb-2520m
>
> Known issues
>
>
> Here are the changes found in Patchwork_127963v2 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271]) +28 other tests
> skip
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>
>
> Build changes
> -
>
> * Linux: CI_DRM_14045 -> Patchwork_127963v2
>
> CI-20190529: 20190529
> CI_DRM_14045: e786d8c6347b8b304e82c6bcebc0d38401792b16 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7648: 5c7b44f13c9c5bc15af0cb2b6a5ea10a8a468ac0 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_127963v2: e786d8c6347b8b304e82c6bcebc0d38401792b16 @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> ### Linux commits
>
> 22a222ed2423 drm/i915/mtl: Add fake PCH for Meteor Lake
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127963v2/index.html
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/guc: Change wa and EU_PERF_CNTL registers to MCR type
On Tue, Jan 02, 2024 at 01:02:31AM +, Shuicheng Lin wrote:
> Some of the wa registers are MCR register, and EU_PERF_CNTL registers
> are MCR register.
> MCR register needs extra process for read/write.
> As normal MMIO register also could work with the MCR register process,
> change all wa registers to MCR type for code simplicity.
>
> Signed-off-by: Shuicheng Lin
> Cc: Matt Roper
> Cc: Umesh Nerlige Ramappa
Reviewed-by: Matt Roper
Tweaked the comment to conform to Linux kernel coding standards, and
applied to drm-intel-gt-next. Thanks for the patch.
At some point we'll need to rework the OA/perf code to use proper
register types for a bunch of their registers (so that we don't need
ugly casts like this), but we can take care of that separately.
Matt
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 63724e17829a..5cbcbe9a4e93 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -377,8 +377,12 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> CCS_MASK(engine->gt))
> ret |= GUC_MMIO_REG_ADD(gt, regset, GEN12_RCU_MODE, true);
>
> + /* some of the WA registers are MCR registers. As it is safe to
> + * use MCR form for non-MCR registers, for code simplicity, all
> + * WA registers are added with MCR form.
> + */
> for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
> - ret |= GUC_MMIO_REG_ADD(gt, regset, wa->reg, wa->masked_reg);
> + ret |= GUC_MCR_REG_ADD(gt, regset, wa->mcr_reg, wa->masked_reg);
>
> /* Be extra paranoid and include all whitelist registers. */
> for (i = 0; i < RING_MAX_NONPRIV_SLOTS; i++)
> @@ -394,13 +398,13 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> ret |= GUC_MMIO_REG_ADD(gt, regset, GEN9_LNCFCMOCS(i),
> false);
>
> if (GRAPHICS_VER(engine->i915) >= 12) {
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL0, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL1, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL2, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL3, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL4, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL5, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL6, false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL0)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL1)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL2)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL3)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL4)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL5)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL6)), false);
> }
>
> return ret ? -1 : 0;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v1 2/3] drm/i915/xelpg: Extend driver code of Xe_LPG to Xe_LPG+
On Thu, Dec 21, 2023 at 08:02:21PM +0530, Haridhar Kalvala wrote:
> From: Harish Chegondi
>
> Xe_LPG+ (IP version 12.74) should take the same general code
> paths as Xe_LPG (versions 12.70 and 12.71).
>
> Xe_LPG+'s workaround list will be handled by the next patch.
>
> Signed-off-by: Harish Chegondi
> Signed-off-by: Haridhar Kalvala
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 4 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 40687806d22a..1ade568ffbfa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1190,7 +1190,8 @@ static int intel_engine_init_tlb_invalidation(struct
> intel_engine_cs *engine)
> num = ARRAY_SIZE(xelpmp_regs);
> }
> } else {
> - if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 71) ||
> + if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 74) ||
> + GRAPHICS_VER_FULL(i915) == IP_VER(12, 71) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 70) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 50) ||
> GRAPHICS_VER_FULL(i915) == IP_VER(12, 55)) {
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 353f93baaca0..25c1023eb5f9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -495,7 +495,7 @@ static unsigned int get_mocs_settings(struct
> drm_i915_private *i915,
> memset(table, 0, sizeof(struct drm_i915_mocs_table));
>
> table->unused_entries_index = I915_MOCS_PTE;
> - if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 71))) {
> + if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 74))) {
> table->size = ARRAY_SIZE(mtl_mocs_table);
> table->table = mtl_mocs_table;
> table->n_entries = MTL_NUM_MOCS_ENTRIES;
> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> b/drivers/gpu/drm/i915/gt/intel_rc6.c
> index 7090e4be29cb..8f4b3c8af09c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> @@ -123,7 +123,7 @@ static void gen11_rc6_enable(struct intel_rc6 *rc6)
>* temporary wa and should be removed after fixing real cause
>* of forcewake timeouts.
>*/
> - 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, 74)))
> pg_enable =
> GEN9_MEDIA_PG_ENABLE |
> GEN11_MEDIA_SAMPLER_PG_ENABLE;
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index db99c2ef66db..990eaa029d9c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -147,7 +147,7 @@ static const char *i915_cache_level_str(struct
> drm_i915_gem_object *obj)
> {
> struct drm_i915_private *i915 = obj_to_i915(obj);
>
> - if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 71))) {
> + if (IS_GFX_GT_IP_RANGE(to_gt(i915), IP_VER(12, 70), IP_VER(12, 74))) {
> switch (obj->pat_index) {
> case 0: return " WB";
> case 1: return " WT";
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/guc: Change wa and EU_PERF_CNTL registers to MCR type
On Wed, Dec 20, 2023 at 12:39:51PM +, Shuicheng Lin wrote:
> Some of the wa registers are MCR register, and EU_PERF_CNTL registers
> are MCR register.
> MCR register needs extra process for read/write.
> As normal MMIO register also could work with the MCR register process,
> change all wa registers to MCR type for code simplicity.
>
> Signed-off-by: Shuicheng Lin
> Cc: Matt Roper
> Cc: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 63724e17829a..61ff4c7e31a6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -378,7 +378,7 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> ret |= GUC_MMIO_REG_ADD(gt, regset, GEN12_RCU_MODE, true);
>
> for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
> - ret |= GUC_MMIO_REG_ADD(gt, regset, wa->reg, wa->masked_reg);
> + ret |= GUC_MCR_REG_ADD(gt, regset, wa->mcr_reg, wa->masked_reg);
I'd add some kind of a comment here, explaining that it's safe to always
use the MCR form here, even though some of the workarounds are touching
non-MCR registers. With a clarifying code comment added,
Reviewed-by: Matt Roper
Matt
>
> /* Be extra paranoid and include all whitelist registers. */
> for (i = 0; i < RING_MAX_NONPRIV_SLOTS; i++)
> @@ -394,13 +394,13 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> ret |= GUC_MMIO_REG_ADD(gt, regset, GEN9_LNCFCMOCS(i),
> false);
>
> if (GRAPHICS_VER(engine->i915) >= 12) {
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL0, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL1, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL2, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL3, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL4, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL5, false);
> - ret |= GUC_MMIO_REG_ADD(gt, regset, EU_PERF_CNTL6, false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL0)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL1)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL2)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL3)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL4)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL5)), false);
> + ret |= GUC_MCR_REG_ADD(gt, regset,
> MCR_REG(i915_mmio_reg_offset(EU_PERF_CNTL6)), false);
> }
>
> return ret ? -1 : 0;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2] drm/i915/mtl: Add fake PCH for Meteor Lake
On Wed, Dec 20, 2023 at 12:22:33AM +0530, Haridhar Kalvala wrote:
> Correct the implementation trying to detect MTL PCH with
> the MTL fake PCH id.
>
> On MTL, both the North Display (NDE) and South Display (SDE) functionality
> reside on the same die (the SoC die in this case), unlike many past
> platforms where the SDE was on a separate PCH die. The code is (badly)
> structured today in a way that assumes the SDE is always on the PCH for
> modern platforms, so on platforms where we don't actually need to identify
> the PCH to figure out how the SDE behaves (i.e., all DG1/2 GPUs as well as
> MTL and LNL),we've been assigning a "fake PCH" as a quickhack that allows
> us to avoid restructuring a bunch of the code.we've been assigning a
> "fake PCH" as a quick hack that allows us to avoid restructuring a bunch
> of the code.
>
> Removed unused macros of LNL amd MTL as well.
>
> v2: Reorder PCH_MTL conditional check (Matt Roper)
> Reverting to PCH_MTL for PICA interrupt(Matt Roper)
>
> Signed-off-by: Haridhar Kalvala
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_backlight.c | 2 +-
> drivers/gpu/drm/i915/display/intel_bios.c| 3 +--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c | 5 +
> drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 6 ++
> drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> drivers/gpu/drm/i915/soc/intel_pch.c | 16
> drivers/gpu/drm/i915/soc/intel_pch.h | 6 +-
> 9 files changed, 19 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 612d4cd9dacb..696ae59874a9 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -1465,7 +1465,7 @@ static bool cnp_backlight_controller_is_valid(struct
> drm_i915_private *i915, int
>
> if (controller == 1 &&
> INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> - INTEL_PCH_TYPE(i915) < PCH_MTP)
> + INTEL_PCH_TYPE(i915) <= PCH_ADP)
> return intel_de_read(i915, SOUTH_CHICKEN1) &
> ICP_SECOND_PPS_IO_SELECT;
>
> return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index aa169b0055e9..0e61e424802e 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2204,8 +2204,7 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8
> vbt_pin)
> if (IS_DGFX(i915))
> return vbt_pin;
>
> - if (INTEL_PCH_TYPE(i915) >= PCH_LNL || HAS_PCH_MTP(i915) ||
> - IS_ALDERLAKE_P(i915)) {
> + if (INTEL_PCH_TYPE(i915) >= PCH_MTL || IS_ALDERLAKE_P(i915)) {
> ddc_pin_map = adlp_ddc_pin_map;
> n_entries = ARRAY_SIZE(adlp_ddc_pin_map);
> } else if (IS_ALDERLAKE_S(i915)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index c985ebb6831a..b251a71092dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3467,15 +3467,15 @@ u32 intel_read_rawclk(struct drm_i915_private
> *dev_priv)
> {
> u32 freq;
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> - freq = dg1_rawclk(dev_priv);
> - else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTL)
> /*
>* MTL always uses a 38.4 MHz rawclk. The bspec tells us
>* "RAWCLK_FREQ defaults to the values for 38.4 and does
>* not need to be programmed."
>*/
> freq = 38400;
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + freq = dg1_rawclk(dev_priv);
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
> freq = cnp_rawclk(dev_priv);
> else if (HAS_PCH_SPLIT(dev_priv))
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index a7d8f3fc98de..6964f4b95865 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -986,7 +986,7 @@ static void gen8_read_and_ack_pch_irqs(struct
> drm_i915_private *i915, u32 *pch_i
>* their flags both in the PICA and SDE IIR.
>*/
> if (*pch_iir & SD
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Wed, Dec 13, 2023 at 04:07:26PM -0800, Matt Roper wrote:
> On Mon, Dec 04, 2023 at 11:13:52AM -0300, Gustavo Sousa wrote:
> > Quoting Gustavo Sousa (2023-12-04 11:04:20-03:00)
> > >Quoting Matt Roper (2023-12-01 20:07:48-03:00)
> > >>On Tue, Nov 28, 2023 at 11:51:43AM +0200, Ville Syrjälä wrote:
> > >>> On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> > >>> > On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> > >>> > > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> > >>> > > > The cdclk tables were introduced with commit 736da8112fee
> > >>> > > > ("drm/i915:
> > >>> > > > Use literal representation of cdclk tables"). It has been almost
> > >>> > > > 4 years
> > >>> > > > and the divider field was not really used yet. Let's remove it.
> > >>> > >
> > >>> > > I think we need to go the other way and actually start using it
> > >>> > > instead
> > >>> > > of (incorrectly) trying to re-derive it from cdclk->vco. The logic
> > >>> > > the
> > >>> > > driver is using today doesn't account for the potential use of
> > >>> > > squashing, which means we program the wrong divider value into
> > >>> > > CDCLK_CTL
> > >>> > > in some cases. I pointed that out during the LNL code reviews a
> > >>> > > couple
> > >>> > > months ago, and I believe Stan is working on fixing that.
> > >>> >
> > >>> > The code should be correct as is, but it does assume that the cd2x
> > >>> > divider is 2 when squashing is used. If that no longer holds then we
> > >>> > have to change something.
> > >>>
> > >>> Something like this should be sufficient to eliminate that
> > >>> assumption.
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > >>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > >>> index 8bb6bab7c8cd..58567d42e725 100644
> > >>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > >>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > >>> @@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct
> > >>> drm_i915_private *dev_priv,
> > >>>
> > >>> waveform = cdclk_squash_waveform(dev_priv, cdclk);
> > >>>
> > >>> -if (waveform)
> > >>> -clock = vco / 2;
> >
> > Ah, one thing I did not mention in my previous message is that, this
> > assignment here means that we were always assuming that the divisor was
> > always 1:
> >
> > x' = vco / 2
> >
> > , meaning that bxt_cdclk_cd2x_div_sel() would do:
> >
> > y' = vco / x' / 2 = 1
> >
>
> I finally got back to looking at this. With Ville's cleanups it's a lot
> clearer and I agree we should be safe to drop the dividers from the
> table.
>
> Reviewed-by: Matt Roper
>
> Sorry for the delay getting back to this.
And applied to drm-intel-next. Thanks for the patch.
Matt
>
>
> Matt
>
> > --
> > Gustavo Sousa
> >
> > >>> -else
> > >>> -clock = cdclk;
> > >>> +clock = DIV_ROUND_CLOSEST(cdclk * 16,
> > >>> cdclk_squash_divider(waveform));
> > >>>
> > >>
> > >>I haven't had time to come back and revisit this (or check your new
> > >>series yet), but when I was reviewing the cdclk stuff a couple months
> > >>ago, my concern was around bxt_cdclk_cd2x_div_sel() which is deriving
> > >>the CD2X divider from the vco and cdclk value. On a platform like DG2,
> > >>we use squashing instead of changes to PLL ratio to hit different cdclk
> > >>values, so the calculation there doesn't seem valid anymore. Am I
> > >>overlooking something?
> > >
> > >I looked at Ville's patches and they seem correct to me - althought I'm
> > >not that experienced and might be missing something as well... Here goes
> > >my rationale:
> > >
> > >Looking at how cdclk works with our hardware, I would say that the
> > >cdclock is defined by:
> > >
> > >cdclk = vco / div / sq_div / 2
> > >
> > >, with
Re: [PATCH] drm/i915/guc: Add MCR type check for wa registers
On Mon, Dec 18, 2023 at 11:46:44AM +, Shuicheng Lin wrote:
> Some of the wa registers are MCR registers, which have different
> read/write process with normal MMIO registers.
> Add function intel_gt_is_mcr_reg to check whether it is mcr register
> or not.
>
> Signed-off-by: Shuicheng Lin
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 27 ++
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 2 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 6 -
> 3 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index e253750a51c5..b3ee9d152dbe 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -81,6 +81,11 @@ static const struct intel_mmio_range
> dg2_lncf_steering_table[] = {
> {},
> };
>
> +static const struct intel_mmio_range dg2_dss_steering_table[] = {
> + { 0x00E400, 0x00E7FF },
> + {},
> +};
This is incomplete. There are a _lot_ more DSS MCR ranges than this.
> +
> /*
> * We have several types of MCR registers on PVC where steering to (0,0)
> * will always provide us with a non-terminated value. We'll stick them
> @@ -190,6 +195,7 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> } else if (IS_DG2(i915)) {
> gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
> gt->steering_table[LNCF] = dg2_lncf_steering_table;
> + gt->steering_table[DSS] = dg2_dss_steering_table;
Why are you making this change only on DG2? There are DSS steering
ranges that we've been implicitly steering on many platforms. Switching
to explicit steering is something that should probably happen on all
platforms or no platforms.
> /*
>* No need to hook up the GAM table since it has a dedicated
>* steering control register on DG2 and can use implicit
> @@ -715,6 +721,27 @@ void intel_gt_mcr_get_nonterminated_steering(struct
> intel_gt *gt,
> *instance = gt->default_steering.instanceid;
> }
>
> +/*
> + * intel_gt_is_mcr_reg - check whether it is a mcr register or not
> + * @gt: GT structure
> + * @reg: the register to check
> + *
> + * Returns true if @reg belong to a register range of any steering type,
> + * otherwise, return false.
> + */
> +bool intel_gt_is_mcr_reg(struct intel_gt *gt, i915_reg_t reg)
> +{
> + int type;
> + i915_mcr_reg_t mcr_reg = {.reg = reg.reg};
> +
> + for (type = 0; type < NUM_STEERING_TYPES; type++) {
> + if (reg_needs_read_steering(gt, mcr_reg, type)) {
> + return true;
> + }
> + }
> + return false;
> +}
We don't need this function; see below.
> +
> /**
> * intel_gt_mcr_read_any_fw - reads one instance of an MCR register
> * @gt: GT structure
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> index 01ac565a56a4..1ac5e6e2814e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.h
> @@ -30,6 +30,8 @@ void intel_gt_mcr_multicast_write_fw(struct intel_gt *gt,
> u32 intel_gt_mcr_multicast_rmw(struct intel_gt *gt, i915_mcr_reg_t reg,
> u32 clear, u32 set);
>
> +bool intel_gt_is_mcr_reg(struct intel_gt *gt, i915_reg_t reg);
> +
> void intel_gt_mcr_get_nonterminated_steering(struct intel_gt *gt,
>i915_mcr_reg_t reg,
>u8 *group, u8 *instance);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 63724e17829a..6c3910c9dce5 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -377,8 +377,12 @@ static int guc_mmio_regset_init(struct temp_regset
> *regset,
> CCS_MASK(engine->gt))
> ret |= GUC_MMIO_REG_ADD(gt, regset, GEN12_RCU_MODE, true);
>
> + /* Check whether there is MCR register or not */
> for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
> - ret |= GUC_MMIO_REG_ADD(gt, regset, wa->reg, wa->masked_reg);
> + if (intel_gt_is_mcr_reg(gt, wa->reg))
The proper condition here would be wa->is_mcr. Of course that assumes
that you actually define all of the workarounds appropriately (using the
MCR variants when appropriate) and also the registers properly (using
MCR_REG() instead of _MMIO).
Converting all of the implicit steering over to explicit steering is a
lot of invasive changes to the code, and
Re: [PATCH] drm/i915/mtl: Add fake PCH for Meteor Lake
ed guess as to which PCH is really there.
>*/
>
> - if (IS_METEORLAKE(dev_priv))
> - id = INTEL_PCH_MTP_DEVICE_ID_TYPE;
> - else if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
> + if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
> id = INTEL_PCH_ADP_DEVICE_ID_TYPE;
> else if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv))
> id = INTEL_PCH_TGP_DEVICE_ID_TYPE;
> @@ -225,6 +218,13 @@ void intel_detect_pch(struct drm_i915_private *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 20) {
> dev_priv->pch_type = PCH_LNL;
> return;
> + } else if (IS_METEORLAKE(dev_priv)) {
> + /*
> + * Both north display and south display are on the SoC die.
> + * The real PCH is uninvolved in display.
> + */
> + dev_priv->pch_type = PCH_MTL;
> + return;
> } else if (IS_DG2(dev_priv)) {
> dev_priv->pch_type = PCH_DG2;
> return;
> diff --git a/drivers/gpu/drm/i915/soc/intel_pch.h
> b/drivers/gpu/drm/i915/soc/intel_pch.h
> index 1b03ea60a7a8..89e89ede265d 100644
> --- a/drivers/gpu/drm/i915/soc/intel_pch.h
> +++ b/drivers/gpu/drm/i915/soc/intel_pch.h
> @@ -25,11 +25,11 @@ enum intel_pch {
> PCH_ICP,/* Ice Lake/Jasper Lake PCH */
> PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
> PCH_ADP,/* Alder Lake PCH */
> - PCH_MTP,/* Meteor Lake PCH */
>
> /* Fake PCHs, functionality handled on the same PCI dev */
> PCH_DG1 = 1024,
> PCH_DG2,
> + PCH_MTL,
> PCH_LNL,
> };
>
> @@ -59,16 +59,12 @@ enum intel_pch {
> #define INTEL_PCH_ADP2_DEVICE_ID_TYPE0x5180
> #define INTEL_PCH_ADP3_DEVICE_ID_TYPE0x7A00
> #define INTEL_PCH_ADP4_DEVICE_ID_TYPE0x5480
> -#define INTEL_PCH_MTP_DEVICE_ID_TYPE 0x7E00
> -#define INTEL_PCH_MTP2_DEVICE_ID_TYPE0xAE00
> #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35 has
> 2918 */
>
> #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
> #define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
> -#define HAS_PCH_LNL(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_LNL)
> -#define HAS_PCH_MTP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_MTP)
> #define HAS_PCH_DG2(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG2)
> #define HAS_PCH_ADP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
> #define HAS_PCH_DG1(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915/xelpg: Add fake PCH for xelpg
> (INTEL_PCH_TYPE(dev_priv) == PCH_LNL) > -#define HAS_PCH_MTP(dev_priv) > (INTEL_PCH_TYPE(dev_priv) == PCH_MTP) > +#define HAS_PCH_MTP(dev_priv) > (INTEL_PCH_TYPE(dev_priv) == PCH_MTL) Since this is a fake PCH, this macro should be HAS_PCH_MTL() to match the naming of the LNL fake PCH. It looks like this macro only gets used in a single place in map_ddc_pin(), and that's another case where the MTL + LNL conditions can be consolidated now that the PCH enum has been reordered. So maybe you can just remove this macro entirely once you make that change. In fact, it doesn't look like HAS_PCH_LNL is used anywhere today either, so a follow-up patch to remove that unused definition might be a good idea as well. Matt > #define HAS_PCH_DG2(dev_priv) > (INTEL_PCH_TYPE(dev_priv) == PCH_DG2) > #define HAS_PCH_ADP(dev_priv) > (INTEL_PCH_TYPE(dev_priv) == PCH_ADP) > #define HAS_PCH_DG1(dev_priv) > (INTEL_PCH_TYPE(dev_priv) == PCH_DG1) > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH] drm/i915/xelpg: Add fake PCH for xelpg
Oh, and one more thing I forgot to mention before hitting send...the
title for this patch doesn't make sense. Xe_LPG is the graphics IP used
by MTL; that's completely unrelated to the display IP (which is
Xe_LPD+).
Since we're assigning the fake PCH value based off the platform
(IS_METEORLAKE) rather than the display version, this should just be
"drm/i915/mtl: Add fake PCH for Meteor Lake"
Matt
On Mon, Dec 18, 2023 at 07:52:12AM -0800, Matt Roper wrote:
> On Mon, Dec 18, 2023 at 04:33:13PM +0530, Haridhar Kalvala wrote:
> > Correct the implementation trying to detect MTL PCH with
> > the MTL fake PCH id.
> >
> > On MTL, both the North Display (NDE) and South Display (SDE) functionality
> > reside on the same die (the SoC die in this case), unlike many past
> > platforms where the SDE was on a separate PCH die. The code is (badly)
> > structured today in a way that assumes the SDE is always on the PCH for
> > modern platforms, so on platforms where we don't actually need to identify
> > the PCH to figure out how the SDE behaves (i.e., all DG1/2 GPUs as well as
> > MTL and LNL),we've been assigning a "fake PCH" as a quickhack that allows
> > us to avoid restructuring a bunch of the code.we've been assigning a
> > "fake PCH" as a quick hack that allows us to avoid restructuring a bunch
> > of the code.
> >
> > Signed-off-by: Haridhar Kalvala
> > ---
> > drivers/gpu/drm/i915/display/intel_backlight.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_gmbus.c | 6 ++
> > drivers/gpu/drm/i915/display/intel_hotplug_irq.c | 7 +++
> > drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> > drivers/gpu/drm/i915/soc/intel_pch.c | 12 +++-
> > drivers/gpu/drm/i915/soc/intel_pch.h | 4 ++--
> > 8 files changed, 18 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_backlight.c
> > index 612d4cd9dacb..696ae59874a9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> > @@ -1465,7 +1465,7 @@ static bool cnp_backlight_controller_is_valid(struct
> > drm_i915_private *i915, int
> >
> > if (controller == 1 &&
> > INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> > - INTEL_PCH_TYPE(i915) < PCH_MTP)
> > + INTEL_PCH_TYPE(i915) <= PCH_ADP)
> > return intel_de_read(i915, SOUTH_CHICKEN1) &
> > ICP_SECOND_PPS_IO_SELECT;
> >
> > return true;
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index c985ebb6831a..2e6e55d3e885 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -3469,7 +3469,7 @@ u32 intel_read_rawclk(struct drm_i915_private
> > *dev_priv)
> >
> > if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> > freq = dg1_rawclk(dev_priv);
> > - else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP)
> > + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTL)
> > /*
> > * MTL always uses a 38.4 MHz rawclk. The bspec tells us
> > * "RAWCLK_FREQ defaults to the values for 38.4 and does
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> > b/drivers/gpu/drm/i915/display/intel_display_irq.c
> > index a7d8f3fc98de..e318e24d1efd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> > @@ -986,7 +986,7 @@ static void gen8_read_and_ack_pch_irqs(struct
> > drm_i915_private *i915, u32 *pch_i
> > * their flags both in the PICA and SDE IIR.
> > */
> > if (*pch_iir & SDE_PICAINTERRUPT) {
> > - drm_WARN_ON(>drm, INTEL_PCH_TYPE(i915) < PCH_MTP);
> > + drm_WARN_ON(>drm, INTEL_PCH_TYPE(i915) <= PCH_ADP);
> >
> > pica_ier = intel_de_rmw(i915, PICAINTERRUPT_IER, ~0, 0);
> > *pica_iir = intel_de_read(i915, PICAINTERRUPT_IIR);
> > diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> > b/drivers/gpu/drm/i915/display/intel_gmbus.c
> > index 40d7b6f3f489..2d9c740ba17e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> > +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> > @@ -155,7 +155,8 @@ static c
Re: [PATCH v3 1/2] drm/i915/display: Add support for darskscreen detection
_types.h
> index 3600497ff512..d441e08fef58 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -49,6 +49,7 @@
> #include "i915_vma.h"
> #include "i915_vma_types.h"
> #include "intel_bios.h"
> +#include "intel_darkscreen.h"
> #include "intel_display.h"
> #include "intel_display_limits.h"
> #include "intel_display_power.h"
> @@ -1539,6 +1540,7 @@ struct intel_crtc {
>
> #ifdef CONFIG_DEBUG_FS
> struct intel_pipe_crc pipe_crc;
> + struct intel_darkscreen dark_screen;
> #endif
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c203dcfd6c7b..4e273c0ac801 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2097,6 +2097,14 @@
> #define TRANS_PUSH_EN REG_BIT(31)
> #define TRANS_PUSH_SENDREG_BIT(30)
>
> +#define _DARK_SCREEN_PIPE_A 0x60120
> +#define DARK_SCREEN(trans) _MMIO_TRANS2(trans, _DARK_SCREEN_PIPE_A)
> +#define DARK_SCREEN_ENABLE REG_BIT(31)
> +#define DARK_SCREEN_DETECT REG_BIT(29)
> +#define DARK_SCREEN_DONE REG_BIT(28)
> +#define DARK_SCREEN_COMPARE_MASK REG_GENMASK(9, 0)
> +#define DARK_SCREEN_COMPARE_VAL(x)
> REG_FIELD_PREP(DARK_SCREEN_COMPARE_MASK, (x))
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index fe659a97001c..ff533733245c 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -176,6 +176,7 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
> i915-display/intel_crtc_state_dump.o \
> i915-display/intel_cursor.o \
> i915-display/intel_cx0_phy.o \
> + i915-display/intel_darkscreen.o \
> i915-display/intel_ddi.o \
> i915-display/intel_ddi_buf_trans.o \
> i915-display/intel_display.o \
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915: Add Wa_14019877138
On Wed, Dec 13, 2023 at 12:16:12PM +0530, Haridhar Kalvala wrote: > Enable Force Dispatch Ends Collection for DG2. > > BSpec: 46001 > > Signed-off-by: Haridhar Kalvala > Reviewed-by: Matt Roper Applied to drm-intel-gt-next. Thanks for the patch. Matt > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 9de41703fae5..50962cfd1353 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -469,6 +469,9 @@ > #define XEHP_PSS_MODE2 MCR_REG(0x703c) > #define SCOREBOARD_STALL_FLUSH_CONTROL REG_BIT(5) > > +#define XEHP_PSS_CHICKEN MCR_REG(0x7044) > +#define FD_END_COLLECT REG_BIT(5) > + > #define GEN7_SC_INSTDONE _MMIO(0x7100) > #define GEN12_SC_INSTDONE_EXTRA _MMIO(0x7104) > #define GEN12_SC_INSTDONE_EXTRA2 _MMIO(0x7108) > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 4cbf9e512645..3eacbc50caf8 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -777,6 +777,9 @@ static void dg2_ctx_workarounds_init(struct > intel_engine_cs *engine, > > /* Wa_18019271663:dg2 */ > wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE); > + > + /* Wa_14019877138:dg2 */ > + wa_mcr_masked_en(wal, XEHP_PSS_CHICKEN, FD_END_COLLECT); > } > > static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine, > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH] drm/i915/guc: Change wa registers to MCR type
On Thu, Dec 14, 2023 at 07:26:29AM +, Shuicheng Lin wrote: > some of the wa registers are MCR registers, which has different > read/write process with normal MMIO registers. As the MCR process > also work for normal MMIO registers, change all wa registers to > MCR process for simplicity. > > Signed-off-by: Shuicheng Lin > Cc: Matt Roper > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > index 63724e17829a..7409d3255cb0 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > @@ -377,8 +377,12 @@ static int guc_mmio_regset_init(struct temp_regset > *regset, > CCS_MASK(engine->gt)) > ret |= GUC_MMIO_REG_ADD(gt, regset, GEN12_RCU_MODE, true); > > + /* some of the wa registers are MCR regiters */ > for (i = 0, wa = wal->list; i < wal->count; i++, wa++) > - ret |= GUC_MMIO_REG_ADD(gt, regset, wa->reg, wa->masked_reg); > + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50)) The condition here doesn't really make sense. MCR registers have existed since gen8, so why are we doing this on graphics version 12.50 and higher? It would be better to just make this conditional on whether the register is actually an MCR register (and needs special steering) or not. Matt > + ret |= GUC_MCR_REG_ADD(gt, regset, wa->mcr_reg, > wa->masked_reg); > + else > + ret |= GUC_MMIO_REG_ADD(gt, regset, wa->reg, > wa->masked_reg); > > /* Be extra paranoid and include all whitelist registers. */ > for (i = 0; i < RING_MAX_NONPRIV_SLOTS; i++) > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Remove divider field from tables
On Mon, Dec 04, 2023 at 11:13:52AM -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2023-12-04 11:04:20-03:00)
> >Quoting Matt Roper (2023-12-01 20:07:48-03:00)
> >>On Tue, Nov 28, 2023 at 11:51:43AM +0200, Ville Syrjälä wrote:
> >>> On Tue, Nov 28, 2023 at 10:43:36AM +0200, Ville Syrjälä wrote:
> >>> > On Mon, Nov 27, 2023 at 08:21:46AM -0800, Matt Roper wrote:
> >>> > > On Fri, Nov 24, 2023 at 05:55:23PM -0300, Gustavo Sousa wrote:
> >>> > > > The cdclk tables were introduced with commit 736da8112fee
> >>> > > > ("drm/i915:
> >>> > > > Use literal representation of cdclk tables"). It has been almost 4
> >>> > > > years
> >>> > > > and the divider field was not really used yet. Let's remove it.
> >>> > >
> >>> > > I think we need to go the other way and actually start using it
> >>> > > instead
> >>> > > of (incorrectly) trying to re-derive it from cdclk->vco. The logic
> >>> > > the
> >>> > > driver is using today doesn't account for the potential use of
> >>> > > squashing, which means we program the wrong divider value into
> >>> > > CDCLK_CTL
> >>> > > in some cases. I pointed that out during the LNL code reviews a
> >>> > > couple
> >>> > > months ago, and I believe Stan is working on fixing that.
> >>> >
> >>> > The code should be correct as is, but it does assume that the cd2x
> >>> > divider is 2 when squashing is used. If that no longer holds then we
> >>> > have to change something.
> >>>
> >>> Something like this should be sufficient to eliminate that
> >>> assumption.
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >>> index 8bb6bab7c8cd..58567d42e725 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >>> @@ -1897,10 +1897,7 @@ static void _bxt_set_cdclk(struct drm_i915_private
> >>> *dev_priv,
> >>>
> >>> waveform = cdclk_squash_waveform(dev_priv, cdclk);
> >>>
> >>> -if (waveform)
> >>> -clock = vco / 2;
>
> Ah, one thing I did not mention in my previous message is that, this
> assignment here means that we were always assuming that the divisor was
> always 1:
>
> x' = vco / 2
>
> , meaning that bxt_cdclk_cd2x_div_sel() would do:
>
> y' = vco / x' / 2 = 1
>
I finally got back to looking at this. With Ville's cleanups it's a lot
clearer and I agree we should be safe to drop the dividers from the
table.
Reviewed-by: Matt Roper
Sorry for the delay getting back to this.
Matt
> --
> Gustavo Sousa
>
> >>> -else
> >>> -clock = cdclk;
> >>> +clock = DIV_ROUND_CLOSEST(cdclk * 16,
> >>> cdclk_squash_divider(waveform));
> >>>
> >>
> >>I haven't had time to come back and revisit this (or check your new
> >>series yet), but when I was reviewing the cdclk stuff a couple months
> >>ago, my concern was around bxt_cdclk_cd2x_div_sel() which is deriving
> >>the CD2X divider from the vco and cdclk value. On a platform like DG2,
> >>we use squashing instead of changes to PLL ratio to hit different cdclk
> >>values, so the calculation there doesn't seem valid anymore. Am I
> >>overlooking something?
> >
> >I looked at Ville's patches and they seem correct to me - althought I'm
> >not that experienced and might be missing something as well... Here goes
> >my rationale:
> >
> >Looking at how cdclk works with our hardware, I would say that the
> >cdclock is defined by:
> >
> >cdclk = vco / div / sq_div / 2
> >
> >, with: vco being the output of the CD2X PLL; "div", the CD2X divider;
> >"sq_div", the divider that is derived from the squash wave (16 / "sqash
> >wave 1's count"); and 2, the final division that is done at the end.
> >
> >The DIV_ROUND_CLOSEST() operation suggested above is equivalent to
> >doing:
> >
> >x = cdclk * sq_div = vco / div / 2
> >
> >Meaning that x is the "unsquashed cdclk". From this point, what
> >bxt_cdclk_cd2x_div_sel() is doing is:
> >
> >y = vco / x / 2
>
Re: [Intel-gfx] [PATCH] drm/i915: Add Wa_14019877138
On Mon, Dec 11, 2023 at 05:08:48PM +0530, Kalvala, Haridhar wrote: > > On 12/6/2023 1:54 AM, Matt Roper wrote: > > On Tue, Dec 05, 2023 at 02:41:05PM +0530, Haridhar Kalvala wrote: > > > Enable Force Dispatch Ends Collection for DG2. > > > > > > BSpec: 46001 > > > > > > Signed-off-by: Haridhar Kalvala > > > --- > > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > > > index 9de41703fae5..85ba62639807 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > > > @@ -469,6 +469,9 @@ > > > #define XEHP_PSS_MODE2 MCR_REG(0x703c) > > > #define SCOREBOARD_STALL_FLUSH_CONTROLREG_BIT(5) > > > +#define XEHP_PSS_CHICKENMCR_REG(0x7044) > > > +#defineFD_END_COLLECTREG_BIT(5) > > Looks like the whitespace between '#define' and the names isn't correct > > here. > > > > Aside from that, > > > > Reviewed-by: Matt Roper > > > Hi Matt, > > Thank you. I verified with checkpatch and it did not shown any warning. I > will check again. Checkpatch won't care since this isn't related to kernel coding style, just to consistency within the header. You should make these definitions use the same whitespace format as all the other ones in the file. Matt > > Thanks & regards, > > Haridhar Kalvala > > > > + > > > #define GEN7_SC_INSTDONE_MMIO(0x7100) > > > #define GEN12_SC_INSTDONE_EXTRA _MMIO(0x7104) > > > #define GEN12_SC_INSTDONE_EXTRA2_MMIO(0x7108) > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > > index 4cbf9e512645..3eacbc50caf8 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > > @@ -777,6 +777,9 @@ static void dg2_ctx_workarounds_init(struct > > > intel_engine_cs *engine, > > > /* Wa_18019271663:dg2 */ > > > wa_masked_en(wal, CACHE_MODE_1, > > > MSAA_OPTIMIZATION_REDUC_DISABLE); > > > + > > > + /* Wa_14019877138:dg2 */ > > > + wa_mcr_masked_en(wal, XEHP_PSS_CHICKEN, FD_END_COLLECT); > > > } > > > static void xelpg_ctx_gt_tuning_init(struct intel_engine_cs *engine, > > > -- > > > 2.25.1 > > > > -- > Regards, > Haridhar Kalvala > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [PATCH 2/2] drm/i915/display: Print PICA version
On Fri, Dec 08, 2023 at 01:46:09PM -0600, Lucas De Marchi wrote:
> On Fri, Dec 08, 2023 at 10:02:53AM -0800, Matt Roper wrote:
> > On Fri, Dec 08, 2023 at 06:31:37AM -0800, Lucas De Marchi wrote:
> > > The PICA_DEVICE_ID follows the same format as other GMD_ID registers
> > > (graphics, display and media). Currently the only use for it is
> > > informational for developers while checking the differences between
> > > machines with the same platform. Print the raw number as there's no need
> > > for the driver to check any of the fields.
> > >
> > > In future this may change, but then the IP version in
> > > struct intel_display_runtime_info will need some refactor to allow
> > > keeping both the display engine and PICA versions.
> > >
> > > Lastly, keeping the PICA version around in the display runtime info
> > > matches its current use. If that changes in future, then it may need
> > > to be moved to the device info.
> > >
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display_device.c | 5 +
> > > drivers/gpu/drm/i915/display/intel_display_device.h | 2 ++
> > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > 3 files changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> > > b/drivers/gpu/drm/i915/display/intel_display_device.c
> > > index 5d1084a98b93..d9d1be008e4c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> > > @@ -956,6 +956,9 @@ static void
> > > __intel_display_device_info_runtime_init(struct drm_i915_private *i9
> > > BUILD_BUG_ON(BITS_PER_TYPE(display_runtime->cpu_transcoder_mask) <
> > > I915_MAX_TRANSCODERS);
> > > BUILD_BUG_ON(BITS_PER_TYPE(display_runtime->port_mask) <
> > > I915_MAX_PORTS);
> > >
> > > + if (HAS_GMD_ID(i915))
> > > + display_runtime->pica_id = intel_de_read(i915, PICA_DEVICE_ID);
> > > +
> > > /* This covers both ULT and ULX */
> > > if (IS_HASWELL_ULT(i915) || IS_BROADWELL_ULT(i915))
> > > display_runtime->port_mask &= ~BIT(PORT_D);
> > > @@ -1124,6 +1127,8 @@ void intel_display_device_info_print(const struct
> > > intel_display_device_info *inf
> > > {
> > > drm_printf(p, "display version: %u.%02u.%02u\n",
> > > runtime->ip.ver, runtime->ip.rel, runtime->ip.step);
> > > + if (runtime->pica_id)
> > > + drm_printf(p, "PICA version: %#08x\n", runtime->pica_id);
> >
> > The actual, expected PICA version number on most (all?) MTL devices will
> > be 0.0. Should we make the condition here HAS_GMD_ID(i915) instead so
> > that we print the value whenever we read it? That will also help us
> > notice if the PICA register is incorrectly 0 on LNL or later platforms
> > where it should have been non-zero.
>
> it seems intel_display_device_info_print() was specially crafted so we
> don't have the i915/xe pointer and instead only operate on the info.
> Yeah, we can get back to i915/xe, but I'm not sure about doing that.
>
> What if we initialize it with U32_MAX and check for it here. I think it
> would take a long time before that becomes invalid.
>
> Another option is not to bother with the additional message in platforms
> without it, and just print it unconditionally, like patch 1 does for the
> rel/step.
>
> Thoughts?
Hmm. Maybe just printing it unconditionally would be fine. Or just
leaving it as you have here and only printing non-zero values is
probably fine too. Either way,
Reviewed-by: Matt Roper
>
> Lucas De Marchi
>
> >
> >
> > Matt
> >
> > >
> > > #define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name,
> > > str_yes_no(info->name))
> > > DEV_INFO_DISPLAY_FOR_EACH_FLAG(PRINT_FLAG);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> > > b/drivers/gpu/drm/i915/display/intel_display_device.h
> > > index 79e9f1c3e241..f8a2ada1a4ec 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> > > @@ -123,6 +123,8 @@ struct intel_display_runtime_info {
> > >
> > > u8 fbc_mask;
> > >
> > > + u32 pica_id;
> > > +
> > > bool has_hdcp;
> >
Re: [PATCH 2/2] drm/i915/display: Print PICA version
On Fri, Dec 08, 2023 at 06:31:37AM -0800, Lucas De Marchi wrote:
> The PICA_DEVICE_ID follows the same format as other GMD_ID registers
> (graphics, display and media). Currently the only use for it is
> informational for developers while checking the differences between
> machines with the same platform. Print the raw number as there's no need
> for the driver to check any of the fields.
>
> In future this may change, but then the IP version in
> struct intel_display_runtime_info will need some refactor to allow
> keeping both the display engine and PICA versions.
>
> Lastly, keeping the PICA version around in the display runtime info
> matches its current use. If that changes in future, then it may need
> to be moved to the device info.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 5 +
> drivers/gpu/drm/i915/display/intel_display_device.h | 2 ++
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 5d1084a98b93..d9d1be008e4c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -956,6 +956,9 @@ static void
> __intel_display_device_info_runtime_init(struct drm_i915_private *i9
> BUILD_BUG_ON(BITS_PER_TYPE(display_runtime->cpu_transcoder_mask) <
> I915_MAX_TRANSCODERS);
> BUILD_BUG_ON(BITS_PER_TYPE(display_runtime->port_mask) <
> I915_MAX_PORTS);
>
> + if (HAS_GMD_ID(i915))
> + display_runtime->pica_id = intel_de_read(i915, PICA_DEVICE_ID);
> +
> /* This covers both ULT and ULX */
> if (IS_HASWELL_ULT(i915) || IS_BROADWELL_ULT(i915))
> display_runtime->port_mask &= ~BIT(PORT_D);
> @@ -1124,6 +1127,8 @@ void intel_display_device_info_print(const struct
> intel_display_device_info *inf
> {
> drm_printf(p, "display version: %u.%02u.%02u\n",
> runtime->ip.ver, runtime->ip.rel, runtime->ip.step);
> + if (runtime->pica_id)
> + drm_printf(p, "PICA version: %#08x\n", runtime->pica_id);
The actual, expected PICA version number on most (all?) MTL devices will
be 0.0. Should we make the condition here HAS_GMD_ID(i915) instead so
that we print the value whenever we read it? That will also help us
notice if the PICA register is incorrectly 0 on LNL or later platforms
where it should have been non-zero.
Matt
>
> #define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name,
> str_yes_no(info->name))
> DEV_INFO_DISPLAY_FOR_EACH_FLAG(PRINT_FLAG);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 79e9f1c3e241..f8a2ada1a4ec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -123,6 +123,8 @@ struct intel_display_runtime_info {
>
> u8 fbc_mask;
>
> + u32 pica_id;
> +
> bool has_hdcp;
> bool has_dmc;
> bool has_dsc;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 27dc903f0553..9d70635508ae 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6362,6 +6362,8 @@ enum skl_power_gate {
> #define TCSS_DDI_STATUS_HPD_LIVE_STATUS_TBT REG_BIT(1)
> #define TCSS_DDI_STATUS_HPD_LIVE_STATUS_ALT REG_BIT(0)
>
> +#define PICA_DEVICE_ID _MMIO(0x16fe00)
> +
> #define PRIMARY_SPI_TRIGGER _MMIO(0x102040)
> #define PRIMARY_SPI_ADDRESS _MMIO(0x102080)
> #define PRIMARY_SPI_REGIONID _MMIO(0x102084)
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH 1/2] drm/i915/display: Also print raw step number
On Fri, Dec 08, 2023 at 06:31:36AM -0800, Lucas De Marchi wrote:
> GMD_ID is already parsed down to the step. Don't omit that information
> in the display engine debug info. This helps to double check the
> stepping is parsed correctly.
>
> For earlier platforms, it will start printing the entire version too
> (which should be 0), as a rel == 0 doesn't mean it doesn't have GMD_ID.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 0b522c6a8d6f..5d1084a98b93 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -1122,13 +1122,8 @@ void intel_display_device_info_print(const struct
> intel_display_device_info *inf
>const struct intel_display_runtime_info
> *runtime,
>struct drm_printer *p)
> {
> - if (runtime->ip.rel)
> - drm_printf(p, "display version: %u.%02u\n",
> -runtime->ip.ver,
> -runtime->ip.rel);
> - else
> - drm_printf(p, "display version: %u\n",
> -runtime->ip.ver);
> + drm_printf(p, "display version: %u.%02u.%02u\n",
> +runtime->ip.ver, runtime->ip.rel, runtime->ip.step);
>
> #define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name,
> str_yes_no(info->name))
> DEV_INFO_DISPLAY_FOR_EACH_FLAG(PRINT_FLAG);
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/i915: fix display ver 12-13 fault error handling
On Fri, Dec 08, 2023 at 01:20:08PM +0200, Jani Nikula wrote:
> Unless I'm completely misreading the bspec, there are no defined bits
> for plane gtt fault errors in DE PIPE IIR for a display versions
> 12-14. This would explain why DG2 in the linked bug is getting thousands
> of fault errors.
I think you might be misreading the spec? On TGL, bits 7-11 are listed
as plane1-4+cursor fault status, and bits 20-22 are listed as plane 5-7
fault status. Bits 7-11 are tagged with a REMOVEDBY tag that eventually
drops them for MTL onward, and bits 20-22 are tagged with a REMOVEDBY
tag that drops them for RKL onward (which makes sense because those
extra planes stopped existing at that point).
Maybe the bspec's way of displaying things is what's causing the
confusion? When you see
REMOVEDBY()
[ Foo, Bar, Baz ]
The "Foo, Bar, Baz" platform list is the *remaining* list of platforms
after the removal is taken into account, not the platforms actually
being removed. You can hover over the REMOVEDBY link to see the actual
platforms being removed and a link to the change record for that.
Matt
>
> Bspec: 50335
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769
> Fixes: 99e2d8bcb887 ("drm/i915/rkl: Limit number of universal planes to 5")
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Cc: # v5.9+
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 4 +++-
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index f8ed53f30b2e..7bede5b56286 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -834,7 +834,9 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private
> *dev_priv)
>
> static u32 gen8_de_pipe_fault_mask(struct drm_i915_private *dev_priv)
> {
> - if (DISPLAY_VER(dev_priv) >= 13 || HAS_D12_PLANE_MINIMIZATION(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 14)
> + return MTL_DE_PIPE_IRQ_FAULT_ERRORS;
> + else if (DISPLAY_VER(dev_priv) >= 12)
> return RKL_DE_PIPE_IRQ_FAULT_ERRORS;
> else if (DISPLAY_VER(dev_priv) >= 11)
> return GEN11_DE_PIPE_IRQ_FAULT_ERRORS;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 27dc903f0553..fcf980694cb4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4354,7 +4354,8 @@
>GEN11_PIPE_PLANE7_FAULT | \
>GEN11_PIPE_PLANE6_FAULT | \
>GEN11_PIPE_PLANE5_FAULT)
> -#define RKL_DE_PIPE_IRQ_FAULT_ERRORS \
> +#define RKL_DE_PIPE_IRQ_FAULT_ERRORS 0
> +#define MTL_DE_PIPE_IRQ_FAULT_ERRORS \
> (GEN9_DE_PIPE_IRQ_FAULT_ERRORS | \
>GEN11_PIPE_PLANE5_FAULT)
>
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
