o emulate the behavior of the timeline
> >> anyway.
> >>
> >> Signed-off-by: Fei Yang
> >
> > It looks like there might be an indentation mistake on the second line
> > of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
> > w
ks like there might be an indentation mistake on the second line
of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
while applying; no need to re-send.
Reviewed-by: Matt Roper
Is there an FDO issue # for the random failures thar were being seen?
If so, we should
tatic void dg1_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> /* Wa_22010493298 */
> wa_masked_en(wal, HIZ_CHICKEN,
>DG1_HZ_READ_SUPPRESSION_OPTIMIZATION_DISABLE);
> +
> + /* Wa_1806527549 */
> + wa_masked_en(wal, HIZ_CHICKEN, HZ_DEPTH_TEST_LE_GE_OPT_DISABLE);
> }
>
>
On Mon, Mar 06, 2023 at 12:49:53PM -0800, Lucas De Marchi wrote:
> Use gt_tuning_settings() for the recommended tunings rather than the one
> for workarounds.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 1
On Mon, Mar 06, 2023 at 12:49:52PM -0800, Lucas De Marchi wrote:
> dg1_gt_workarounds_init() is only ever called for DG1, so there is no
> point checking it again.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_
for SAMedia")
> Signed-off-by: Badal Nilawar
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/dr
d-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 --
> drivers/gpu/drm/i915/i915_reg_defs.h| 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/dri
+ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> > @@ -19,7 +19,7 @@ static bool __guc_rc_supported(struct intel_guc *guc)
> > * Do not enable gucrc to avoid additional interrupts which
> > * may disrupt pcode wa.
> > */
> > - if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
> > + if (IS_METEORLAKE(gt->i915) && INTEL_REVID(gt->i915) == 0 &&
> > gt->type == GT_MEDIA)
> > return false;
> >
> > --
> > 2.25.1
> >
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
On Thu, Feb 23, 2023 at 10:08:51AM +0100, Andrzej Hajda wrote:
> On 17.02.2023 19:54, Matt Roper wrote:
> > MTL's primary GT can continue to use the same engine TLB invalidation
> > programming as past Xe_HP-based platforms. However the media GT needs
> >
Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Andrzej Hajda
Signed-off-by: Matt Roper
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 52 ---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git
max_subslices in the eu_mask
> > struct.
> >
> > Reported-by: Emil Renner Berthing
> > Signed-off-by: Andrea Righi
>
> Looks like bug was probably introduced in:
>
> Fixes: bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU mask internally in
engine instance, it inexplicably
uses bit 1 to request invalidations rather than bit 0.
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 52 ---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
2 files
(Andrzej)
>
> v5:
> * Tidy checkpatch warnings.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andrzej Hajda
> Cc: Matt Roper
> Reviewed-by: Andrzej Hajda # v1
> Reviewed-by: Matt Roper # v3
Reviewed-by: Matt Roper
for this version as well.
Matt
> Signed-of
On Wed, Feb 15, 2023 at 11:48:13AM -0800, Sripada, Radhakrishna wrote:
>
>
> > -Original Message-
> > From: dri-devel On Behalf Of Matt
> > Roper
> > Sent: Monday, February 13, 2023 4:19 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: d
: a7ec65fc7e83 ("drm/i915/xelpmp: Add multicast steering for media GT")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_m
f, and by doing so minimise the amount
> of invariant platform and engine checks during each and every TLB
> invalidation.
>
> v2:
> * Fail engine probe if TLB invlidations registers are unknown.
>
> v3:
> * Rebase.
>
> Signed-off-by: Tvrtko Ursulin
>
On Mon, Feb 06, 2023 at 08:54:10AM -0800, Lucas De Marchi wrote:
> INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually
> used it can just be removed.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
Looks like the only reference to the register
On Fri, Feb 03, 2023 at 10:03:49AM -0800, Lucas De Marchi wrote:
> On Thu, Feb 02, 2023 at 05:12:10PM -0800, Matt Roper wrote:
> > On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> > > Register 0x9424 is not replicated on any platform, so it shouldn't
d either add a new "GEN9" definition, or just go back to
using the GEN7 definition.
Matt
>
> Also use intel_uncore_rmw() rather than a read + write where possible.
>
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
> Cc: Matt Roper
>
. As far as we know, there's never a case where a
register that lives outside the RENDER powerwell will be reset by an
RCS/CCS engine reset.
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/gt/selftest_workarounds.c| 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu
. As such, we should implement this on the GT
workaround list rather than an engine list.
Bspec: 19219
Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
1 file
the reset of a register that
lives outside the RENDER domain.
Re-applying these registers on engine resets wouldn't actually hurt
anything, but is unnecessary and just makes it more confusing to anyone
trying to decipher how these registers really work.
Signed-off-by: Matt Roper
---
drivers/gpu/d
915: Define MCR registers explicitly")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/dri
On Thu, Jan 26, 2023 at 10:46:01AM +, Tvrtko Ursulin wrote:
>
> On 25/01/2023 19:04, Matt Roper wrote:
> > On Wed, Jan 25, 2023 at 10:51:53AM +, Tvrtko Ursulin wrote:
> > >
> > > On 24/01/2023 20:54, john.c.harri...@intel.com wrote:
> > > > Fr
On Wed, Jan 25, 2023 at 03:41:58PM -0800, Matt Roper wrote:
> Workaround Wa_18018781329 has applied to several recent Xe_HP-based
> platforms. However there are some extra gotchas to implementing this
> properly for MTL that we need to take into account:
>
> * Due to the sepa
annotation, workarounds will always be properly applied in a
multicast manner on these platforms.
Cc: Gustavo Sousa
Fixes: 58bc2453ab8a ("drm/i915: Define multicast registers as a new type")
Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
---
drivers/gpu/drm/i915/gt/intel_gt_regs.
exist.
Cc: Gustavo Sousa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 22 ++---
drivers/gpu/drm/i915/i915_drv.h | 4
3 files changed, 24 insertions(+), 9 deletions(-)
diff
ot;drm/i915/dg2: Move misplaced 'ctx' & 'gt' wa's to engine
wa list")
Fixes: b2006061ae28 ("drm/i915/xehpsdv: Move render/compute engine reset
domains related workarounds")
Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
Signed-off-by: Matt Roper
---
On Wed, Jan 25, 2023 at 04:43:29PM -0300, Gustavo Sousa wrote:
> On Tue, Jan 24, 2023 at 05:14:06PM -0800, Matt Roper wrote:
> > Register reset characteristics (i.e., whether the register maintains or
> > loses its value on engine reset) is an important factor that determines
>
int ret;
> > - drm_dbg(>drm, "Triggering Driver-FLR\n");
> > + gt_dbg(uncore->gt, "Triggering Driver-FLR\n");
> > /*
> > * Make sure any pending FLR requests have cleared by waiting for the
> > @@ -2738,9 +2733,7 @@ static void driver_initiated_flr(struct intel_uncore
> > *uncore)
> > */
> > ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0,
> > flr_timeout_ms);
> > if (ret) {
> > - drm_err(>drm,
> > - "Failed to wait for Driver-FLR bit to clear! %d\n",
> > - ret);
> > + gt_err(uncore->gt, "Failed to wait for Driver-FLR bit to clear!
> > %d\n", ret);
> > return;
> > }
> > intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
> > @@ -2752,7 +2745,7 @@ static void driver_initiated_flr(struct intel_uncore
> > *uncore)
> > DRIVERFLR_STATUS, DRIVERFLR_STATUS,
> > flr_timeout_ms);
> > if (ret) {
> > - drm_err(>drm, "wait for Driver-FLR completion failed!
> > %d\n", ret);
> > + gt_err(uncore->gt, "wait for Driver-FLR completion failed!
> > %d\n", ret);
> > return;
> > }
> > @@ -2911,7 +2904,7 @@ intel_uncore_arm_unclaimed_mmio_detection(struct
> > intel_uncore *uncore)
> > {
> > bool ret = false;
> > - if (drm_WARN_ON(>i915->drm, !uncore->debug))
> > + if (gt_WARN_ON(uncore->gt, !uncore->debug))
> > return false;
> > spin_lock_irq(>debug->lock);
> > @@ -2921,10 +2914,10 @@ intel_uncore_arm_unclaimed_mmio_detection(struct
> > intel_uncore *uncore)
> > if (unlikely(check_for_unclaimed_mmio(uncore))) {
> > if (!uncore->i915->params.mmio_debug) {
> > - drm_dbg(>i915->drm,
> > - "Unclaimed register detected, "
> > - "enabling oneshot unclaimed register reporting.
> > "
> > - "Please use i915.mmio_debug=N for more
> > information.\n");
> > + gt_dbg(uncore->gt,
> > + "Unclaimed register detected, "
> > + "enabling oneshot unclaimed register reporting. "
> > + "Please use i915.mmio_debug=N for more
> > information.\n");
> > uncore->i915->params.mmio_debug++;
> > }
> > uncore->debug->unclaimed_mmio_check--;
> > @@ -2957,7 +2950,7 @@ intel_uncore_forcewake_for_reg(struct intel_uncore
> > *uncore,
> > {
> > enum forcewake_domains fw_domains = 0;
> > - drm_WARN_ON(>i915->drm, !op);
> > + gt_WARN_ON(uncore->gt, !op);
> > if (!intel_uncore_has_forcewake(uncore))
> > return 0;
> > @@ -2968,7 +2961,7 @@ intel_uncore_forcewake_for_reg(struct intel_uncore
> > *uncore,
> > if (op & FW_REG_WRITE)
> > fw_domains |= uncore->funcs.write_fw_domains(uncore, reg);
> > - drm_WARN_ON(>i915->drm, fw_domains & ~uncore->fw_domains);
> > + gt_WARN_ON(uncore->gt, fw_domains & ~uncore->fw_domains);
> > return fw_domains;
> > }
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
annotation, workarounds will always be properly applied in a
multicast manner on these platforms.
Cc: Gustavo Sousa
Fixes: 58bc2453ab8a ("drm/i915: Define multicast registers as a new type")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
drivers/gp
engine reset
domains related workarounds")
Fixes: 41bb543f5598 ("drm/i915/mtl: Add initial gt workarounds")
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
drivers/gpu/drm/i915/i915_d
as CPU-initiated accesses; they
use a different steering control register (0x20CC) which is initialized
to a non-terminated DSS target by pre-OS firmware and never changed
thereafter (i915 does not touch it and userspace does not have
permission to change that register).
Signed-off-by: Matt Roper
2 to avoid catching all future platforms.
>(Matt)
>
> v4:
> * Be totally explicit on the Gen12 branch. (Andrzej)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Balasubramani Vivekanandan
> Cc: Andrzej Hajda
> Reviewed-by: Andrzej Hajda # v1
>
2 to avoid catching all future platforms.
>(Matt)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Balasubramani Vivekanandan
> Cc: Andrzej Hajda
> Reviewed-by: Andrzej Hajda # v1
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 17
On Thu, Jan 05, 2023 at 01:35:52PM +, Tvrtko Ursulin wrote:
>
> Okay to sum it up below with some final notes..
>
> On 04/01/2023 19:34, Matt Roper wrote:
> > On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:
> > >
> > > On 23/
On Fri, Jan 06, 2023 at 10:38:35AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Revert to the original explicit approach and document the reasoning
> behind it.
>
> v2:
> * DG2 needs to be covered too. (Matt)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: M
On Thu, Jan 05, 2023 at 01:06:37PM +, Tvrtko Ursulin wrote:
>
> On 04/01/2023 17:41, Matt Roper wrote:
> > On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
> > >
> > > On 03/01/2023 19:57, Matt Roper wrote:
> > > > On Mon, Dec 19, 202
lping.
> >
> > > Secondary but also important - if i915 is end of line then an extra
> > > why we want to rip out this for ancient platforms. Is the
> > > cost/benefit positive there?
> >
> > yep, here I agree and was my argument about using the platform names
> > rather than a more "catch all" regex. I think doing this only for tgl+
> > platforms or even dg2+ would be ok.
>
> Okay this is something to have as a 2nd option indeed. DG2 is out of force
> probe so maybe try with MTL. Although different rules for different
> platforms I don't know if will work in practice. Could be justt too
> complicated to be practical.
>
> > > As a side note, and going back to the question of what the tool can
> > > output. Long time ago I had an idea where we could improve all this
> > > by making it completely data-driven. Have the WA database inspecting
> > > tool output a table which could be directly pasted into code and
> > > interpreted by i915.
> > >
> > > For reference look at intel_workarounds_table.h in
> > > https://patchwork.freedesktop.org/patch/399377/?series=83580=3
> > > and see what you thing. That was just a sketch of the idea, not
> > > complete, and yes, i915 end of life point makes it moot.
> >
> > now that xe is announced I can talk about this part... this was more
> > or less what I implemented in xe: it's a table with
> > "register + condition + action". There are the most common condition
> > checks builtin + a function hook for the more advanced ones. During
> > binding the driver walks the table and coalesces the entries creating
> > a per-register value that can be used at the proper times, depending if
> > they are gt, engine, context workarounds.
>
> Cool, I support that high level approach.
>
> Regards,
>
> Tvrtko
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2023 19:57, Matt Roper wrote:
> > On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
> > > On 19.12.2022 11:13, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> >
; > giving sufficient attention that changes are made in tandem.)
>
> I can argue to the other side too. We don't have comments in the kernel
> like
>
> /* Add 1 to i */
> i += 1;
>
> This is exactly what these comments are doing. And they are misleading
Yeah, this
f TLB invlidations registers are unknown.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Andrzej Hajda
> > Cc: Matt Roper
> > Reviewed-by: Andrzej Hajda # v1
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
>
it in the specific steppings associated
with the workaround.
Bspec: 68331
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 ++---
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers
On Mon, Dec 05, 2022 at 04:33:29PM -0300, Gustavo Sousa wrote:
> On Thu, Dec 01, 2022 at 02:22:10PM -0800, Matt Roper wrote:
> > The TGL/RKL/DG1/ADL performance tuning guide suggests programming a
> > literal value of 0x2FC0100F for this register. The register's hardware
&g
On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
>
> On 02/12/2022 22:49, Rodrigo Vivi wrote:
> > On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
> > > When determining whether the platform has a hardware-level steering
> > > semaphore (
On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
>
> On 28/11/2022 23:30, Matt Roper wrote:
> > Starting with MTL, the driver needs to not only protect the steering
> > control register from simultaneous software accesses, but also protect
> > against race
/i915/mtl: Add hardware-level lock for steering")
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/inte
existing bits/fields in the preferred notation.
Bspec: 31870
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt
On Thu, Dec 01, 2022 at 02:56:30PM +0530, Balasubramani Vivekanandan wrote:
> On 30.11.2022 07:58, Matt Roper wrote:
> > PPAT setup involves a series of multicast writes. This can be optimized
> > slightly be acquiring forcewake and the steering lock just once for the
>
ndex c28be430718a..fd30befbf784 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> @@ -3,14 +3,18 @@
> * Copyright(c) 2020 Intel Corporation.
> */
> #include
> -#include "intel_pxp.h"
> -#include "intel_pxp_irq.h"
> -#include "intel_pxp_session.h"
> +
> #include "gt/intel_gt_irq.h"
> #include "gt/intel_gt_regs.h"
> #include "gt/intel_gt_types.h"
> +
> #include "i915_irq.h"
> #include "i915_reg.h"
> +
> +#include "intel_pxp.h"
> +#include "intel_pxp_irq.h"
> +#include "intel_pxp_session.h"
> +#include "intel_pxp_types.h"
> #include "intel_runtime_pm.h"
>
> /**
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> index 6a7d4e2ee138..37371f44a550 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -3,11 +3,13 @@
> * Copyright(c) 2020 Intel Corporation.
> */
>
> +#include "i915_drv.h"
> +
> #include "intel_pxp.h"
> #include "intel_pxp_irq.h"
> #include "intel_pxp_pm.h"
> #include "intel_pxp_session.h"
> -#include "i915_drv.h"
> +#include "intel_pxp_types.h"
>
> void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
> {
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index b0c9170b1395..16782d119bfd 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -11,17 +11,19 @@
> #include "gem/i915_gem_lmem.h"
>
> #include "i915_drv.h"
> +
> #include "intel_pxp.h"
> -#include "intel_pxp_session.h"
> -#include "intel_pxp_tee.h"
> #include "intel_pxp_cmd_interface_42.h"
> #include "intel_pxp_huc.h"
> +#include "intel_pxp_session.h"
> +#include "intel_pxp_tee.h"
> +#include "intel_pxp_types.h"
>
> static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> {
> struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
>
> - return _gt(i915)->pxp;
> + return i915->pxp;
> }
>
> static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> index f74b1e11a505..d550cdba3399 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
> @@ -12,12 +12,23 @@
> #include
>
> struct intel_context;
> +struct intel_gt;
> struct i915_pxp_component;
> +struct drm_i915_private;
>
> /**
> * struct intel_pxp - pxp state
> */
> struct intel_pxp {
> + /** @i915: back poiner to i915*/
> + struct drm_i915_private *i915;
> +
> + /**
> + * @ctrl_gt: poiner to the tile that owns the controls for PXP
> subsystem assets that
> + * the VDBOX, the KCR engine (and GSC CS depending on the platform)
> + */
> + struct intel_gt *ctrl_gt;
> +
> /**
>* @pxp_component: i915_pxp_component struct of the bound mei_pxp
>* module. Only set and cleared inside component bind/unbind functions,
>
> base-commit: d21d6474a37e5d43075a24668807ea40a7ee9fc1
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
On Wed, Nov 30, 2022 at 09:07:23AM -0800, Wayne Boyer wrote:
> As per the performance tuning guide, set the HOSTCACHEEN bit to
> implement the recommended caching policy on PVC.
>
> Signed-off-by: Wayne Boyer
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel
On Wed, Nov 30, 2022 at 09:21:07PM +0530, Balasubramani Vivekanandan wrote:
> On 28.11.2022 15:30, Matt Roper wrote:
> > PPAT setup involves a series of multicast writes. This can be optimized
> > slightly be acquiring forcewake and the steering lock just once for the
>
PPAT setup involves a series of multicast writes. This can be optimized
slightly be acquiring forcewake and the steering lock just once for the
entire sequence.
v2:
- We should use FW_REG_WRITE instead of FW_REG_READ. (Bala)
Suggested-by: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
fix to new steering semaphore register. (Mika)
Cc: Mika Kuoppala
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 38 ++---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
accesses in
interrupt context because reset -> errordump happens in a tasklet.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 79 ++
PPAT setup involves a series of multicast writes. This can be optimized
slightly be acquiring forcewake and the steering lock just once for the
entire sequence.
Suggested-by: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 27
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR
register")
Reported-by: kernel test robot
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mc
for hardware semaphore and CI taint if we ever
encounter it (this implies a hardware/firmware problem). (Mika)
- Add an extra patch optimizing xehp_setup_private_ppat by holding
forcewake & mcr lock over the sequence of register writes. (Bala)
Cc: Mika Kuoppala
Cc: Balasubramani Vivekanan
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
following patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
1 file changed, 10 insertions(+), 8
On Wed, Nov 23, 2022 at 02:46:18PM -0800, John Harrison wrote:
> On 11/17/2022 09:33, Matt Roper wrote:
> > ...
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index 830edffe88cc..d9a8ff9e5e57 100644
of intel_gt_tiles_init
>
> v3:
> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
>
> v4: drop using RCU primitives on ggtt->gt_list as it is not an RCU list
> (Matt Roper)
>
> Cc: Matt Roper
> Signed-off-by: Aravind Iddamsetty
Reviewed-by: Matt Roper
>
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
folling patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
1 file changed, 10 insertions(+), 8
n be used
to serialize not only software accesses, but also hardware/firmware
accesses as well; support for that hardware level lock will be added in
a future patch.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/i
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR
register")
Reported-by: kernel test robot
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mc
; assuming the hardware lock is behaving properly,
there should never be any contention on the software lock in this case.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 29 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
2 files changed, 26
-provided STEER_SEMAPHORE that allows us to
synchronize with external hardware and firmware agents.
Matt Roper (4):
drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg()
drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writes
drm/i915/gt: Add dedicated MCR lock
drm/i915/mtl: Add
of intel_gt_tiles_init
>
> v3:
> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
>
> Cc: Matt Roper
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 54 +--
> drivers/gpu/drm/i915/gt/intel_gt.c
On Fri, Nov 18, 2022 at 01:20:45PM -0800, Lucas De Marchi wrote:
> On Thu, Nov 17, 2022 at 09:33:58AM -0800, Matt Roper wrote:
> > The GT MCR code currently relies on uncore->lock to avoid race
> > conditions on the steering control register during MCR operations. The
> >
I can see, letting
this function run its course doesn't wind up having any effect or cause
any problems (you still wind up with an empty list).
Regardless,
Reviewed-by: Matt Roper
>
> engine_fake_wa_init(engine, wal);
> @@ -3016,9 +3016,6 @@ void intel_engine_init_workarounds(
uot;drm/i915/gt: Add intel_gt_mcr_wait_for_reg_fw()")
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 12 ++--
3 files changed, 19 in
e that was wrongly referenced, adding back the
> reference in the correct paragraph.
> - Remove "Display workarounds" and just mention "display IP" under
> "Other" category since all of them are peppered around the driver.
>
> Cc: Matt Roper
> Sign
t; description below for now?
Matt
> + *
> + * - Other: There are WAs that, due to their nature, cannot be applied from
> a central
> + * place. Those are peppered around the rest of the code, as needed.
> + *
> + * .. [1] Technically, some registers are powercontext saved & restored, so
> they
> + *survive a suspend/resume. In practice, writing them again is not too
> + *costly and simplifies things, so it's the approach taken in the driver.
> + */
>
> static void wa_init_start(struct i915_wa_list *wal, const char *name, const
> char *engine_name)
> {
> --
> 2.38.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Cc: Joonas Lahtinen
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
There was some recent offline discussion questioning whether we'd fully
identified the root cause of some historic CI failures, or whether it
was possible we might still have a bug lurking somewhere causing
sporadic failures
On Mon, Nov 07, 2022 at 07:43:59PM +0530, Iddamsetty, Aravind wrote:
>
>
> On 31-10-2022 23:16, Matt Roper wrote:
> > On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote:
> >> On XE_LPM+ platforms the media engines are carved out into a separate
> >&
t; v2: clean up the if statement for the engine irq (Tvrtko)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> Cc: Tvrtko Ursulin
> Reviewed-by: Matt Roper #v1
Reviewed-by: Matt Roper
for v2 as well.
> ---
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 75
the debug logs (Matt)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 27 -
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/g
BLE REG_BIT(4)
We need one more space here between 'define' and the register name for
consistency with the rest of the file. But I can fix that up while
applying.
Reviewed-by: Matt Roper
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
> +
> #define GEN8_R
_FREQUENCY_CONFIG param2 */
> #define PCODE_MBOX_DOMAIN_NONE 0x0
> #define PCODE_MBOX_DOMAIN_MEDIAFF0x3
> +
> +/* Wa_14017210380: mtl */
> +#define PCODE_MBOX_GT_STATE0x50
> +/* sub-commands (param1) */
> +#define PCODE_MBOX_GT_STATE_MEDIA_BUSY 0x1
> +#define PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY 0x2
> +/* param2 */
> +#define PCODE_MBOX_GT_STATE_DOMAIN_MEDIA 0x1
> +
> #define GEN6_PCODE_DATA _MMIO(0x138128)
> #define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
> #define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
On Mon, Oct 31, 2022 at 09:43:33AM -0700, Ceraolo Spurio, Daniele wrote:
>
>
> On 10/31/2022 9:26 AM, Matt Roper wrote:
> > On Thu, Oct 27, 2022 at 03:15:50PM -0700, Daniele Ceraolo Spurio wrote:
> > > Starting on MTL, the GSC is no longer managed with direct MMIO acce
PAT setup should be noted and explained as
well since it differs from how you approached the other changes here.
>
> BSPEC: 63834
>
> Cc: Matt Roper
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 49 +++---
> d
s.
> Note that, although it is now a CS, the GSC retains its old
> class:instance value (OTHER_CLASS instance 6)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Now that we have an OTHER_CLASS engine, I think we also need to deal
with the class -> reg mapping table in mmio_
On Fri, Oct 28, 2022 at 04:04:18PM -0700, Lucas De Marchi wrote:
> On Fri, Oct 28, 2022 at 03:40:22PM -0700, Matt Roper wrote:
> > The termination entries were missing for a couple of the recently-added
> > MTL steering tables.
> >
> > Fixes: f32898c94a10 ("drm/i9
The termination entries were missing for a couple of the recently-added
MTL steering tables.
Fixes: f32898c94a10 ("drm/i915/xelpg: Add multicast steering")
Fixes: a7ec65fc7e83 ("drm/i915/xelpmp: Add multicast steering for media GT")
Signed-off-by: Matt Roper
---
dri
On Fri, Oct 28, 2022 at 10:14:05AM -0700, Ceraolo Spurio, Daniele wrote:
>
>
> On 10/27/2022 8:40 PM, Matt Roper wrote:
> > On Thu, Oct 27, 2022 at 03:15:54PM -0700, Daniele Ceraolo Spurio wrote:
> > > There is no userspace user for this CS yet, we only need it for intern
On Thu, Oct 27, 2022 at 03:15:54PM -0700, Daniele Ceraolo Spurio wrote:
> There is no userspace user for this CS yet, we only need it for internal
> kernel ops (e.g. HuC, PXP), so don't expose it.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Since we never expose
On Thu, Oct 27, 2022 at 03:15:53PM -0700, Daniele Ceraolo Spurio wrote:
> The GSC CS has its own dedicated bit in the GDRST register.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Bspec: 52549
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/int
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 ++
> 1 file changed, 43 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_i
apping tables, even before this
patch, so I'd just leave this sentence off to avoid confusion.
Otherwise,
Reviewed-by: Matt Roper
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 11 +--
> dr
s.
> Note that, although it is now a CS, the GSC retains its old
> class:instance value (OTHER_CLASS instance 6)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Maybe add "Bspec: 65308, 45605" as a reference?
Otherwise,
Reviewed-by: Matt Roper
> ---
> d
A misplaced closing parenthesis caused the groupid/instanceid values to
be considered part of the ternary operator's condition instead of being
OR'd into the resulting value.
Fixes: f32898c94a10 ("drm/i915/xelpg: Add multicast steering")
Reported-by: kernel test robot
Signed-off-by:
he older TGL-ADL gfx IP name. MTL's media IP is called
Xe_LPM+ (which we should label as XELPMP in code, so it looks like the
final "P" is missing here).
Matt
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
, we keep the
> interrupts always enabled in HW and use a variable in the GuC structure
> to determine if we want to service the received interrupts or not.
>
> v2: use MTL_ prefix for reg definition (Matt)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> Cc: John Harri
The bspec was just updated with a correction to the forcewake domain
required when accessing registers in the CCS engine ranges (0x1a000 -
0x1 and 0x26000 - 0x27fff) on PVC; these ranges require a wake on
the RENDER domain, not the GT domain.
Bspec: 67609
Signed-off-by: Matt Roper
t writes just to be safe. (Bala)
Bspec: 67788, 67112
Cc: Radhakrishna Sripada
Cc: Balasubramani Vivekanandan
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 135 +---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/gt/inte
MTL's media IP (Xe_LPM+) only has a single type of steering ("OAADDRM")
which selects between media slice 0 and media slice 1. We'll always
steer to media slice 0 unless it is fused off (which is the case when
VD0, VE0, and SFC0 are all reported as unavailable).
Bspec: 67789
Signed-of
need only make changes to structures that have an
explicit i915_reg_t in them now.
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c| 16 --
drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 51 ---
drivers/gpu/drm/i915/gt/inte
Let's be more explicit about which of our workarounds are updating MCR
registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 433 +++---
.../gpu/drm/i915/gt/intel_workarounds_types.h | 4 +-
2 files changed, 263 insertions(+), 174 deletions
ally
steer to the primary GAM) is sufficient; we don't need to loop over each
instance of the MCR register.
v2:
- Update more instances of fault registers. (Bala)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c| 52 +++
drivers/gpu/drm/i915/i915_gpu_er
that handles this on MCR registers, similar to the
__intel_wait_for_register_fw() function we already have for regular
registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 55 ++
drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 7
2 files changed, 62
Let's drop a few register definitions that are unused anywhere in the
driver today. Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.
Signed-off-by: Matt Roper
---
drivers
101 - 200 of 1194 matches
Mail list logo
