Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

[Joonas Lahtinen]

+ Tvrtko and Chris for comments

Code seems to be added in:

commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin 
Date:   Tue Nov 21 18:18:50 2017 +

drm/i915/pmu: Add interrupt count metric

I think later in the thread there was a suggestion to replace this with
simple counter increment in IRQ handler.

Regards, Joonas

Quoting Thomas Gleixner (2020-12-06 18:38:44)
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> 
> > Now that kstat_irqs is exported, get rid of count_interrupts in
> > i915_pmu.c
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
> > *hrtimer)
> >   return HRTIMER_RESTART;
> >  }
> >  
> > -static u64 count_interrupts(struct drm_i915_private *i915)
> > -{
> > - /* open-coded kstat_irqs() */
> > - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> > - u64 sum = 0;
> > - int cpu;
> > -
> > - if (!desc || !desc->kstat_irqs)
> > - return 0;
> > -
> > - for_each_possible_cpu(cpu)
> > - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> > -
> > - return sum;
> > -}
> 
> May I ask why this has been merged in the first place?
> 
> Nothing in a driver has ever to fiddle with the internals of an irq
> descriptor. We have functions for properly accessing them. Just because
> C allows to fiddle with everything is not a justification. If the
> required function is not exported then adding the export with a proper
> explanation is not asked too much.
> 
> Also this lacks protection or at least a comment why this can be called
> safely and is not subject to a concurrent removal of the irq descriptor.
> The same problem exists when calling kstat_irqs(). It's even documented
> at the top of the function.
> 
> Thanks,
> 
> tglx
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-07 20:48:55)
> 
> >Repeating the same comment as on previous review, avoid including anything 
> >in i915_drv.h and only include in the relevant files that require to touch 
> >the internals of the structs.
> 
> I would still need to include i915_drv.h for macro INTEL_GEN(), hopefully 
> it's acceptable.

That is fine. I was referring to the opposite, do not include
"intel_pxp.h" from i915_drv.h.

It's instead better to add "intel_pxp_types.h" etc. (look for *_types.h
files from i915 source) and minimize what is included by each file.

Regards, Joonas

> 
> -Original Message-
> From: Huang, Sean Z 
> Sent: Monday, December 7, 2020 10:26 AM
> To: Joonas Lahtinen ; 
> Intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP 
> component
> 
> Hi Joonas,
> 
> Thanks for the details review. I have apply the modification according to the 
> review, and will update as rev2.
> > Description is no more true for single-session only
> DONE
> 
> > Same here, needs updating.
> DONE
> 
> >Repeating the same comment as on previous review, avoid including anything 
> >in i915_drv.h and only include in the relevant files that require to touch 
> >the internals of the structs.
> DONE
> 
> > I think this should instead go as part of intel_gt, not here.
> DONE
> 
> > We should aim to only take struct intel_pxp as parameter for intel_pxp_* 
> > functions.
> DONE, I think the suggestion is reasonable. I expect that will modify the 
> code significantly in the future commits, but let me try intel_pxp_* instead 
> of i915
> 
> > This would be either a major kernel programmer error or the memory would be 
> > seriously corrupt. No point leaving such checks to production code, so 
> > GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug builds.
> DONE, I just remove the error check
> 
> > Also, we have not really initialized anything so it's really premature to 
> > print anything in this patch.
> DONE, remove the print
> 
> > Same here, we really want to tighten the scope to intel_pxp and call 
> > this from intel_gt_fini(), so signature should look like: void 
> > intel_pxp_fini(struct intel_pxp *pxp)
> DONE
> 
> Best regards,
> Sean
> 
> -Original Message-
> From: Joonas Lahtinen 
> Sent: Monday, December 7, 2020 2:01 AM
> To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP 
> component
> 
> Quoting Huang, Sean Z (2020-12-07 02:21:19)
> > PXP (Protected Xe Path) is an i915 componment, available on GEN12+, 
> > that helps user space to establish the hardware protected session and 
> > manage the status of each alive software session, as well as the life 
> > cycle of each session.
> > 
> > By design PXP will expose ioctl so allow user space to create, set, 
> > and destroy each session. It will also provide the communication 
> > chanel to TEE (Trusted Execution Environment) for the protected 
> > hardware session creation.
> 
> Description is no more true for single-session only.
> 
> 
> 
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -130,6 +130,25 @@ config DRM_I915_GVT_KVMGT
> >   Choose this option if you want to enable KVMGT support for
> >   Intel GVT-g.
> >  
> > +config DRM_I915_PXP
> > +   bool "Enable Intel PXP support for Intel Gen12+ platform"
> > +   depends on DRM_I915
> > +   select INTEL_MEI_PXP
> > +   default n
> > +   help
> > + This option selects INTEL_MEI_ME if it isn't already selected to
> > + enabled full PXP Services on Intel platforms.
> > +
> > + PXP is an i915 componment, available on Gen12+, that helps user
> > + space to establish the hardware protected session and manage the
> > + status of each alive software session, as well as the life cycle
> > + of each session.
> > +
> > + PXP expose ioctl so allow user space to create, set, and destroy
> > + each session. It will also provide the communication chanel to
> > + TEE (Trusted Execution Environment) for the protected hardware
> > + session creation.
> 
> Same here, needs updating.
> 
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -105,6 +105,8 @@
> >  
> >  #include "intel_region_lmem.h"
> >  
> > +#include "pxp/intel_pxp.h"
> 
> Repeating the same comment as on previous rev

Re: [Intel-gfx] [RFC-v3 11/13] drm/i915/uapi: introduce drm_i915_gem_create_ext

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:03:05)
> From: Bommu Krishnaiah 

The patch authorship is still recorded wrong.

'git am' should always be used for importing patches to retain the
correct authorship.

Regards, Joonas

> Same old gem_create but with now with extensions support. This is needed
> to support various upcoming usecases. For now we use the extensions
> mechanism to support PAVP.
> 
> Signed-off-by: Bommu Krishnaiah 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
> Cc: Matthew Auld matthew.a...@intel.com
> Cc: Telukuntla Sreedhar 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c | 42 -
>  include/uapi/drm/i915_drm.h | 47 +
>  3 files changed, 89 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index af06c85e6ba7..3dbda949bf71 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1733,7 +1733,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> -   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
> DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(I915_GEM_CREATE_EXT, i915_gem_create_ioctl, 
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
> DRM_RENDER_ALLOW),
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 58276694c848..41698a823737 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -53,6 +53,7 @@
>  #include "i915_drv.h"
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
> +#include "i915_user_extensions.h"
>  
>  #include "intel_pm.h"
>  
> @@ -260,6 +261,35 @@ i915_gem_dumb_create(struct drm_file *file,
>&args->size, &args->handle);
>  }
>  
> +struct create_ext {
> +struct drm_i915_private *i915;
> +};
> +
> +static int __create_setparam(struct drm_i915_gem_object_param *args,
> +   struct create_ext 
> *ext_data)
> +{
> +   if (!(args->param & I915_OBJECT_PARAM)) {
> +   DRM_DEBUG("Missing I915_OBJECT_PARAM namespace\n");
> +   return -EINVAL;
> +   }
> +
> +   return -EINVAL;
> +}
> +
> +static int create_setparam(struct i915_user_extension __user *base, void 
> *data)
> +{
> +   struct drm_i915_gem_create_ext_setparam ext;
> +
> +   if (copy_from_user(&ext, base, sizeof(ext)))
> +   return -EFAULT;
> +
> +   return __create_setparam(&ext.param, data);
> +}
> +
> +static const i915_user_extension_fn create_extensions[] = {
> +   [I915_GEM_CREATE_EXT_SETPARAM] = create_setparam,
> +};
> +
>  /**
>   * Creates a new mm object and returns a handle to it.
>   * @dev: drm device pointer
> @@ -271,10 +301,20 @@ i915_gem_create_ioctl(struct drm_device *dev, void 
> *data,
>   struct drm_file *file)
>  {
> struct drm_i915_private *i915 = to_i915(dev);
> -   struct drm_i915_gem_create *args = data;
> +   struct create_ext ext_data = { .i915 = i915 };
> +   struct drm_i915_gem_create_ext *args = data;
> +   int ret;
>  
> i915_gem_flush_free_objects(i915);
>  
> +   ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
> +  create_extensions,
> +  ARRAY_SIZE(create_extensions),
> +  &ext_data);
> +   if (ret)
> +   return ret;
> +
> +
> return i915_gem_create(file,
>intel_memory_region_by_type(i915,
>
> INTEL_MEMORY_SYSTEM),
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 6edcb2b6c708..e918ccc81c74 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -391,6 +391,7 @@ typedef struct _drm_i915_sarea {
>  #define DRM_IOCTL_I915_G

Re: [Intel-gfx] [RFC-v3 01/13] drm/i915/pxp: Introduce Intel PXP component

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:02:55)
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps to establish the hardware protected session and manage
> the status of the alive software session, as well as its life cycle.
> 
> This patch series is to allow the kernel space to create and
> manage a single hardware session (a.k.a default session or
> arbitrary session). So Mesa can allocate the protected buffer,
> which is encrypted with the leverage of the arbitrary hardware
> session.
> 
> Signed-off-by: Huang, Sean Z 



> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -254,6 +254,11 @@ i915-y += \
>  
>  i915-y += i915_perf.o
>  
> +# Protected execution platform (PXP) support
> +i915-$(CONFIG_DRM_I915_PXP) += \
> +   pxp/intel_pxp.o \
> +   pxp/intel_pxp_context.o
> +
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
>  i915-$(CONFIG_DRM_I915_SELFTEST) += \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 44f1d51e5ae5..d8e20ede7326 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -584,6 +584,12 @@ int intel_gt_init(struct intel_gt *gt)
> if (err)
> goto err_gt;
>  
> +   if (INTEL_GEN(gt->i915) >= 12) {

This check should be moved into intel_pxp_init() to avoid cluttering the
top level init flow.

Inside init, we should record the pxp initialization status and fail
the attempted use of PXP from uAPI or from MEI driver with -ENODEV.

> +   err = intel_pxp_init(>->pxp);
> +   if (err)
> +   goto err_gt;
> +   }
> +
> goto out_fw;
>  err_gt:
> __intel_gt_disable(gt);
> @@ -638,6 +644,7 @@ void intel_gt_driver_release(struct intel_gt *gt)
> if (vm) /* FIXME being called twice on error paths :( */
> i915_vm_put(vm);
>  
> +   intel_pxp_uninit(>->pxp);

intel_pxp_fini()

> intel_gt_pm_fini(gt);
> intel_gt_fini_scratch(gt);
> intel_gt_fini_buffer_pool(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 6d39a4a11bf3..05255632c2c0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -23,6 +23,7 @@
>  #include "intel_rc6_types.h"
>  #include "intel_rps_types.h"
>  #include "intel_wakeref.h"
> +#include "pxp/intel_pxp.h"

This should include just intel_pxp_types.h.

> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_context.h"
> +
> +int intel_pxp_init(struct intel_pxp *pxp)
> +{
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
> +
> +   /* PXP only available for GEN12+ */

Comment is spurious, just describes what the next line of code reads, so can
be dropped.

> +   if (INTEL_GEN(gt->i915) < 12)

We probably better introduce HAS_PXP() macro (I think it was previously
suggested, too).

> +   return -ENODEV;

This is top-level initialization function, we should record the
initialization status somewhere at the end of successful init sequence.
Then in whatever entrypoints we have to the code from userspace we want
to differentiate between failure to initialize and not supported by HW.

Based on what I'm reading here, this could be made into void function as
I don't see anything that would potentially fail.

So above would look like

if (!HAS_PXP(i915))
return;

As the top level intel_gt init sequence is not impacted by the lack of
PXP or even the init failure.

> +   intel_pxp_ctx_init(&pxp->ctx);

I think we could use the pxp->ctx.id being nonzero as a check for successful
initialization in the entrypoints to code.

> +   drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content 
> support initialized\n");
> +
> +   return 0;
> +}
> +
> +void intel_pxp_uninit(struct intel_pxp *pxp)

intel_pxp_fini()

> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_H__
> +#define __INTEL_PXP_H__
> +
> +#include "intel_pxp_context.h"

This should only include intel_pxp_context_types.h file.

> +
> +struct intel_pxp {
> +   struct pxp_context ctx;
> +};

These should too go into separate intel_pxp_types.h file.

> +#ifdef CONFIG_DRM_I915_PXP
> +int intel_pxp_init(struct intel_pxp *pxp);
> +void intel_pxp_uninit(struct intel_pxp *pxp);

intel_pxp_fini()

> +#else
> +static inline int intel_pxp_init(struct intel_pxp *pxp)

This could become void.

> +{
> +   return 0;
> +}
> +
> +static inline void intel_pxp_uninit(struct intel_pxp *pxp)

intel_pxp_fini()

> index

Re: [Intel-gfx] [RFC-v3 03/13] drm/i915/pxp: Implement funcs to create the TEE channel

[Joonas Lahtinen]

Please not that in the middle section of the review I noticed that we're
creating i915_component which is injected with the send/recv functions
from MEI subsystem, so the component naming conventions seem to be
reversed to me.

Quoting Huang, Sean Z (2020-12-09 09:02:57)
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (defualt) session.

This TEE channel should be described in more detail. Now it
is hard to assess if the placement is correct. Is it related to the GT
only, or is it also related to display?

> Signed-off-by: Huang, Sean Z 



> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1216,6 +1216,12 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values. */
> struct mutex hdcp_comp_mutex;
>  
> +   struct i915_pxp_comp_master *pxp_tee_master;

The struct and variable names don't relate. No need to add "_master"
here (or "_primary") as we don't seem to have other than one.

struct i915_pxp_tee_component *pxp_tee_comp;

I can't assess if this belongs to intel_gt or here.

> +   bool pxp_tee_comp_added;

Why can't we just check for non-zero pxp_tee; ?

> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -5,6 +5,7 @@
>  #include "i915_drv.h"
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
>  
>  /* KCR register definitions */
>  #define KCR_INIT_MMIO(0x320f0)
> @@ -24,6 +25,8 @@ int intel_pxp_init(struct intel_pxp *pxp)
>  
> intel_uncore_write(gt->uncore, KCR_INIT, 
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
>  
> +   intel_pxp_tee_component_init(pxp);

I don't think this is the right location. This is for early hardware
init.

This should be a call named i915_pxp_tee_component_init();

And as it is related to exposing the component it should be much later
in init, probably near the audio component.

> @@ -31,5 +34,7 @@ int intel_pxp_init(struct intel_pxp *pxp)
>  
>  void intel_pxp_uninit(struct intel_pxp *pxp)
>  {
> +   intel_pxp_tee_component_fini(pxp);

Same here.

> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include 
> +#include "drm/i915_pxp_tee_interface.h"
> +#include "drm/i915_component.h"
> +#include  "i915_drv.h"
> +#include "intel_pxp.h"
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_tee.h"
> +
> +static int intel_pxp_tee_io_message(struct intel_pxp *pxp,

For .c local static functions, the prefixes should be dropped.

This should take struct intel_pxp_tee *tee as first parameter

> +   void *msg_in, u32 msg_in_size,

void* is no good, doesn't give impression of unit of size (pages?)

> +   void *msg_out, u32 *msg_out_size_ptr,

_ptr is tautology

> +   u32 msg_out_buf_size)

We can use the same variable for in and out

static int do_io(struct intel_pxp_tee *tee,
 u8 *in, size_t in_nbytes,
 u8 *out, size_t *out_nbytes)

> +{
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +   struct drm_i915_private *i915 = gt->i915;
> +   struct i915_pxp_comp_master *pxp_tee_master = i915->pxp_tee_master;
> +
> +   if (!pxp_tee_master || !msg_in || !msg_out || !msg_out_size_ptr)
> +   return -EINVAL;

GEM_BUG_ON() should be sufficient.

> +   lockdep_assert_held(&i915->pxp_tee_comp_mutex);
> +
> +   if (drm_debug_enabled(DRM_UT_DRIVER))
> +   print_hex_dump(KERN_DEBUG, "TEE input message binaries:",
> +  DUMP_PREFIX_OFFSET, 4, 4, msg_in, msg_in_size, 
> true);
> +
> +   ret = pxp_tee_master->ops->send(pxp_tee_master->tee_dev, msg_in, 
> msg_in_size);
> +   if (ret) {
> +   drm_err(&i915->drm, "Failed to send TEE message\n");
> +   return -EFAULT;
> +   }
> +
> +   ret = pxp_tee_master->ops->receive(pxp_tee_master->tee_dev, msg_out, 
> msg_out_buf_size);
> +   if (ret < 0) {
> +   drm_err(&i915->drm, "Failed to receive TEE message\n");
> +   return -EFAULT;
> +   }

Ok, this got confusing. It seems that we're importing the TEE hardware
to use from MEI subsystem? And not exposing it from i915.

I think the whole component mechanism is then the wrong way around. It
should be us importing the tee dev from MEI subsystem to communicate.

Also, why are we having separate send/receive callbacks but we stuff
everything under single function, we should not do that. So this should
be split into send() and recv() functions here.



> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_TEE_H__
> +#define __INTEL_PXP_TEE_

Re: [Intel-gfx] [RFC-v3 04/13] drm/i915/pxp: Create the arbitrary session after boot

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:02:58)
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session. Because the
> hardware requires at least one alive session for protected buffer
> creation.  This arbitrary session needs to be re-created after
> teardown or power event because hardware encryption key won't be
> valid after such cases.
> 
> Signed-off-by: Huang, Sean Z 



> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -8,6 +8,22 @@
>  
>  #include "intel_pxp_context.h"

Again, needs split between _types.h for both included types and declared
types.

>  
> +enum pxp_session_types {
> +   SESSION_TYPE_TYPE0 = 0,
> +   SESSION_TYPE_TYPE1 = 1,
> +
> +   SESSION_TYPE_MAX
> +};
> +
> +enum pxp_protection_modes {
> +   PROTECTION_MODE_NONE = 0,
> +   PROTECTION_MODE_LM   = 2,
> +   PROTECTION_MODE_HM   = 3,
> +   PROTECTION_MODE_SM   = 6,
> +
> +   PROTECTION_MODE_ALL
> +};
> +

None of this should be relevant for the single-session operation.

> +static bool is_hw_arb_session_in_play(struct intel_pxp *pxp)
> +{
> +   u32 regval_sip = 0;

No need to initialize.

> +   intel_wakeref_t wakeref;

Should not be needed here.

> +   struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);

This would be at the top of the function ususally.

> +
> +   with_intel_runtime_pm(>->i915->runtime_pm, wakeref) {

Repeating from previous review, these runtime checks should be hoisted to upper
level functions.

> +   regval_sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
> +   }
> +
> +   return regval_sip & BIT(ARB_SESSION_INDEX);

This function should literally just be

struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
u32 kcr_sip;

kcr_sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
return kcr_sip & BIT(ARB_SESSION_INDEX);

> +/* wait hw session_in_play reg to match the current sw state */
> +static int wait_arb_hw_sw_state(struct intel_pxp *pxp)
> +{
> +   const int max_retry = 10;
> +   const int ms_delay = 10;
> +   int retry = 0;
> +   int ret;
> +   struct pxp_protected_session *arb = pxp->ctx.arb_session;
> +
> +   ret = -EINVAL;
> +   for (retry = 0; retry < max_retry; retry++) {
> +   if (is_hw_arb_session_in_play(pxp) ==
> +   arb->is_in_play) {
> +   ret = 0;
> +   break;
> +   }
> +
> +   msleep(ms_delay);
> +   }

Again, this function should be rewritten utilize wait_for_* utils for
the single register we're checking.

So I think both of the above will then get merged into a single
local function:

static int wait_for_arb_session_in_play(struct intel_pxp *pxp)

> +/**
> + * create_session_entry - Create a new session entry with provided info.
> + * @pxp: pointer to pxp struct.
> + *
> + * Return: the pointer to the created session.
> + */
> +static struct pxp_protected_session *create_session_entry(struct intel_pxp 
> *pxp)
> +{
> +   struct pxp_protected_session *session;
> +
> +   session = kzalloc(sizeof(*session), GFP_KERNEL);
> +   if (!session)
> +   return NULL;

We only have single session, we can embed it and avoid dynamic
allocation.

>>> FROM HERE

> +   session->context_id = pxp->ctx.id;
> +   session->type = ARB_SESSION_TYPE;
> +   session->protection_mode = ARB_PROTECTION_MODE;
> +   session->index = ARB_SESSION_INDEX;
> +   session->is_in_play = false;
> +
> +   return session;
> +}
> +
> +int intel_pxp_arb_reserve_session(struct intel_pxp *pxp)
> +{
> +   int ret;
> +   struct pxp_protected_session *session = NULL;
> +
> +   lockdep_assert_held(&pxp->ctx.mutex);
> +
> +   ret = wait_arb_hw_sw_state(pxp);
> +   if (ret)
> +   return ret;
> +
> +   session = create_session_entry(pxp);
> +   if (!session)
> +   return -ENOMEM;
> +
> +   return ret;
> +}
> +
> +/**
> + * intel_pxp_arb_mark_session_in_play - To put an reserved protected session 
> to "in_play" state
> + * @pxp: pointer to pxp struct.
> + *
> + * Return: status. 0 means update is successful.
> + */
> +static int intel_pxp_arb_mark_session_in_play(struct intel_pxp *pxp)
> +{
> +   struct pxp_protected_session *arb = pxp->ctx.arb_session;
> +
> +   lockdep_assert_held(&pxp->ctx.mutex);
> +
> +   if (arb->is_in_play)
> +   return -EINVAL;
> +
> +   arb->is_in_play = true;
> +   return 0;
> +}

<<< UNTIL HERE

This is all just software tracking which we don't need for a single
session.

> +
> +int intel_pxp_arb_create_session(struct intel_pxp *pxp)

intel_pxp_arb_session()

> +{
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +
> +   lockdep_assert_held(&pxp->ctx.mutex);
> +
> +  

Re: [Intel-gfx] [RFC-v3 05/13] drm/i915/pxp: Func to send hardware session termination

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:02:59)
> Implement the functions to allow PXP to send a GPU command, in
> order to terminate the hardware session, so hardware can recycle
> this session slot for the next usage.

Just like for the ARB session creation must happen during i915
initialization in order to guarantee being available for userspace, we
must detect the corruption from i915 and i915 must be able to recreate
the session.

We already initiate the TEE commands to create the session, so I assume
we have to repeat those to recreate the session? Should not we
invalidate the previous session as part of that flow.

Any command to be sent to the command streamers that i915 is also
submitting to, should definitely happen under strict i915 control.

So we should include the session termination command in here, inside
i915 source.

Regards, Joonas

> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 156 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h |  18 +++
>  3 files changed, 175 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0710cc522f38..2da904cda49f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -258,6 +258,7 @@ i915-y += i915_perf.o
>  i915-$(CONFIG_DRM_I915_PXP) += \
> pxp/intel_pxp.o \
> pxp/intel_pxp_arb.o \
> +   pxp/intel_pxp_cmd.o \
> pxp/intel_pxp_context.o \
> pxp/intel_pxp_tee.o
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> new file mode 100644
> index ..e531ea9f3cdc
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "intel_pxp_cmd.h"
> +#include "i915_drv.h"
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +struct i915_vma *intel_pxp_cmd_get_batch(struct intel_pxp *pxp,
> +struct intel_context *ce,
> +struct intel_gt_buffer_pool_node 
> *pool,
> +u32 *cmd_buf, int cmd_size_in_dw)
> +{
> +   struct i915_vma *batch = ERR_PTR(-EINVAL);
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
> +   u32 *cmd;
> +
> +   if (!ce || !ce->engine || !cmd_buf)
> +   return ERR_PTR(-EINVAL);
> +
> +   if (cmd_size_in_dw * 4 > PAGE_SIZE) {
> +   drm_err(>->i915->drm, "Failed to %s, invalid 
> cmd_size_id_dw=[%d]\n",
> +   __func__, cmd_size_in_dw);
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC);
> +   if (IS_ERR(cmd)) {
> +   drm_err(>->i915->drm, "Failed to 
> i915_gem_object_pin_map()\n");
> +   return ERR_PTR(-EINVAL);
> +   }
> +
> +   memcpy(cmd, cmd_buf, cmd_size_in_dw * 4);
> +
> +   if (drm_debug_enabled(DRM_UT_DRIVER)) {
> +   print_hex_dump(KERN_DEBUG, "cmd binaries:",
> +  DUMP_PREFIX_OFFSET, 4, 4, cmd, cmd_size_in_dw 
> * 4, true);
> +   }
> +
> +   i915_gem_object_unpin_map(pool->obj);
> +
> +   batch = i915_vma_instance(pool->obj, ce->vm, NULL);
> +   if (IS_ERR(batch)) {
> +   drm_err(>->i915->drm, "Failed to i915_vma_instance()\n");
> +   return batch;
> +   }
> +
> +   return batch;
> +}
> +
> +int intel_pxp_cmd_submit(struct intel_pxp *pxp, u32 *cmd, int cmd_size_in_dw)
> +{
> +   int err = -EINVAL;
> +   struct i915_vma *batch;
> +   struct i915_request *rq;
> +   struct intel_context *ce = NULL;
> +   bool is_engine_pm_get = false;
> +   bool is_batch_vma_pin = false;
> +   bool is_skip_req_on_err = false;
> +   bool is_engine_get_pool = false;
> +   struct intel_gt_buffer_pool_node *pool = NULL;
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
> +
> +   if (!HAS_ENGINE(gt, VCS0) ||
> +   !gt->engine[VCS0]->kernel_context) {
> +   err = -EINVAL;
> +   goto end;
> +   }
> +
> +   if (!cmd || (cmd_size_in_dw * 4) > PAGE_SIZE) {
> +   drm_err(>->i915->drm, "Failed to %s bad params\n", 
> __func__);
> +   return -EINVAL;
> +   }
> +
> +   ce = gt->engine[VCS0]->kernel_context;
> +
> +   intel_engine_pm_get(ce->engine);
> +   is_engine_pm_get = true;
> +
> +   pool = intel_gt_get_buffer_pool(gt, PAGE_SIZE);
> +   if (IS_ERR(pool)) {
> +   drm_err(>->i915->drm, "Failed to 
> intel_engine_get_pool()\n");
> +   

Re: [Intel-gfx] [RFC-v3 07/13] drm/i915/pxp: Destroy arb session upon teardown

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:03:01)
> Teardown is triggered when the display topology changes and no
> long meets the secure playback requirement, and hardware trashes
> all the encryption keys for display. So as a result, PXP should
> handle such case and terminate the type0 sessions, which including
> arb session

We have only a single session, so this should be simplified to exactly
tear down that single session.

No need for any of the type0/type1 differentiation.

Regards, Joonas

> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/pxp/intel_pxp.c |   3 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.c |  76 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_arb.h |   1 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 129 ++-
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h |  12 ++-
>  5 files changed, 211 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 9bcb170b34f1..48e926363696 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -28,6 +28,9 @@ static int intel_pxp_teardown_required_callback(struct 
> intel_pxp *pxp)
> mutex_lock(&pxp->ctx.mutex);
>  
> pxp->ctx.global_state_attacked = true;
> +   pxp->ctx.flag_display_hm_surface_keys = false;
> +
> +   ret = intel_pxp_arb_terminate_session(pxp);
>  
> mutex_unlock(&pxp->ctx.mutex);
>  
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> index c1ad45b83478..09148ca9035c 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
> @@ -10,6 +10,7 @@
>  #include "intel_pxp.h"
>  #include "intel_pxp_context.h"
>  #include "intel_pxp_tee.h"
> +#include "intel_pxp_cmd.h"
>  
>  #define GEN12_KCR_SIP _MMIO(0x32260) /* KCR type0 session in play 0-31 */
>  
> @@ -150,3 +151,78 @@ int intel_pxp_arb_create_session(struct intel_pxp *pxp)
>  end:
> return ret;
>  }
> +
> +static int intel_pxp_arb_session_with_global_termination(struct intel_pxp 
> *pxp)
> +{
> +   u32 *cmd = NULL;
> +   u32 *cmd_ptr = NULL;
> +   int cmd_size_in_dw = 0;
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +
> +   /* Calculate how many bytes need to be alloc */
> +   cmd_size_in_dw += intel_pxp_cmd_add_prolog(pxp, NULL, 
> ARB_SESSION_TYPE, ARB_SESSION_INDEX);
> +   cmd_size_in_dw += intel_pxp_cmd_add_inline_termination(NULL);
> +   cmd_size_in_dw += intel_pxp_cmd_add_epilog(NULL);
> +
> +   cmd = kzalloc(cmd_size_in_dw * 4, GFP_KERNEL);
> +   if (!cmd)
> +   return -ENOMEM;
> +
> +   /* Program the command */
> +   cmd_ptr = cmd;
> +   cmd_ptr += intel_pxp_cmd_add_prolog(pxp, cmd_ptr, ARB_SESSION_TYPE, 
> ARB_SESSION_INDEX);
> +   cmd_ptr += intel_pxp_cmd_add_inline_termination(cmd_ptr);
> +   cmd_ptr += intel_pxp_cmd_add_epilog(cmd_ptr);
> +
> +   if (cmd_size_in_dw != (cmd_ptr - cmd)) {
> +   ret = -EINVAL;
> +   drm_err(>->i915->drm, "Failed to %s\n", __func__);
> +   goto end;
> +   }
> +
> +   if (drm_debug_enabled(DRM_UT_DRIVER)) {
> +   print_hex_dump(KERN_DEBUG, "global termination cmd binaries:",
> +  DUMP_PREFIX_OFFSET, 4, 4, cmd, cmd_size_in_dw 
> * 4, true);
> +   }
> +
> +   ret = intel_pxp_cmd_submit(pxp, cmd, cmd_size_in_dw);
> +   if (ret) {
> +   drm_err(>->i915->drm, "Failed to intel_pxp_cmd_submit()\n");
> +   goto end;
> +   }
> +
> +end:
> +   kfree(cmd);
> +   return ret;
> +}
> +
> +/**
> + * intel_pxp_arb_terminate_session - Terminate the arb hw session and its 
> entries.
> + * @pxp: pointer to pxp struct.
> + *
> + * This function is NOT intended to be called from the ioctl, and need to be 
> protected by
> + * ctx.mutex to ensure no SIP change during the call.
> + *
> + * Return: status. 0 means terminate is successful.
> + */
> +int intel_pxp_arb_terminate_session(struct intel_pxp *pxp)
> +{
> +   int ret;
> +   struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
> +   struct pxp_protected_session *arb = pxp->ctx.arb_session;
> +
> +   lockdep_assert_held(&pxp->ctx.mutex);
> +
> +   /* terminate the hw sessions */
> +   ret = intel_pxp_arb_session_with_global_termination(pxp);
> +   if (ret) {
> +   drm_err(>->i915->drm, "Failed to 
> intel_pxp_arb_session_with_global_termination\n");
> +   return ret;
> +   }
> +
> +   kfree(arb);
> +
> +   return ret;
> +}
> +
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.h 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
> index e410c0bbdcc3..d7b3b05a4314 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
> @@ -32,5 +32,6 @@ struct pxp_protecte

Re: [Intel-gfx] [RFC-v3 06/13] drm/i915/pxp: Enable PXP irq worker and callback stub

[Joonas Lahtinen]

Quoting Huang, Sean Z (2020-12-09 09:03:00)
> Create the irq worker that serves as callback handler, those
> callback stubs should be called while the hardware key teardown
> occurs.
> 
> Signed-off-by: Huang, Sean Z 



> +static int intel_pxp_global_terminate_complete_callback(struct intel_pxp 
> *pxp)
> +{
> +   int ret = 0;
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +
> +   mutex_lock(&pxp->ctx.mutex);
> +
> +   if (pxp->ctx.global_state_attacked) {
> +   pxp->ctx.global_state_attacked = false;

This software tracking should not be needed.

> +
> +   /* Re-create the arb session after teardown handle complete */
> +   ret = intel_pxp_arb_create_session(pxp);
> +   if (ret) {
> +   drm_err(>->i915->drm, "Failed to create arb 
> session\n");
> +   goto end;
> +   }
> +   }
> +end:
> +   mutex_unlock(&pxp->ctx.mutex);
> +   return ret;
> +}
> +
> +static void intel_pxp_irq_work(struct work_struct *work)
> +{
> +   struct intel_pxp *pxp = container_of(work, typeof(*pxp), irq_work);
> +   struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
> +   u32 events = 0;
> +
> +   spin_lock_irq(>->irq_lock);
> +   events = fetch_and_zero(&pxp->current_events);

"current_events" is not a great name for variable to be handled by
irq_work function.

> +   spin_unlock_irq(>->irq_lock);
> +
> +   if (events & PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED ||
> +   events & PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ)
> +   intel_pxp_teardown_required_callback(pxp);

On this path we should go and invalidate all contexts and buffer objects
that are created with PROTECTED_CONTENT flag.

We should only track the lack of the single session, and hold off from
submitting any newly created contexts until the next event.

> +
> +   if (events & PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE)
> +   intel_pxp_global_terminate_complete_callback(pxp);

After this, we should be able to proceed with creation/usage of
PROTECTED_CONTENT flagged items as the session is available.

I only see the session being created and other software tracking I'm not
following exactly.

So the only boolean state we should track is if the arb_session is valid
or is "in play" as the terminology seems to be.

Regards, Joonas

> +
> +   spin_lock_irq(>->irq_lock);
> +   intel_pxp_write_irq_mask_reg(gt, 0);
> +   spin_unlock_irq(>->irq_lock);
> +}

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression

[Joonas Lahtinen]

+ intel-gfx

Quoting Rong Chen (2020-12-10 08:54:59)
> 
> 
> On 11/13/20 10:27 PM, Joonas Lahtinen wrote:
> > Hi,
> >
> > Could you add intel-gfx@lists.freedesktop.org into reports going
> > forward.
> 
> Hi Joonas,
> 
> Sorry for the late, which kind of issue that needs to be forwarded?

When sending the regression notifications, it would be useful to include
the mailing lists from MAINTAINERS file based on the files being touched
by the bisected commit.

That would help bringing the right attention and be especially important
for the cases where the patch author has become inactive (changed jobs
or e-mail, etc.)

Regards, Joonas

> Best Regards,
> Rong Chen
> 
> >
> > Quoting kernel test robot (2020-11-11 17:58:11)
> >> Greeting,
> >>
> >> FYI, we noticed a -54.0% regression of 
> >> phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> >>  due to commit:
> > How many runs are there on the bad version to ensure the bisect is
> > repeatable?
> >
> > According to Chris test has various factors affecting why the result
> > could fluctuate and has been known. Reverting the patch did not have
> > an effect on the benchmark and was not expected to do so, either.
> >
> > Is there some mechanism to queue a re-run?
> >
> > Would it make sense to do further runs before sending out the e-mail
> > to avoid false positives.
> >
> > It could of course be also solved by sticking to tests that have less
> > fluctuation in them.
> >
> > Regards, Joonas
> >
> >>
> >> commit: 59dd13ad310793757e34afa489dd6fc8544fc3da ("drm/i915/gem: Flush 
> >> coherency domains on first set-domain-ioctl")
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> >>
> >>
> >> in testcase: phoronix-test-suite
> >> on test machine: 12 threads Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 
> >> 8G memory
> >> with following parameters:
> >>
> >>  need_x: true
> >>  test: jxrendermark-1.2.4
> >>  option_a: Radial Gradient Paint
> >>  option_b: 1024x1024
> >>  cpufreq_governor: performance
> >>  ucode: 0xd6
> >>
> >> test-description: The Phoronix Test Suite is the most comprehensive 
> >> testing and benchmarking platform available that provides an extensible 
> >> framework for which new tests can be easily added.
> >> test-url: http://www.phoronix-test-suite.com/
> >>
> >>
> >>
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kernel test robot 
> >>
> >>
> >> Details are as below:
> >> -->
> >>
> >>
> >> To reproduce:
> >>
> >>  git clone https://github.com/intel/lkp-tests.git
> >>  cd lkp-tests
> >>  bin/lkp install job.yaml  # job file is attached in this email
> >>  bin/lkp run job.yaml
> >>
> >> =
> >> compiler/cpufreq_governor/kconfig/need_x/option_a/option_b/rootfs/tbox_group/test/testcase/ucode:
> >>gcc-9/performance/x86_64-rhel-8.3/true/Radial Gradient 
> >> Paint/1024x1024/debian-x86_64-phoronix/lkp-cfl-d1/jxrendermark-1.2.4/phoronix-test-suite/0xd6
> >>
> >> commit:
> >>0dccdba51e ("Merge tag 'gvt-fixes-2020-10-30' of 
> >> https://github.com/intel/gvt-linux into drm-intel-fixes")
> >>59dd13ad31 ("drm/i915/gem: Flush coherency domains on first 
> >> set-domain-ioctl")
> >>
> >> 0dccdba51e852271 59dd13ad310793757e34afa489d
> >>  ---
> >>   %stddev %change %stddev
> >>   \  |\
> >>8980 ±  2% -54.0%   4127
> >> phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> >>9.00   +13.9%  10.25 ±  4%  
> >> phoronix-test-suite.time.percent_of_cpu_this_job_got
> >>
> >>
> >>
> >>   
> &

Re: [Intel-gfx] [PATCH] drm/i915/gt: Add a comment about how to use udev for configuring engines

[Joonas Lahtinen]

Quoting Chris Wilson (2020-12-21 15:01:05)
> We expose engine properties under sysfs so that the sysadmin can
> configure the driver according to their requirements. We can also use
> udev rules to then apply that configuration anytime a device is
> reloaded. Include a udev snippet provided by Joonas as an example.
> 
> v2: Update the snippet
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/gt/sysfs_engines.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c 
> b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> index 9cf943b6a44b..37f078e69a42 100644
> --- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
> +++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> @@ -11,6 +11,22 @@
>  #include "intel_engine_heartbeat.h"
>  #include "sysfs_engines.h"
>  
> +/*
> + * The sysfs provides a means for configuring each engine for the intended
> + * usecase, and by utilising a udev the configuration can be made persistent
> + * across reboots and device rebinding.
> + *
> + * An example udev rule to run a custom sysadmin script would be,
> + * /etc/udev/rules.d/50-intel-gpu.rules:
> + *
> + * 
> ACTION=="bind|add",SUBSYSTEM=="pci",DRIVER=="i915",RUN+="/usr/local/libexec/i915-disable-preempt-timeout.sh"
> + *
> + * where the script receives the device name and can open the sysfs, e.g.:
> + * for ENGINE in $(find /sys/$DEVPATH/drm/card?/engine -maxdepth 1) do
> + *   echo 0 > $ENGINE/preempt_timeout_ms # Disable reset on preemption 
> failure
> + * done
> + */

If we just could get this into the output of 'make htmldocs', it would
be good.

Regards, Joonas

> +
>  struct kobj_engine {
> struct kobject base;
> struct intel_engine_cs *engine;
> -- 
> 2.20.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v19 02/13] drm/i915/pxp: set KCR reg init during the boot time

[Joonas Lahtinen]

Quoting Vivi, Rodrigo (2021-01-07 17:31:36)
> On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> > Set the KCR init during the boot time, which is
> > required by hardware, to allow us doing further
> > protection operation such as sending commands to
> > GPU or TEE.
> > 
> > Signed-off-by: Huang, Sean Z 
> > ---
> >  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > index 9bc3c7e30654..f566a4fda044 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > @@ -6,6 +6,12 @@
> >  #include "intel_pxp.h"
> >  #include "intel_pxp_context.h"
> >  
> > +/* KCR register definitions */
> 
> please define this in i915_reg.h

Generally the trend on the GT side is to contain in a .c file if there are
no shared users like these. So they should be at this spot, yet the rest
of the review comments apply.

The spurious comments should be dropped and like Rodrigo pointed out, we
should be using the appropriate macros for a masked writes, not baking in
the #define.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v19 00/13] Introduce Intel PXP component - Mesa single session

[Joonas Lahtinen]

Quoting Vivi, Rodrigo (2021-01-07 17:42:12)
> On Wed, 2021-01-06 at 15:12 -0800, Huang, Sean Z wrote:
> > PXP (Protected Xe Path) is an i915 component, available on
> > GEN12+ that helps to establish the hardware protected session
> > and manage the status of the alive software session, as well
> > as its life cycle.
> > 
> > This patch series is to allow the kernel space to create and
> > manage a single hardware session (a.k.a. default session or
> > arbitrary session). So user can allocate the protected buffer,
> > which is encrypted with the leverage of the arbitrary hardware
> > session.
> > 
> > v2:
> >     - modification based on code review feedbacks received
> >     - passing pxp instead of i915 as function argument
> >     - remove dead code only for multi-session
> >     - move the pxp init call from i915_drv.c to intel_gt.c
> >     - remove the tautology naming
> > 
> > v3:
> >     - rebase to latest drm-tip
> > 
> > v4:
> >     - Append the split non-mesa patch sereis (commit #14 - #21) into
> >   this patch series
> > 
> > v5:
> >     - include "intel_pxp.h" in intel_pxp_sm.h at commit #14 to fix
> >   the build problem.
> > 
> > v6:
> >     - Fix the null pointer arb_session access bug in intel_pxp_arb.c
> > in
> >   "04 [RFC-v5] drm/i915/pxp: Create the arbitrary session after
> >   boot"
> > 
> > v7:
> >     - Use list_for_each_entry_safe instead of list_for_each_entry
> > 
> > v8:
> >     - Add MEI vtag support for PXP multi-session usage
> > 
> > v9:
> >     - Fix error handling bug in commit #5 "Func to send hardware
> > session
> >   termination". In intel_pxp_cmd.c, we should properly assign
> >   "err = PTR_ERR(x)" if hitting the error case "IS_ERR(x)", this
> > is
> >   the only change in v9.
> > 
> > v10
> >     - Remove the multi session commits #14-#21, for now we would like
> > to
> >   keep the multi session patches as downstream.
> >     - Adopt the code review suggestion from Wilson in commit #1
> > 
> > v11
> >     - In commit #05 "drm/i915/pxp: Func to send hardware session
> >   termination", we should not assume VCS0 is always on.
> >   Instead we use available VCS#, could be VCS0, VCS2, etc.
> > 
> > v12
> >     - Add "#include  in #1 intel_pxp_types.h
> > 
> > v13
> >     - Add "#include  in #1 intel_pxp_types.h (#v12
> > didn't
> >   actually update the _types.h file...)
> > 
> > v14
> >     - Add "if (INTEL_GEN(gt->i915) < 12) return;" in #1
> >   intel_pxp_fini(), just skip for non gen12+ sku
> > 
> > v15
> >     In #04:
> >     - Make intel_pxp_arb_reserve_session() as static function to fix
> > the
> >   sparse warning
> >     - Update value of PXP_TEE_ARB_CMD_BIN 
> > 
> > v16
> >     In #04:
> >     - Remove the binary from source code via defining the TEE command
> >   header
> > 
> > v17
> >     - In #04, directly return intel_pxp_tee_component_fini() if
> >   pxp_tee_comp_added is off
> > 
> > v18
> >     - In #09, Add intel_pxp_gem_context_set_protected() to check the
> > arb
> >   session before setting protected flag for gem context
> > 
> >     - In #12, Replace i915_gem_context_set_protected() with
> >   intel_pxp_gem_context_set_protected() to check whether the
> > arbitrary
> >   session is alive
> > 
> > v19
> >     - In #01, put intel_pxp_fini() in intel_gt_driver_remove()
> > instead of
> >   intel_gt_driver_release() since intel_gt_driver_release() is
> > the last
> >   stage of i915 unbind and we shouldn't call the component_del
> > here.
> > 
> >     - In #04, check if arbitrary session is alive before
> >   intel_pxp_arb_create_session()
> 
> Please reduce the amount of series revision and start using --in-reply-
> to so we can easily see what was addressed from the previous comments
> versus what is open.

CI doesn't always work nicely with --in-reply-to :/

The changes made to each patch should be noted in the commit message of
the patch, not just in the cover letter. And level of detail of the
changes doesn't need to be verbose.

That way when reviewing v10 after v9, reviewer can also can through
patches which have v10 change entry in them.

Use trybot instead of the mailing list to catch things like missing
includes, so those should not result in new revisions. Only send to the
mailing list a new revision that you have checked to compile and fully
work.

But most importantly, I notice plenty of previously given feedback that
is unaddressed (type0/type1, unnecessary variables like session type
etc. that can only have single value in this series). So all of the
previous feedback needs addressing before continuing the review.

There is lot to be fixed about the coding style to match surroundings,
but that only makes sense as the last step after the series is otherwise
ready.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

ad C0DRB3/C1DRB3 as 16 bits again and add _BW suffix (Ville)
- Remove reference to struct drm_device.pdev (Thomas)
- Increase separation between GuC and execlists code (Chris, Matt B)

- Use might_alloc() (Bernard)
- Split DGFX_FEATURES from GEN12_FEATURES (Lucas)
- Deduplicate Wa_22010271021 programming on (Jose)
- Drop duplicate WaDisable4x2SubspanOptimization:hsw (Tvrtko)
- Selftest improvements (Chris, Hsin-Yi, Tvrtko)
- Shuffle around init_memory_region for stolen (Matt)
- Typo fixes (wengjianfeng)


Abdiel Janulgue (1):
  drm/i915/query: Expose memory regions through the query uAPI

Aditya Swarup (1):
  drm/i915: Add Wa_14010733141

Anusha Srivatsa (1):
  drm/i915/lmem: Bypass aperture when lmem is available

Bernard Zhao (1):
  drm/i915: Use might_alloc()

CQ Tang (2):
  drm/i915: Create stolen memory region from local memory
  drm/i915/stolen: enforce the min_page_size contract

Caz Yokoyama (2):
  drm/i915/gen12: Add recommended hardware tuning value
  drm/i915/icl: add Wa_22010271021 for all gen11

Chris Wilson (6):
  drm/i915/selftests: Skip aperture remapping selftest where there is no 
aperture
  drm/i915/selftests: Only query RAPL for integrated power measurements
  drm/i915/gem: Pin the L-shape quirked object as unshrinkable
  drm/i915/gt: Move engine setup out of set_default_submission
  drm/i915/gt: Move submission_method into intel_gt
  drm/i915/gt: Move CS interrupt handler to the backend

Hsin-Yi Wang (1):
  drm/i915/selftests: Rename pm_ prefixed functions names

Janusz Krzysztofik (1):
  drm/i915/gt: Do release kernel context if breadcrumb measure fails

Joonas Lahtinen (1):
  Merge tag 'topic/intel-gen-to-ver-2021-04-19' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next

José Roberto de Souza (1):
  drm/i915: Move Wa_16011163337 to gen12_ctx_workarounds_init()

Lv Yunlong (1):
  drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdp

Maarten Lankhorst (4):
  drm/i915: Fix docbook descriptions for i915_gem_shrinker
  drm/i915: Fix docbook descriptions for i915_cmd_parser
  drm/i915: Use trylock in shrinker for ggtt on bsw vt-d and bxt, v2.
  drm/i915: Remove erroneous i915_is_ggtt check for 
I915_GEM_OBJECT_UNBIND_VM_TRYLOCK

Matt Roper (1):
  drm/i915/lmem: Fail driver init if LMEM training failed

Matthew Auld (19):
  drm/i915/uapi: fix kernel doc warnings
  drm/i915/uapi: convert i915_user_extension to kernel doc
  drm/i915/uapi: convert i915_query and friend to kernel doc
  drm/doc: add section for driver uAPI
  drm/i915/stolen: treat stolen local as normal local memory
  drm/i915/stolen: actually mark as contiguous
  drm/i915/gtt: map the PD up front
  drm/i915/gtt/dgfx: place the PD in LMEM
  drm/doc/rfc: i915 DG1 uAPI
  drm/i915: mark stolen as private
  drm/i915: rework gem_create flow for upcoming extensions
  drm/i915/uapi: introduce drm_i915_gem_create_ext
  drm/i915/uapi: implement object placement extension
  drm/i915/lmem: support optional CPU clearing for special internal use
  drm/i915/gem: clear userspace buffers for LMEM
  drm/i915/gem: hide new uAPI behind CONFIG_BROKEN
  drm/i915: drop the __i915_active_call pointer packing
  drm/i915/stolen: shuffle around init_memory_region
  drm/doc/rfc: drop the i915_gem_lmem.h header

Mohammed Khajapasha (2):
  drm/i915/fbdev: Use lmem physical addresses for fb_mmap() on discrete
  drm/i915: Return error value when bo not in LMEM for discrete

Stéphane Marchesin (1):
  drm/i915: Fix crash in auto_retire

Swathi Dhanavanthri (1):
  drm/i915: Add Wa_14011060649

Thomas Zimmermann (1):
  drm/i915/gem: Remove reference to struct drm_device.pdev

Tvrtko Ursulin (6):
  drm/i915: Take request reference before arming the watchdog timer
  drm/i915/pmu: Check actual RC6 status
  drm/i915/overlay: Fix active retire callback alignment
  drm/i915/selftests: Fix active retire callback alignment
  drm/i915: Drop duplicate WaDisable4x2SubspanOptimization:hsw
  drm/i915/params: Align visibility of device level and global modparams

Venkata Ramana Nayana (1):
  drm/i915/dg1: Fix mapping type for default state object

Venkata Sandeep Dhanalakota (1):
  drm/i915: Update the helper to set correct mapping

Ville Syrjälä (3):
  drm/i915: Avoid div-by-zero on gen2
  drm/i915: Read C0DRB3/C1DRB3 as 16 bits again
  drm/i915: Give C0DRB3/C1DRB3 a _BW suffix

wengjianfeng (1):
  drm/i915/gt: fix typo issue

 Documentation/gpu/driver-uapi.rst  |   8 +
 Documentation/gpu/index.rst|   1 +
 Documentation/gpu/rfc/i915_gem_lmem.rst| 131 +++
 Documentation/gpu/rfc/index.rst|   4 +
 drivers/gpu/drm/i915/display/intel_display.c   |  10 +
 drivers/g

Re: [Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-05-28 10:25:57)
> Hi Dave & Daniel,
> 
> Here's drm-intel-gt-next pull request.
> 
> Most notably it has the reworked DG1 uAPI (behind CONFIG_BROKEN)
> as requested. Important fix for Gitlab issues #3293 and #3450 and
> one another kernel crash. Adds missing workarounds for Gen11 and
> Gen12. Hiding of modparams for compiled-out features. Conversion
> to use trylock shrinking for BSW VT-d and BXT.
> 
> Then there are the uAPI kerneldoc improvements as part of the DG1
> uAPI rework. Usual amount smaller fixes, code refactoring and
> cleanups as prep for upcoming patches.

And includes tag 'topic/intel-gen-to-ver-2021-04-19' (but that is
already merged to drm-next).

Regards, Joonas

> Regards, Joonas
> 
> ***
> 
> drm-intel-gt-next-2021-05-28:
> 
> UAPI Changes:
> - Add reworked uAPI for DG1 behind CONFIG_BROKEN (Matt A, Abdiel)
> 
> Driver Changes:
> 
> - Fix for Gitlab issues #3293 and #3450:
>   Avoid kernel crash on older L-shape memory machines
> 
> - Hide modparams for compiled-out features (Tvrtko)
> - Add Wa_14010733141 (VDBox SFC reset) for Gen11+ (Aditya)
> - Fix crash in auto_retire active retire callback due to
>   misalignment (Stephane)
> - Use trylock in shrinker for GGTT on BSW VT-d and BXT (Maarten)
> - Fix overlay active retire callback alignment (Tvrtko)
> - Eliminate need to align active retire callbacks (Matt A, Ville,
>   Daniel)
> - Program FF_MODE2 tuning value for all Gen12 platforms (Caz)
> - Add Wa_14011060649 for TGL,RKL,DG1 and ADLS (Swathi)
> - Create stolen memory region from local memory on DG1 (CQ)
> - Place PD in LMEM on dGFX (Matt A)
> - Use WC when default state object is allocated in LMEM (Venkata)
> - Determine the coherent map type based on object location (Venkata)
> - Use lmem physical addresses for fb_mmap() on discrete (Mohammed)
> - Bypass aperture on fbdev when LMEM is available (Anusha)
> - Return error value when displayable BO not in LMEM for dGFX (Mohammed)
> - Do release kernel context if breadcrumb measure fails (Janusz)
> - Apply Wa_22010271021 for all Gen11 platforms (Caz)
> - Fix unlikely ref count race in arming the watchdog timer (Tvrtko)
> - Check actual RC6 enable status in PMU (Tvrtko)
> - Fix a double free in gen8_preallocate_top_level_pdp (Lv)
> - Remove erroneous i915_is_ggtt check for
>   I915_GEM_OBJECT_UNBIND_VM_TRYLOCK (Maarten)
> 
> - Convert uAPI headers to real kerneldoc (Matt A)
> - Clean up kerneldoc warnings headers (Matt A, Maarten)
> - Fail driver if LMEM training failed (Matt R)
> - Avoid div-by-zero on Gen2 (Ville)
> - Read C0DRB3/C1DRB3 as 16 bits again and add _BW suffix (Ville)
> - Remove reference to struct drm_device.pdev (Thomas)
> - Increase separation between GuC and execlists code (Chris, Matt B)
> 
> - Use might_alloc() (Bernard)
> - Split DGFX_FEATURES from GEN12_FEATURES (Lucas)
> - Deduplicate Wa_22010271021 programming on (Jose)
> - Drop duplicate WaDisable4x2SubspanOptimization:hsw (Tvrtko)
> - Selftest improvements (Chris, Hsin-Yi, Tvrtko)
> - Shuffle around init_memory_region for stolen (Matt)
> - Typo fixes (wengjianfeng)
> 
> The following changes since commit 425390c5dce6da76578389629d19517fcd79c959:
> 
>   drm/i915: split dgfx features from gen 12 (2021-04-14 13:05:06 +0300)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/drm-intel-gt-next-2021-05-28
> 
> for you to fetch changes up to 5b26d57fdb499c2363f3d895ef008e73ec02eb9b:
> 
>   drm/i915: Add Wa_14010733141 (2021-05-27 11:05:09 -0700)
> 
> 
> UAPI Changes:
> - Add reworked uAPI for DG1 behind CONFIG_BROKEN (Matt A, Abdiel)
> 
> Driver Changes:
> 
> - Fix for Gitlab issues #3293 and #3450:
>   Avoid kernel crash on older L-shape memory machines
> 
> - Add Wa_14010733141 (VDBox SFC reset) for Gen11+ (Aditya)
> - Fix crash in auto_retire active retire callback due to
>   misalignment (Stephane)
> - Fix overlay active retire callback alignment (Tvrtko)
> - Eliminate need to align active retire callbacks (Matt A, Ville,
>   Daniel)
> - Program FF_MODE2 tuning value for all Gen12 platforms (Caz)
> - Add Wa_14011060649 for TGL,RKL,DG1 and ADLS (Swathi)
> - Create stolen memory region from local memory on DG1 (CQ)
> - Place PD in LMEM on dGFX (Matt A)
> - Use WC when default state object is allocated in LMEM (Venkata)
> - Determine the coherent map type based on object location (Venkata)
> - Use lmem physical addresses for fb_mmap() on discrete (Mohammed)
> - Bypass aperture on fbdev when LMEM is available (Anusha)
> - Return error value when displayable BO not in LMEM for dGF

Re: [Intel-gfx] i915 and swiotlb_max_segment

[Joonas Lahtinen]

+ Tvrtko to take a look

Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> > 
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> > 
> > swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> > SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> > size when swiotlb is otherwise enabled.
> > 
> > i915 then uses it to:
> > 
> >  a) decided on the max order in i915_gem_object_get_pages_internal
> >  b) decide on a max segment size in i915_sg_segment_size
> > 
> > for a) it really seems i915 should switch to dma_alloc_noncoherent
> > or dma_alloc_noncontigous ASAP instead of using alloc_page and
> > streaming DMA mappings.  Any chance I could trick one of the i915
> > maintaines into doing just that given that the callchain is not
> > exactly trivial?
> > 
> > For b) I'm not sure swiotlb and i915 really agree on the meaning
> > of the value.  swiotlb_set_max_segment basically returns the entire
> > size of the swiotlb buffer, while i915 seems to use it to limit
> > the size each scatterlist entry.  It seems like dma_max_mapping_size
> > might be the best value to use here.
> 
> Yes. The background behind that was SWIOTLB would fail because well, the
> size of the sg was too large. And some way to limit it to max size
> was needed - the dma_max_mapping_size "should" be just fine.
> 
> > 
> > Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> > a horribly confusing API.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Daniel,

Here's the final -gt-next PR for 5.14.

Two major uAPI changes for new Gen12+ platforms: Stop supporting
old MMAP IOCTL (excl. TGL) and require use of MMAP_OFFSET instead.
Start enabling HuC loading by default (excl. TGL and RKL).

Revert for io_mapping_map_user which was already in -fixes.

Enabling of the TTM device and memory managers for handling LMEM
on dGFX (currently replaces the buddy allocator). Note that this
only impacts the platforms behind force probe protection.

A lot of improvments to the GuC submission backend to prepare for
enabling on newer platforms.

Only a couple other reworks and fixes.

Regards, Joonas

***

drm-intel-gt-next-2021-06-10:

UAPI Changes:

- Disable mmap ioctl for gen12+ (excl. TGL-LP)
- Start enabling HuC loading by default for upcoming Gen12+
  platforms (excludes TGL and RKL)

Core Changes:

- Backmerge of drm-next

Driver Changes:

- Revert "i915: use io_mapping_map_user" (Eero, Matt A)
- Initialize the TTM device and memory managers (Thomas)
- Major rework to the GuC submission backend to prepare
  for enabling on new platforms (Michal Wa., Daniele,
  Matt B, Rodrigo)
- Fix i915_sg_page_sizes to record dma segments rather
  than physical pages (Thomas)

- Locking rework to prep for TTM conversion (Thomas)
- Replace IS_GEN and friends with GRAPHICS_VER (Lucas)
- Use DEVICE_ATTR_RO macro (Yue)
- Static code checker fixes (Zhihao)

The following changes since commit ccd1950c2f7e38ae45aeefb99a08b39407cd6c63:

  Merge tag 'drm-intel-gt-next-2021-05-28' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-06-02 14:15:54 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-06-10

for you to fetch changes up to 47c65b3853f88d105017ef512a521794db51bfeb:

  drm/i915/uc: Use platform specific defaults for GuC/HuC enabling (2021-06-09 
10:52:03 -0700)


UAPI Changes:

- Disable mmap ioctl for gen12+ (excl. TGL-LP)
- Start enabling HuC loading by default for upcoming Gen12+
  platforms (excludes TGL and RKL)

Core Changes:

- Backmerge of drm-next

Driver Changes:

- Revert "i915: use io_mapping_map_user" (Eero, Matt A)
- Initialize the TTM device and memory managers (Thomas)
- Major rework to the GuC submission backend to prepare
  for enabling on new platforms (Michal Wa., Daniele,
  Matt B, Rodrigo)
- Fix i915_sg_page_sizes to record dma segments rather
  than physical pages (Thomas)

- Locking rework to prep for TTM conversion (Thomas)
- Replace IS_GEN and friends with GRAPHICS_VER (Lucas)
- Use DEVICE_ATTR_RO macro (Yue)
- Static code checker fixes (Zhihao)


Daniele Ceraolo Spurio (4):
  drm/i915/guc: skip disabling CTBs before sanitizing the GuC
  drm/i915/guc: use probe_error log for CT enablement failure
  drm/i915/guc: enable only the user interrupt when using GuC submission
  drm/i915/guc: Use guc_class instead of engine_class in fw interface

John Harrison (1):
  drm/i915/uc: Use platform specific defaults for GuC/HuC enabling

Joonas Lahtinen (1):
  Merge drm/drm-next into drm-intel-gt-next

Lucas De Marchi (3):
  drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER
  drm/i915/gt: Add remaining conversions to GRAPHICS_VER
  drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER

Maarten Lankhorst (1):
  drm/i915: Disable mmap ioctl for gen12+

Matthew Auld (1):
  Revert "i915: use io_mapping_map_user"

Matthew Brost (2):
  drm/i915/guc: Drop guc->interrupts.enabled
  drm/i915/guc: Ensure H2G buffer updates visible before tail update

Michal Wajdeczko (12):
  drm/i915/guc: Keep strict GuC ABI definitions
  drm/i915/guc: Stop using fence/status from CTB descriptor
  drm/i915: Promote ptrdiff() to i915_utils.h
  drm/i915/guc: Only rely on own CTB size
  drm/i915/guc: Don't repeat CTB layout calculations
  drm/i915/guc: Replace CTB array with explicit members
  drm/i915/guc: Update sizes of CTB buffers
  drm/i915/guc: Start protecting access to CTB descriptors
  drm/i915/guc: Stop using mutex while sending CTB messages
  drm/i915/guc: Don't receive all G2H messages in irq handler
  drm/i915/guc: Always copy CT message to new allocation
  drm/i915/guc: Early initialization of GuC send registers

Rodrigo Vivi (1):
  drm/i915/guc: Remove sample_forcewake h2g action

Thomas Hellström (5):
  drm/i915: Untangle the vma pages_mutex
  drm/i915: Don't free shared locks while shared
  drm/i915: Fix i915_sg_page_sizes to record dma segments rather than 
physical pages
  drm/i915/ttm Initialize the ttm device and memory managers
  drm/i915/ttm: Embed a ttm buffer object in the i915 gem object

YueHaibing (1):
  drm/i915: use DEVICE_ATTR_RO macro

Zh

Re: [Intel-gfx] Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c

[joonas . lahtinen]

+ Jesse

Quoting Colin Ian King (2021-06-09 14:50:07)
> Hi,
> 
> I was reviewing some old unassigned variable warnings from static
> analysis by Coverity and found an issue introduced with the following
> commit:
> 
> commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> Author: Jesse Barnes 
> Date:   Fri May 14 15:41:14 2010 -0700
> 
> x86 platform driver: intelligent power sharing driver
> 
> The analysis is as follows:
> 
> drivers/platform/x86/intel_ips.c
> 
>  871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, int period)
>  872 {
>  873u32 val;
>  874u32 ret;
>  875
>  876/*
>  877 * CEC is in joules/65535.  Take difference over time to
>  878 * get watts.
>  879 */
>  880val = thm_readl(THM_CEC);
>  881
>  882/* period is in ms and we want mW */
>  883ret = (((val - *last) * 1000) / period);
> 
> Unused value (UNUSED_VALUE)
> assigned_value:  Assigning value from ret * 1000U / 65535U to ret here,
> but that stored value is not used.
> 
>  884ret = (ret * 1000) / 65535;
>  885*last = val;
>  886
>  887return 0;
>  888 }
> 
> I'm really not sure why ret is being calculated on lines 883,884 and not
> being used. Should that be *last = ret on line 885? Looks suspect anyhow.

According to git blame code seems to have been disabled intentionally by the
following commit:

commit 96f3823f537088c13735cfdfbf284436c802352a
Author: Jesse Barnes 
Date:   Tue Oct 5 14:50:59 2010 -0400

[PATCH 2/2] IPS driver: disable CPU turbo

The undocumented interface we're using for reading CPU power seems to be
overreporting power.  Until we figure out how to correct it, disable CPU
turbo and power reporting to be safe.  This will keep the CPU within default
limits and still allow us to increase GPU frequency as needed.

Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up
wanting to fix it? Or eliminate completely.

In theory the thm_readl() may affect the system behavior so would not
remove that for extra paranoia.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Computation of return value being discarded in get_cpu_power() in drivers/platform/x86/intel_ips.c

[Joonas Lahtinen]

(Address for Hans was corrupt in previous message, which confused my mail
client. Sorry for duplicate message, the other is without From: field).

+ Jesse

Quoting Colin Ian King (2021-06-09 14:50:07)
> Hi,
> 
> I was reviewing some old unassigned variable warnings from static
> analysis by Coverity and found an issue introduced with the following
> commit:
> 
> commit aa7ffc01d254c91a36bf854d57a14049c6134c72
> Author: Jesse Barnes 
> Date:   Fri May 14 15:41:14 2010 -0700
> 
> x86 platform driver: intelligent power sharing driver
> 
> The analysis is as follows:
> 
> drivers/platform/x86/intel_ips.c
> 
>  871 static u32 get_cpu_power(struct ips_driver *ips, u32 *last, int period)
>  872 {
>  873u32 val;
>  874u32 ret;
>  875
>  876/*
>  877 * CEC is in joules/65535.  Take difference over time to
>  878 * get watts.
>  879 */
>  880val = thm_readl(THM_CEC);
>  881
>  882/* period is in ms and we want mW */
>  883ret = (((val - *last) * 1000) / period);
> 
> Unused value (UNUSED_VALUE)
> assigned_value:  Assigning value from ret * 1000U / 65535U to ret here,
> but that stored value is not used.
> 
>  884ret = (ret * 1000) / 65535;
>  885*last = val;
>  886
>  887return 0;
>  888 }
> 
> I'm really not sure why ret is being calculated on lines 883,884 and not
> being used. Should that be *last = ret on line 885? Looks suspect anyhow.

According to git blame code seems to have been disabled intentionally by the
following commit:
  
commit 96f3823f537088c13735cfdfbf284436c802352a
Author: Jesse Barnes 
Date:   Tue Oct 5 14:50:59 2010 -0400
  
[PATCH 2/2] IPS driver: disable CPU turbo
  
The undocumented interface we're using for reading CPU power seems to be
overreporting power.  Until we figure out how to correct it, disable CPU
turbo and power reporting to be safe.  This will keep the CPU within default
limits and still allow us to increase GPU frequency as needed.
  
Maybe wrap the code after thm_readl() in #if 0 in case somebody ends up
wanting to fix it? Or eliminate completely.
  
In theory the thm_readl() may affect the system behavior so would not
remove that for extra paranoia.
  
Regards, Joonas

> Colin
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> Pull request for drm-misc-next and drm-intel-gt-next.
> 
> topic/i915-ttm-2021-06-11:
> drm-misc and drm-intel pull request for topic/i915-ttm:
> - Convert i915 lmem handling to ttm.
> - Add a patch to temporarily add a driver_private member to vma_node.
> - Use this to allow mixed object mmap handling for i915.
> The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> 
>   Merge tag 'exynos-drm-next-for-v5.14' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> drm-next (2021-06-11 14:19:12 +1000)

This base is not in drm-misc-next or drm-intel-gt-next, so effectively
we would end up pulling 478 extra commits from drm-next as a result. And
also causing all the warnings for those commits. I don't think we should
do that?

The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
"Merge tag 'drm-intel-gt-next-2021-05-28' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next"
Should we re-do the topic branch based on that?

However the DIM docs[1] indeed do say: "For topic branches shared within
the gpu/drm subsystem, base it on the latest drm-next branch." I think
the docs don't take into account the current period where drm-next is
being actively updated as we speak.

Should we update the docs to use 'git merge-base' or something else?

Regards, Joonas

[1]: 
https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches

> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/topic/i915-ttm-2021-06-11
> 
> for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> 
>   drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 +0200)
> 
> 
> drm-misc and drm-intel pull request for topic/i915-ttm:
> - Convert i915 lmem handling to ttm.
> - Add a patch to temporarily add a driver_private member to vma_node.
> - Use this to allow mixed object mmap handling for i915.
> 
> 
> Maarten Lankhorst (2):
>   drm/vma: Add a driver_private member to vma_node.
>   drm/i915: Use ttm mmap handling for ttm bo's.
> 
> Thomas Hellström (2):
>   drm/i915/ttm: Introduce a TTM i915 gem object backend
>   drm/i915/lmem: Verify checks for lmem residency
> 
>  drivers/gpu/drm/drm_gem.c  |   9 -
>  drivers/gpu/drm/i915/Makefile  |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
>  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
>  drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
>  drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
>  drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 
> +
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.h|  48 ++
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  90 +--
>  drivers/gpu/drm/i915/gt/intel_region_lmem.c|   3 +-
>  drivers/gpu/drm/i915/i915_gem.c|   5 +-
>  drivers/gpu/drm/i915/intel_memory_region.c |   1 -
>  drivers/gpu/drm/i915/intel_memory_region.h |   1 -
>  drivers/gpu/drm/i915/intel_region_ttm.c|   8 +-
>  drivers/gpu/drm/i915/intel_region_ttm.h|  11 +-
>  drivers/gpu/drm/i915/selftests/igt_mmap.c  |  25 +-
>  drivers/gpu/drm/i915/selftests/igt_mmap.h  |  12 +-
>  include/drm/drm_vma_manager.h  |   2 +-
>  24 files changed, 1039 insertions(+), 250 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-06-11 13:40:56)
> Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> > Pull request for drm-misc-next and drm-intel-gt-next.
> > 
> > topic/i915-ttm-2021-06-11:
> > drm-misc and drm-intel pull request for topic/i915-ttm:
> > - Convert i915 lmem handling to ttm.
> > - Add a patch to temporarily add a driver_private member to vma_node.
> > - Use this to allow mixed object mmap handling for i915.
> > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> > 
> >   Merge tag 'exynos-drm-next-for-v5.14' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> > drm-next (2021-06-11 14:19:12 +1000)
> 
> This base is not in drm-misc-next or drm-intel-gt-next, so effectively
> we would end up pulling 478 extra commits from drm-next as a result. And
> also causing all the warnings for those commits. I don't think we should
> do that?
> 
> The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
> "Merge tag 'drm-intel-gt-next-2021-05-28' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next"
> Should we re-do the topic branch based on that?

This problem seems to come from the fact that only the PR from yesterday
that got merged to drm-next had the dependency patches. The previous
backmerge of drm-next was requested too early.

I've solved this with least hassle by backmerging drm-next again and
then applying the PR to drm-intel-gt-next.

I think drm-misc-next should do the same (exact commit was
1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2).

Regards, Joonas

> However the DIM docs[1] indeed do say: "For topic branches shared within
> the gpu/drm subsystem, base it on the latest drm-next branch." I think
> the docs don't take into account the current period where drm-next is
> being actively updated as we speak.
> 
> Should we update the docs to use 'git merge-base' or something else?
> 
> Regards, Joonas
> 
> [1]: 
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches
> 
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-misc tags/topic/i915-ttm-2021-06-11
> > 
> > for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> > 
> >   drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 +0200)
> > 
> > 
> > drm-misc and drm-intel pull request for topic/i915-ttm:
> > - Convert i915 lmem handling to ttm.
> > - Add a patch to temporarily add a driver_private member to vma_node.
> > - Use this to allow mixed object mmap handling for i915.
> > 
> > 
> > Maarten Lankhorst (2):
> >   drm/vma: Add a driver_private member to vma_node.
> >   drm/i915: Use ttm mmap handling for ttm bo's.
> > 
> > Thomas Hellström (2):
> >   drm/i915/ttm: Introduce a TTM i915 gem object backend
> >   drm/i915/lmem: Verify checks for lmem residency
> > 
> >  drivers/gpu/drm/drm_gem.c  |   9 -
> >  drivers/gpu/drm/i915/Makefile  |   1 +
> >  drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
> >  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
> >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
> >  drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 
> > +
> >  drivers/gpu/drm/i915/gem/i915_gem_ttm.h|  48 ++
> >  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  90 +--
> >  drivers/gpu/drm/i915/gt/intel_region_lmem.c|   3 +-
> >  drivers/gpu/drm/i915/i915_gem.c|   5 +-
> >  drivers/gpu/drm/i915/intel_memory_region.c |   1 -
> >  drivers/gpu/drm/i915/intel_memory_region.h |   1 -
> >  drivers/gpu/drm/i915/intel_region_ttm.c|   8 +-
> >  drivers/gpu/drm/i915/intel_region_ttm.h|  11 +-
> >  drivers/gpu/drm/i915/selftests/igt_mmap.c  |  25 +-
> >  drivers/gpu/drm/i915/selftests/igt_mmap.h  |  12 +-
> >  include/drm/drm_vma_manager.h  |   2 +-
> >  24 files changed, 1039 insertions(+), 250 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Thomas Zimmermann (2021-06-13 21:54:03)
> Hi Joonas
> 
> Am 11.06.21 um 13:13 schrieb Joonas Lahtinen:
> > Quoting Joonas Lahtinen (2021-06-11 13:40:56)
> >> Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> >>> Pull request for drm-misc-next and drm-intel-gt-next.
> >>>
> >>> topic/i915-ttm-2021-06-11:
> >>> drm-misc and drm-intel pull request for topic/i915-ttm:
> >>> - Convert i915 lmem handling to ttm.
> >>> - Add a patch to temporarily add a driver_private member to vma_node.
> >>> - Use this to allow mixed object mmap handling for i915.
> >>> The following changes since commit 
> >>> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> >>>
> >>>Merge tag 'exynos-drm-next-for-v5.14' of 
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> >>> drm-next (2021-06-11 14:19:12 +1000)
> >>
> >> This base is not in drm-misc-next or drm-intel-gt-next, so effectively
> >> we would end up pulling 478 extra commits from drm-next as a result. And
> >> also causing all the warnings for those commits. I don't think we should
> >> do that?
> >>
> >> The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
> >> "Merge tag 'drm-intel-gt-next-2021-05-28' of 
> >> git://anongit.freedesktop.org/drm/drm-intel into drm-next"
> >> Should we re-do the topic branch based on that?
> > 
> > This problem seems to come from the fact that only the PR from yesterday
> > that got merged to drm-next had the dependency patches. The previous
> > backmerge of drm-next was requested too early.
> > 
> > I've solved this with least hassle by backmerging drm-next again and
> > then applying the PR to drm-intel-gt-next.
> > 
> > I think drm-misc-next should do the same (exact commit was
> > 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2).
> 
> I did a backmerge from drm-next recently and drm-misc-next can merge the 
> patches in tags/topic/i915-ttm-2021-06-11 without additions.
> 
> I assume you to updated drm-intel-gt-next without redoing the PR?

Correct.

Regards, Joonas

> 
> Best regards
> Thomas
> 
> > 
> > Regards, Joonas
> > 
> >> However the DIM docs[1] indeed do say: "For topic branches shared within
> >> the gpu/drm subsystem, base it on the latest drm-next branch." I think
> >> the docs don't take into account the current period where drm-next is
> >> being actively updated as we speak.
> >>
> >> Should we update the docs to use 'git merge-base' or something else?
> >>
> >> Regards, Joonas
> >>
> >> [1]: 
> >> https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches
> >>
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>git://anongit.freedesktop.org/drm/drm-misc 
> >>> tags/topic/i915-ttm-2021-06-11
> >>>
> >>> for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> >>>
> >>>drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 
> >>> +0200)
> >>>
> >>> 
> >>> drm-misc and drm-intel pull request for topic/i915-ttm:
> >>> - Convert i915 lmem handling to ttm.
> >>> - Add a patch to temporarily add a driver_private member to vma_node.
> >>> - Use this to allow mixed object mmap handling for i915.
> >>>
> >>> 
> >>> Maarten Lankhorst (2):
> >>>drm/vma: Add a driver_private member to vma_node.
> >>>drm/i915: Use ttm mmap handling for ttm bo's.
> >>>
> >>> Thomas Hellström (2):
> >>>drm/i915/ttm: Introduce a TTM i915 gem object backend
> >>>drm/i915/lmem: Verify checks for lmem residency
> >>>
> >>>   drivers/gpu/drm/drm_gem.c  |   9 -
> >>>   drivers/gpu/drm/i915/Makefile  |   1 +
> >>>   drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
> >>>   drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
> >>>   drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
> >>>   drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
> >>>   drivers/gpu/drm

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-06-11 14:13:02)
> Quoting Joonas Lahtinen (2021-06-11 13:40:56)
> > Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> > > Pull request for drm-misc-next and drm-intel-gt-next.
> > > 
> > > topic/i915-ttm-2021-06-11:
> > > drm-misc and drm-intel pull request for topic/i915-ttm:
> > > - Convert i915 lmem handling to ttm.
> > > - Add a patch to temporarily add a driver_private member to vma_node.
> > > - Use this to allow mixed object mmap handling for i915.
> > > The following changes since commit 
> > > 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> > > 
> > >   Merge tag 'exynos-drm-next-for-v5.14' of 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> > > drm-next (2021-06-11 14:19:12 +1000)
> > 
> > This base is not in drm-misc-next or drm-intel-gt-next, so effectively
> > we would end up pulling 478 extra commits from drm-next as a result. And
> > also causing all the warnings for those commits. I don't think we should
> > do that?
> > 
> > The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
> > "Merge tag 'drm-intel-gt-next-2021-05-28' of 
> > git://anongit.freedesktop.org/drm/drm-intel into drm-next"
> > Should we re-do the topic branch based on that?
> 
> This problem seems to come from the fact that only the PR from yesterday
> that got merged to drm-next had the dependency patches. The previous
> backmerge of drm-next was requested too early.
> 
> I've solved this with least hassle by backmerging drm-next again and
> then applying the PR to drm-intel-gt-next.

And now I have actually pushed the merge too.. Thanks to Tvrtko
for pointing out broken drm-tip.

Regards, Joonas

> 
> I think drm-misc-next should do the same (exact commit was
> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2).
> 
> Regards, Joonas
> 
> > However the DIM docs[1] indeed do say: "For topic branches shared within
> > the gpu/drm subsystem, base it on the latest drm-next branch." I think
> > the docs don't take into account the current period where drm-next is
> > being actively updated as we speak.
> > 
> > Should we update the docs to use 'git merge-base' or something else?
> > 
> > Regards, Joonas
> > 
> > [1]: 
> > https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches
> > 
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://anongit.freedesktop.org/drm/drm-misc 
> > > tags/topic/i915-ttm-2021-06-11
> > > 
> > > for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> > > 
> > >   drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 
> > > +0200)
> > > 
> > > 
> > > drm-misc and drm-intel pull request for topic/i915-ttm:
> > > - Convert i915 lmem handling to ttm.
> > > - Add a patch to temporarily add a driver_private member to vma_node.
> > > - Use this to allow mixed object mmap handling for i915.
> > > 
> > > 
> > > Maarten Lankhorst (2):
> > >   drm/vma: Add a driver_private member to vma_node.
> > >   drm/i915: Use ttm mmap handling for ttm bo's.
> > > 
> > > Thomas Hellström (2):
> > >   drm/i915/ttm: Introduce a TTM i915 gem object backend
> > >   drm/i915/lmem: Verify checks for lmem residency
> > > 
> > >  drivers/gpu/drm/drm_gem.c  |   9 -
> > >  drivers/gpu/drm/i915/Makefile  |   1 +
> > >  drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
> > >  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
> > >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
> > >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
> > >  drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
> > >  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 
> > > +
> > >  dri

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

es range-based (Matt R)
- Ditch the i915_gem_ww_ctx loop member (Thomas, Maarten)
- Use NULL instead of 0 where appropriate (Ville)
- Rename pci/debugfs functions to respect file prefix (Jani, Lucas)
- Drop guc_communication_enabled (Daniele)
- Selftest fixes (Thomas, Daniel, Matt A, Maarten)
- Clean up inconsistent indenting (Colin)
- Use direction definition DMA_BIDIRECTIONAL instead of
  PCI_DMA_BIDIRECTIONAL (Cai)
- Add "intel_" as prefix in set_mocs_index() (Ayaz)


Akeem G Abodunrin (1):
  drm/i915/dg2: Add new LRI reg offsets

Akira Yokosawa (1):
  drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid

Anshuman Gupta (2):
  drm/i915/pxp: Add plane decryption support
  drm/i915/pxp: black pixels on pxp disabled

Ayaz A Siddiqui (6):
  drm/i915/gt: Add support of mocs propagation
  drm/i915/gt: Set CMD_CCTL to UC for Gen12 Onward
  drm/i915/gt: Set BLIT_CCTL reg to un-cached
  drm/i915/gt: Initialize unused MOCS entries with device specific values
  drm/i915/gt: Add separate MOCS table for Gen12 devices other than TGL/RKL
  drm/i915/gt: Add "intel_" as prefix in set_mocs_index()

Cai Huoqing (1):
  drm/i915: Use direction definition DMA_BIDIRECTIONAL instead of 
PCI_DMA_BIDIRECTIONAL

Colin Ian King (1):
  drm/i915: clean up inconsistent indenting

Dan Carpenter (1):
  drm/i915/gt: Potential error pointer dereference in pinned_context()

Daniel Vetter (14):
  drm/doc/rfc: drop lmem uapi section
  drm/i915: Use locked access to ctx->engines in set_priority
  drm/i915: Actually delete gpu reloc selftests
  drm/i915: Release i915_gem_context from a worker
  drm/i915: Release ctx->syncobj on final put, not on ctx close
  drm/i915: Keep gem ctx->vm alive until the final put
  drm/i915: Drop code to handle set-vm races from execbuf
  drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm
  drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam
  drm/i915: Add i915_gem_context_is_full_ppgtt
  drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem
  drm/i915: Drop __rcu from gem_context->vm
  drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups
  drm/i915: Stop rcu support for i915_address_space

Daniele Ceraolo Spurio (12):
  drm/i915/guc: drop guc_communication_enabled
  drm/i915/guc: put all guc objects in lmem when available
  drm/i915/guc: Add DG1 GuC / HuC firmware defs
  drm/i915/pxp: Define PXP component interface
  drm/i915/pxp: define PXP device flag and kconfig
  drm/i915/pxp: allocate a vcs context for pxp usage
  drm/i915/pxp: set KCR reg init
  drm/i915/pxp: interfaces for using protected objects
  drm/i915/pxp: start the arb session on demand
  drm/i915/pxp: add pxp debugfs
  drm/i915/pxp: add PXP documentation
  drm/i915/pxp: enable PXP for integrated Gen12

Huang, Sean Z (5):
  drm/i915/pxp: Implement funcs to create the TEE channel
  drm/i915/pxp: Create the arbitrary session after boot
  drm/i915/pxp: Implement arb session teardown
  drm/i915/pxp: Implement PXP irq handler
  drm/i915/pxp: Enable PXP power management

Jani Nikula (1):
  drm/i915/pci: rename functions to have i915_pci prefix

Janusz Krzysztofik (2):
  drm/i915: Mark GPU wedging on driver unregister unrecoverable
  drm/i915: Flush buffer pools on driver remove

Joonas Lahtinen (2):
  Merge drm/drm-next into drm-intel-gt-next
  Merge remote-tracking branch 'tip/locking/wwmutex' into drm-intel-gt-next

Kees Cook (1):
  drm/i915: Use designated initializers for init/exit table

Lucas De Marchi (8):
  drm/i915/xehpsdv: factor out function to read RP_STATE_CAP
  drm/i915/dg1: remove __maybe_unused leftover
  drm/i915/xehpsdv: Define MOCS table for XeHP SDV
  drm/i915: rename debugfs_gt files
  drm/i915: rename debugfs_engines files
  drm/i915: rename debugfs_gt_pm files
  drm/i915: deduplicate frequency dump on debugfs
  drm/i915: remove IS_ACTIVE

Maarten Lankhorst (5):
  drm/i915: Add pci ids and uapi for DG1
  drm/i915: Add mmap lock around vma_lookup() in the mman selftest.
  drm/i915: Move __i915_gem_free_object to ttm_bo_destroy
  kernel/locking: Add context to ww_mutex_trylock()
  drm/i915: Fix runtime pm handling in i915_gem_shrink

Matt Roper (21):
  drm/i915: correct name of GT forcewake domain in error messages
  drm/i915: Re-use gen11 forcewake read functions on gen12
  drm/i915: Make shadow tables range-based
  drm/i915/gen11: Update shadowed register table
  drm/i915/gen12: Update shadowed register table
  drm/i915/xehp: Xe_HP shadowed registers are a strict superset of gen12
  drm/i915/xehp: Loop over all gslices for INSTDONE processing
  drm/i915/dg2: Report INSTDONE_GEOM

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Daniel,

Here comes the final feature PR for 5.16.

As the biggest thing it adds multi-LRC (parallel) submission
implementation for GuC and a simplified parallel submission uAPI
to go with that (only works with GuC for now). It is has a similar
mission to the bonded submission uAPI, take a look at the kerneldocs
for full detail.

Then there are some improvements to making sure old pages are flushed from
caches before making them available to userspaces. Those extra flushes may
be visible in corner case scenarios if application is frequently importing
new dmabufs on non-LLC hardware. The better approach would anyway be to
recycle a pool of dmabufs than destroy and recreate.

In addition to that, it's only minor changes with mainly developer
impact and those can be seen in shortlog.

Regards, Joonas

PS. There has been request to backmerge drm-next after you merge this
PR, to bring in dma-resv iterators. I'll do that.

PPS. Will send out the dim patches for the "for-linux-next-gt" branch
 updating to make sure we avoid the future conflicts.

***

drm-intel-gt-next-2021-10-21:

UAPI Changes:

- Expose multi-LRC submission interface

  Similar to the bonded submission interface but simplified.
  Comes with GuC only implementation for now. See kerneldoc
  for more details.

  Userspace changes: https://github.com/intel/media-driver/pull/1252

- Expose logical engine instance to user

  Needed by the multi-LRC submission interface for GuC

  Userspace changes: https://github.com/intel/media-driver/pull/1252

Driver Changes:

- Fix blank screen booting crashes when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (Hugh)
- Add support for multi-LRC submission in the GuC backend (Matt B)
- Add extra cache flushing before making pages userspace visible (Matt A, 
Thomas)
- Mark internal GPU object pages dirty so they will be flushed properly (Matt A)

- Move remaining debugfs interfaces i915_wedged/i915_forcewake_user into gt 
(Andi)
- Replace the unconditional clflushes with drm_clflush_virt_range() (Ville)
- Remove IS_ACTIVE macro completely (Lucas)
- Improve kerneldocs for cache_dirty (Matt A)

- Add missing includes (Lucas)
- Selftest improvements (Matt R, Ran, Matt A)

The following changes since commit 1a839e016e4964b5c8384e5d82e5e5ac02a23f52:

  drm/i915: remove IS_ACTIVE (2021-10-07 11:04:05 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-10-21

for you to fetch changes up to ab5d964c001b9efffcbfa4d67a30186b67d79771:

  drm/i915/selftests: mark up hugepages object with start_cpu_write (2021-10-20 
16:50:42 +0100)


UAPI Changes:

- Expose multi-LRC submission interface

  Similar to the bonded submission interface but simplified.
  Comes with GuC only implementation for now. See kerneldoc
  for more details.

  Userspace changes: https://github.com/intel/media-driver/pull/1252

- Expose logical engine instance to user

  Needed by the multi-LRC submission interface for GuC

  Userspace changes: https://github.com/intel/media-driver/pull/1252

Driver Changes:

- Fix blank screen booting crashes when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (Hugh)
- Add support for multi-LRC submission in the GuC backend (Matt B)
- Add extra cache flushing before making pages userspace visible (Matt A, 
Thomas)
- Mark internal GPU object pages dirty so they will be flushed properly (Matt A)

- Move remaining debugfs interfaces i915_wedged/i915_forcewake_user into gt 
(Andi)
- Replace the unconditional clflushes with drm_clflush_virt_range() (Ville)
- Remove IS_ACTIVE macro completely (Lucas)
- Improve kerneldocs for cache_dirty (Matt A)

- Add missing includes (Lucas)
- Selftest improvements (Matt R, Ran, Matt A)


Andi Shyti (1):
  drm/i915/gt: move remaining debugfs interfaces into gt

Hugh Dickins (1):
  drm/i915: fix blank screen booting crashes

Lucas De Marchi (2):
  drm/i915/gt: include tsc.h where used
  drm/i915/gt: add asm/cacheflush.h for use of clflush()

Matt Roper (1):
  drm/i915: Stop using I915_TILING_* in client blit selftest

Matthew Auld (9):
  drm/i915: mark dmabuf objects as ALLOC_USER
  drm/i915: mark userptr objects as ALLOC_USER
  drm/i915: extract bypass-llc check into helper
  drm/i915/dmabuf: add paranoid flush-on-acquire
  drm/i915/userptr: add paranoid flush-on-acquire
  drm/i915/shmem: ensure flush during swap-in on non-LLC
  drm/i915: expand on the kernel-doc for cache_dirty
  drm/i915: mark up internal objects with start_cpu_write
  drm/i915/selftests: mark up hugepages object with start_cpu_write

Matthew Brost (24):
  drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct
  drm/i915/guc: Take GT PM ref when deregistering context
  drm/i915/guc: Take engine PM when a context is pinned with GuC submission
  drm/i915/gu

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

[Joonas Lahtinen]

Hi Matt & John,

Can you please queue patches with the right Fixes: references to convert
all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
protection for now. Please do so before next Wednesday so we get it
queued in drm-intel-next-fixes.

There's the orthogonal track to discuss what would be the stable set of
tracepoints we could expose. However, before that discussion is closed,
let's keep a rather strict line to avoid potential maintenance burned.

We can then relax in the future as needed.

Regards, Joonas

Quoting Matthew Brost (2021-06-24 10:04:29)
> As discussed in [1], [2] we are enabling GuC submission support in the
> i915. This is a subset of the patches in step 5 described in [1],
> basically it is absolute to enable CI with GuC submission on gen11+
> platforms.
> 
> This series itself will likely be broken down into smaller patch sets to
> merge. Likely into CTBs changes, basic submission, virtual engines, and
> resets.
> 
> A following series will address the missing patches remaining from [1].
> 
> Locally tested on TGL machine and basic tests seem to be passing.
> 
> Signed-off-by: Matthew Brost 
> 
> [1] https://patchwork.freedesktop.org/series/89844/
> [2] https://patchwork.freedesktop.org/series/91417/
> 
> Daniele Ceraolo Spurio (1):
>   drm/i915/guc: Unblock GuC submission on Gen11+
> 
> John Harrison (10):
>   drm/i915/guc: Module load failure test for CT buffer creation
>   drm/i915: Track 'serial' counts for virtual engines
>   drm/i915/guc: Provide mmio list to be saved/restored on engine reset
>   drm/i915/guc: Don't complain about reset races
>   drm/i915/guc: Enable GuC engine reset
>   drm/i915/guc: Fix for error capture after full GPU reset with GuC
>   drm/i915/guc: Hook GuC scheduling policies up
>   drm/i915/guc: Connect reset modparam updates to GuC policy flags
>   drm/i915/guc: Include scheduling policies in the debugfs state dump
>   drm/i915/guc: Add golden context to GuC ADS
> 
> Matthew Brost (36):
>   drm/i915/guc: Relax CTB response timeout
>   drm/i915/guc: Improve error message for unsolicited CT response
>   drm/i915/guc: Increase size of CTB buffers
>   drm/i915/guc: Add non blocking CTB send function
>   drm/i915/guc: Add stall timer to non blocking CTB send function
>   drm/i915/guc: Optimize CTB writes and reads
>   drm/i915/guc: Add new GuC interface defines and structures
>   drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor
>   drm/i915/guc: Add lrc descriptor context lookup array
>   drm/i915/guc: Implement GuC submission tasklet
>   drm/i915/guc: Add bypass tasklet submission path to GuC
>   drm/i915/guc: Implement GuC context operations for new inteface
>   drm/i915/guc: Insert fence on context when deregistering
>   drm/i915/guc: Defer context unpin until scheduling is disabled
>   drm/i915/guc: Disable engine barriers with GuC during unpin
>   drm/i915/guc: Extend deregistration fence to schedule disable
>   drm/i915: Disable preempt busywait when using GuC scheduling
>   drm/i915/guc: Ensure request ordering via completion fences
>   drm/i915/guc: Disable semaphores when using GuC scheduling
>   drm/i915/guc: Ensure G2H response has space in buffer
>   drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC
>   drm/i915/guc: Update GuC debugfs to support new GuC
>   drm/i915/guc: Add several request trace points
>   drm/i915: Add intel_context tracing
>   drm/i915/guc: GuC virtual engines
>   drm/i915: Hold reference to intel_context over life of i915_request
>   drm/i915/guc: Disable bonding extension with GuC submission
>   drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs
>   drm/i915/guc: Reset implementation for new GuC interface
>   drm/i915: Reset GPU immediately if submission is disabled
>   drm/i915/guc: Add disable interrupts to guc sanitize
>   drm/i915/guc: Suspend/resume implementation for new interface
>   drm/i915/guc: Handle context reset notification
>   drm/i915/guc: Handle engine reset failure notification
>   drm/i915/guc: Enable the timer expired interrupt for GuC
>   drm/i915/guc: Capture error state on context reset
> 
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |   30 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |1 +
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c  |3 +-
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |6 +-
>  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   |   41 +-
>  drivers/gpu/drm/i915/gt/intel_breadcrumbs.h   |   14 +-
>  .../gpu/drm/i915/gt/intel_breadcrumbs_types.h |7 +
>  drivers/gpu/drm/i915/gt/intel_context.c   |   41 +-
>  drivers/gpu/drm/i915/gt/intel_context.h   |   31 +-
>  drivers/gpu/drm/i915/gt/intel_context_types.h |   49 +
>  drivers/gpu/drm/i915/gt/intel_engine.h|   72 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  182 +-
>  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  |   71 +-
>  .../gpu/drm/i915/gt/intel_engine_heartbeat.h  |4 +
>  drivers/gpu/drm/i915/gt/intel_engine_types

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

[Joonas Lahtinen]

Quoting Matthew Brost (2021-10-22 19:42:19)
> On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > Hi Matt & John,
> > 
> > Can you please queue patches with the right Fixes: references to convert
> > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
> > protection for now. Please do so before next Wednesday so we get it
> > queued in drm-intel-next-fixes.
> > 
> 
> Don't we already do that? I checked i915_trace.h and every tracepoint I
> added (intel_context class, i915_request_guc_submit) is protected by
> LOW_LEVEL_TRACEPOINTS.
> 
> The only thing I changed outside of that protection is adding the guc_id
> field to existing i915_request class tracepoints.

It's the first search hit for "guc" inside the i915_trace.h file :)

> Without the guc_id in
> those tracepoints these are basically useless with GuC submission. We
> could revert that if it is a huge deal but as I said then they are
> useless...

Let's eliminate it for now and restore the tracepoint exactly as it was.

If there is an immediate need, we should instead have an auxilary tracepoint
which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the
information of the basic tracepoint.

For the longer term solution we should align towards the dma fence
tracepoints. When those are combined with the OA information, one should
be able to get a good understanding of both the software and hardware
scheduling decisions.

Regards, Joonas

> 
> Matt
> 
> > There's the orthogonal track to discuss what would be the stable set of
> > tracepoints we could expose. However, before that discussion is closed,
> > let's keep a rather strict line to avoid potential maintenance burned.
> > 
> > We can then relax in the future as needed.
> > 
> > Regards, Joonas
> > 
> > Quoting Matthew Brost (2021-06-24 10:04:29)
> > > As discussed in [1], [2] we are enabling GuC submission support in the
> > > i915. This is a subset of the patches in step 5 described in [1],
> > > basically it is absolute to enable CI with GuC submission on gen11+
> > > platforms.
> > > 
> > > This series itself will likely be broken down into smaller patch sets to
> > > merge. Likely into CTBs changes, basic submission, virtual engines, and
> > > resets.
> > > 
> > > A following series will address the missing patches remaining from [1].
> > > 
> > > Locally tested on TGL machine and basic tests seem to be passing.
> > > 
> > > Signed-off-by: Matthew Brost 
> > > 
> > > [1] https://patchwork.freedesktop.org/series/89844/
> > > [2] https://patchwork.freedesktop.org/series/91417/
> > > 
> > > Daniele Ceraolo Spurio (1):
> > >   drm/i915/guc: Unblock GuC submission on Gen11+
> > > 
> > > John Harrison (10):
> > >   drm/i915/guc: Module load failure test for CT buffer creation
> > >   drm/i915: Track 'serial' counts for virtual engines
> > >   drm/i915/guc: Provide mmio list to be saved/restored on engine reset
> > >   drm/i915/guc: Don't complain about reset races
> > >   drm/i915/guc: Enable GuC engine reset
> > >   drm/i915/guc: Fix for error capture after full GPU reset with GuC
> > >   drm/i915/guc: Hook GuC scheduling policies up
> > >   drm/i915/guc: Connect reset modparam updates to GuC policy flags
> > >   drm/i915/guc: Include scheduling policies in the debugfs state dump
> > >   drm/i915/guc: Add golden context to GuC ADS
> > > 
> > > Matthew Brost (36):
> > >   drm/i915/guc: Relax CTB response timeout
> > >   drm/i915/guc: Improve error message for unsolicited CT response
> > >   drm/i915/guc: Increase size of CTB buffers
> > >   drm/i915/guc: Add non blocking CTB send function
> > >   drm/i915/guc: Add stall timer to non blocking CTB send function
> > >   drm/i915/guc: Optimize CTB writes and reads
> > >   drm/i915/guc: Add new GuC interface defines and structures
> > >   drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor
> > >   drm/i915/guc: Add lrc descriptor context lookup array
> > >   drm/i915/guc: Implement GuC submission tasklet
> > >   drm/i915/guc: Add bypass tasklet submission path to GuC
> > >   drm/i915/guc: Implement GuC context operations for new inteface
> > >   drm/i915/guc: Insert fence on context when deregistering
> > >   drm/i915/guc: Defer context unpin until scheduling is disabled
> > >   drm/i915/guc: Disable engine barriers with GuC during unpin
> > >   drm/i915/guc: E

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix recursive lock in GuC submission

[Joonas Lahtinen]

Quoting Thomas Hellström (2021-10-21 08:39:48)
> On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:



> > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > pinned with GuC submission")
> > Signed-off-by: Matthew Brost 
> > Cc: sta...@vger.kernel.org

This Cc: stable annotation is unnecessary.

Please always use "dim fixes 1a52faed31311" for helping to decide which
Cc's are needed. In this case stable is not needed. If it was, there
would be an indication of kernel version. In this case this is fine to
be picked up by in drm-intel-next-fixes PR.

Let's pay attention to the right Fixes: annotation while submitting and
reviewing patches.

Regards, Joonas

[Intel-gfx] [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer

[Joonas Lahtinen]

Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
Tvrtko will bring added bandwidth and focus to the GT/GEM domain
(drm-intel-gt-next).

This will help with the increased driver maintenance efforts, allows
alternating the drm-intel-gt-next pull requests and also should increase
the coverage for the maintenance in general.

Signed-off-by: Joonas Lahtinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Acked-by: Jani Nikula 
Acked-by: Rodrigo Vivi 
Acked-by: Tvrtko Ursulin 
Cc: Sean Paul 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: dri-de...@lists.freedesktop.org
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 98aa1f55ed41..07553156a1c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9361,6 +9361,7 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and 
derivative chipsets)
 M: Jani Nikula 
 M: Joonas Lahtinen 
 M: Rodrigo Vivi 
+M: Tvrtko Ursulin 
 L: intel-gfx@lists.freedesktop.org
 S: Supported
 W: https://01.org/linuxgraphics/
-- 
2.31.1

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

[Joonas Lahtinen]

Quoting Matthew Brost (2021-10-25 18:15:09)
> On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> > Quoting Matthew Brost (2021-10-22 19:42:19)
> > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > > > Hi Matt & John,
> > > > 
> > > > Can you please queue patches with the right Fixes: references to convert
> > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
> > > > protection for now. Please do so before next Wednesday so we get it
> > > > queued in drm-intel-next-fixes.
> > > > 
> > > 
> > > Don't we already do that? I checked i915_trace.h and every tracepoint I
> > > added (intel_context class, i915_request_guc_submit) is protected by
> > > LOW_LEVEL_TRACEPOINTS.
> > > 
> > > The only thing I changed outside of that protection is adding the guc_id
> > > field to existing i915_request class tracepoints.
> > 
> > It's the first search hit for "guc" inside the i915_trace.h file :)
> > 
> > > Without the guc_id in
> > > those tracepoints these are basically useless with GuC submission. We
> > > could revert that if it is a huge deal but as I said then they are
> > > useless...
> > 
> > Let's eliminate it for now and restore the tracepoint exactly as it was.
> > 
> 
> Don't really agree - let's render tracepoints to be useless? Are
> tracepoints ABI? I googled this and couldn't really find a definie
> answer. If tracepoints are ABI, then OK I can revert this change but
> still this is a poor technical decision (tracepoints should not be ABI).

Thats a very heated discussion in general. But the fact is that if
tracepoint changes have caused regressions to applications, they have
been forced to be remain untouched. You are free to raise the discussion
with Linus/LKML if you feel that should not be the case. So the end
result is that tracepoints are effectively in limbo, not ABI unless some
application uses them like ABI.

Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look
for threads with many replies. It's not that I would not agree, it's more
that I'm not in the mood for repeating that discussion over and over again
and always land in the same spot.

So for now, we don't add anything new to tracepoints we can't guarantee
to always be there untouched. Similarly, we don't guarantee any of them
to remain stable. So we try to be compatible with the limbo.

I'm long overdue waiting for some stable consumer to step up for the
tracepoints, so we can then start discussion what would actually be the
best way of getting that information out for them. In ~5 years that has
not happened.

> > If there is an immediate need, we should instead have an auxilary tracepoint
> > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the
> > information of the basic tracepoint.
> > 
> 
> Regardless of what I said above, I'll post 2 patches. The 1st just
> remove the GuC, the 2nd modify the tracepoint to include guc_id if
> LOW_LEVEL_TRACEPOINTS is defined.

Thanks. Let's get a patch merged which simply drops the guc_id for now
to unblock things.

For the second, an auxilary tracepoint will be preferred instead of
mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS).

I only noticed a patch that mutates the tracepoints, can you
double-check sending the first patch?

Regards, Joonas

> 
> > For the longer term solution we should align towards the dma fence
> > tracepoints. When those are combined with the OA information, one should
> > be able to get a good understanding of both the software and hardware
> > scheduling decisions.
> > 
> 
> Not sure about this either. I use these tracepoins to correlate things
> to the GuC log. Between the 2, if you know what you are doing you
> basically can figure out everything that is happening. Fields in the
> trace translate directly to fields in the GuC log. Some of these fields
> are backend specific, not sure how these could be pushed the dma fence
> tracepoints. For what it is worth, without these tracepoints we'd likely
> still have a bunch of bugs in the GuC firmware. I understand these
> points, several other i915 developers do, and several of the GuC
> firmware developers do too.
> 
> Matt
> 
> > Regards, Joonas
> > 
> > > 
> > > Matt
> > > 
> > > > There's the orthogonal track to discuss what would be the stable set of
> > > > tracepoints we could expose. However, before that discussion is closed,
> > > > let's keep a rather st

Re: [Intel-gfx] [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig

[Joonas Lahtinen]

Quoting John Harrison (2021-10-26 00:06:54)
> On 10/25/2021 09:34, Matthew Brost wrote:
> > Hide the guc_id and tail fields, for request trace points, behind
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> > are ABI (maybe?) so don't change them without kernel developers Kconfig
> > options.
> The i915 sw arch team have previously hard blocked requests for changes 
> to trace points from user land tool developers on the grounds that trace 
> points are not ABI and are free to change at whim as and when the i915 
> internal implementation changes. They are purely for use of developers 
> to debug the i915 driver as the i915 driver currently stands at any 
> given instant.

Correct. That is indicated by the LOW_LEVEL_TRACEPOINTS.

All the discussions about stable usage really revolve around the low level
backend specific scheduling tracepoints to analyze hardware utilization.
And those even become infeasible to expose when GuC scheduling is enabled
as the information really goes to GuC log.

Luckily we have added the mechanism to get the actual utilization
through OA via gpuvis tool, so we don't have to guesstimate it from the
KMD scheduling tracepoints (which are for KMD debugging).

> So I don't see how it can be argued that we must not update any trace 
> points to allow for debugging of i915 scheduling issues on current 
> platforms. And having to enable extra config options just to keep 
> existing higher level trace points usable seems broken.

We can update them (even outside LOW_LEVEL_TRACEPOINTS) but there should
not be any backend specific data added outside the LOW_LEVEL_TRACEPOINTS,
just to prevent anyone from starting to use them in some
visualization/analysis tooling.

If you have the energy to drive the general LKML/Linux Plumbers level
discussion about tracepoint stability limbo into a conclusion, I'll be
more than happy to see it resolved :)

Regards, Joonas

> 
> John.
> 
> 
> >
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/i915_trace.h | 27 +++
> >   1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> > b/drivers/gpu/drm/i915/i915_trace.h
> > index 9795f456cccf..4f5238d02b51 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
> > __entry->ctx, __entry->seqno, __entry->flags)
> >   );
> >   
> > +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> >   DECLARE_EVENT_CLASS(i915_request,
> >   TP_PROTO(struct i915_request *rq),
> >   TP_ARGS(rq),
> > @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
> > __entry->guc_id, __entry->ctx, __entry->seqno,
> > __entry->tail)
> >   );
> > +#else
> > +DECLARE_EVENT_CLASS(i915_request,
> > + TP_PROTO(struct i915_request *rq),
> > + TP_ARGS(rq),
> > +
> > + TP_STRUCT__entry(
> > +  __field(u32, dev)
> > +  __field(u64, ctx)
> > +  __field(u16, class)
> > +  __field(u16, instance)
> > +  __field(u32, seqno)
> > +  ),
> > +
> > + TP_fast_assign(
> > +__entry->dev = 
> > rq->engine->i915->drm.primary->index;
> > +__entry->class = rq->engine->uabi_class;
> > +__entry->instance = rq->engine->uabi_instance;
> > +__entry->ctx = rq->fence.context;
> > +__entry->seqno = rq->fence.seqno;
> > +),
> > +
> > + TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> > +   __entry->dev, __entry->class, __entry->instance,
> > +   __entry->ctx, __entry->seqno)
> > +);
> > +#endif
> >   
> >   DEFINE_EVENT(i915_request, i915_request_add,
> >TP_PROTO(struct i915_request *rq),
> 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix recursive lock in GuC submission

[Joonas Lahtinen]

Quoting Matthew Brost (2021-10-25 20:13:22)
> On Mon, Oct 25, 2021 at 03:23:00PM +0300, Joonas Lahtinen wrote:
> > Quoting Thomas Hellström (2021-10-21 08:39:48)
> > > On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> > 
> > 
> > 
> > > > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > > > pinned with GuC submission")
> > > > Signed-off-by: Matthew Brost 
> > > > Cc: sta...@vger.kernel.org
> > 
> > This Cc: stable annotation is unnecessary.
> > 
> > Please always use "dim fixes 1a52faed31311" for helping to decide which
> > Cc's are needed. In this case stable is not needed. If it was, there
> > would be an indication of kernel version. In this case this is fine to
> > be picked up by in drm-intel-next-fixes PR.
> > 
> > Let's pay attention to the right Fixes: annotation while submitting and
> > reviewing patches.
> > 
> 
> Will do. Working on getting push rights. Is there any documentation with
> all the rules when pushing as it seems like there are a lot of rules.

Yes, we have the documentation here:

https://drm.pages.freedesktop.org/maintainer-tools/committer-guidelines.html

And more specifically this topic:

https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-intel.html#labeling-fixes-before-pushing

I could even recommend to at least do a cursory read through the wider
documentation about how the different trees interact:

https://drm.pages.freedesktop.org/maintainer-tools/index.html

Makes it easier to understand how the tags are used.

Regards, Joonas

> 
> Matt 
> 
> > Regards, Joonas

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

[Joonas Lahtinen]

Quoting Matthew Brost (2021-10-26 18:51:17)
> On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote:
> > Quoting Matthew Brost (2021-10-25 18:15:09)
> > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> > > > Quoting Matthew Brost (2021-10-22 19:42:19)
> > > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > > > > > Hi Matt & John,
> > > > > > 
> > > > > > Can you please queue patches with the right Fixes: references to 
> > > > > > convert
> > > > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
> > > > > > protection for now. Please do so before next Wednesday so we get it
> > > > > > queued in drm-intel-next-fixes.
> > > > > > 
> > > > > 
> > > > > Don't we already do that? I checked i915_trace.h and every tracepoint 
> > > > > I
> > > > > added (intel_context class, i915_request_guc_submit) is protected by
> > > > > LOW_LEVEL_TRACEPOINTS.
> > > > > 
> > > > > The only thing I changed outside of that protection is adding the 
> > > > > guc_id
> > > > > field to existing i915_request class tracepoints.
> > > > 
> > > > It's the first search hit for "guc" inside the i915_trace.h file :)
> > > > 
> > > > > Without the guc_id in
> > > > > those tracepoints these are basically useless with GuC submission. We
> > > > > could revert that if it is a huge deal but as I said then they are
> > > > > useless...
> > > > 
> > > > Let's eliminate it for now and restore the tracepoint exactly as it was.
> > > > 
> > > 
> > > Don't really agree - let's render tracepoints to be useless? Are
> > > tracepoints ABI? I googled this and couldn't really find a definie
> > > answer. If tracepoints are ABI, then OK I can revert this change but
> > > still this is a poor technical decision (tracepoints should not be ABI).
> > 
> > Thats a very heated discussion in general. But the fact is that if
> > tracepoint changes have caused regressions to applications, they have
> > been forced to be remain untouched. You are free to raise the discussion
> > with Linus/LKML if you feel that should not be the case. So the end
> > result is that tracepoints are effectively in limbo, not ABI unless some
> > application uses them like ABI.
> > 
> > Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look
> > for threads with many replies. It's not that I would not agree, it's more
> > that I'm not in the mood for repeating that discussion over and over again
> > and always land in the same spot.
> > 
> > So for now, we don't add anything new to tracepoints we can't guarantee
> > to always be there untouched. Similarly, we don't guarantee any of them
> > to remain stable. So we try to be compatible with the limbo.
> > 
> > I'm long overdue waiting for some stable consumer to step up for the
> > tracepoints, so we can then start discussion what would actually be the
> > best way of getting that information out for them. In ~5 years that has
> > not happened.
> > 
> > > > If there is an immediate need, we should instead have an auxilary 
> > > > tracepoint
> > > > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the
> > > > information of the basic tracepoint.
> > > > 
> > > 
> > > Regardless of what I said above, I'll post 2 patches. The 1st just
> > > remove the GuC, the 2nd modify the tracepoint to include guc_id if
> > > LOW_LEVEL_TRACEPOINTS is defined.
> > 
> > Thanks. Let's get a patch merged which simply drops the guc_id for now
> > to unblock things.
> > 
> > For the second, an auxilary tracepoint will be preferred instead of
> > mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS).
> > 
> > I only noticed a patch that mutates the tracepoints, can you
> > double-check sending the first patch?
> 
> Sorry for the double reply - missed this one in the first.
> 
> I changed my plans / mind after I send the original email. I only sent a
> patch which includes guc_id when LOW_LEVEL_TRACEPOINTS is enabled. That
> is the bear minimum I live with. Without it any time there is a problem
> results in hacking the kernel. I can't do t

[Intel-gfx] [PATCH] drm/i915: Revert 'guc_id' from i915_request tracepoint

[Joonas Lahtinen]

Avoid adding backend specific data to the tracepoints outside of
the LOW_LEVEL_TRACEPOINTS kernel config protection. These bits of
information are bound to change depending on the selected submission
method per platform and are not necessarily possible to maintain in
the future.

Fixes: dbf9da8d55ef ("drm/i915/guc: Add trace point for GuC submit")
Signed-off-by: Joonas Lahtinen 
Cc: John Harrison 
Cc: Matthew Brost 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_trace.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 9795f456cccf..8104981a6604 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -794,7 +794,6 @@ DECLARE_EVENT_CLASS(i915_request,
TP_STRUCT__entry(
 __field(u32, dev)
 __field(u64, ctx)
-__field(u32, guc_id)
 __field(u16, class)
 __field(u16, instance)
 __field(u32, seqno)
@@ -805,16 +804,14 @@ DECLARE_EVENT_CLASS(i915_request,
   __entry->dev = rq->engine->i915->drm.primary->index;
   __entry->class = rq->engine->uabi_class;
   __entry->instance = rq->engine->uabi_instance;
-  __entry->guc_id = rq->context->guc_id.id;
   __entry->ctx = rq->fence.context;
   __entry->seqno = rq->fence.seqno;
   __entry->tail = rq->tail;
   ),
 
-   TP_printk("dev=%u, engine=%u:%u, guc_id=%u, ctx=%llu, seqno=%u, 
tail=%u",
+   TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u, tail=%u",
  __entry->dev, __entry->class, __entry->instance,
- __entry->guc_id, __entry->ctx, __entry->seqno,
- __entry->tail)
+ __entry->ctx, __entry->seqno, __entry->tail)
 );
 
 DEFINE_EVENT(i915_request, i915_request_add,
-- 
2.31.1

Re: [Intel-gfx] [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer

[Joonas Lahtinen]

Quoting Dave Airlie (2021-10-26 03:34:52)
> On Mon, 25 Oct 2021 at 23:51, Daniel Vetter  wrote:
> >
> > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen
> >  wrote:
> > >
> > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver.
> > > Tvrtko will bring added bandwidth and focus to the GT/GEM domain
> > > (drm-intel-gt-next).
> > >
> > > This will help with the increased driver maintenance efforts, allows
> > > alternating the drm-intel-gt-next pull requests and also should increase
> > > the coverage for the maintenance in general.
> > >
> > > Signed-off-by: Joonas Lahtinen 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Acked-by: Jani Nikula 
> > > Acked-by: Rodrigo Vivi 
> > > Acked-by: Tvrtko Ursulin 
> > > Cc: Sean Paul 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: dri-de...@lists.freedesktop.org
> >
> > Acked-by: Daniel Vetter 
> 
> Acked-by: Dave Airlie 

Thanks for the Acks, this is now merged.

Regards, Joonas

Re: ✓ Fi.CI.BAT: success for drm/i915: Revert 'guc_id' from i915_request tracepoint

[Joonas Lahtinen]

+ Jani and Rodrigo in order to pick this to -fixes.

Quoting Patchwork (2021-10-27 13:31:33)
> Patch Details
> 
> Series:  drm/i915: Revert 'guc_id' from i915_request tracepoint
> URL: https://patchwork.freedesktop.org/series/96336/
> State:   success
> Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21458/index.html
> 
> CI Bug Log - changes from CI_DRM_10795 -> Patchwork_21458
> 
> Summary
> 
> SUCCESS
> 
> No regressions found.

Thanks for the review, this is now merged to drm-intel-gt-next.

Regards, Joonas

> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21458/
> index.html
> 
> Participating hosts (37 -> 35)
> 
> Additional (2): fi-tgl-1115g4 fi-icl-u2
> Missing (4): fi-bsw-cyan bat-adlp-4 bat-dg1-6 bat-dg1-5
> 
> Known issues
> 
> Here are the changes found in Patchwork_21458 that come from known issues:
> 
> IGT changes
> 
> Issues hit
> 
>   • igt@amdgpu/amd_basic@query-info:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109315)
>   • igt@amdgpu/amd_cs_nop@fork-gfx0:
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (fdo#109315) +17 similar issues
>   • igt@amdgpu/amd_cs_nop@nop-gfx0:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109315 / i915#2575) +16 similar
> issues
>   • igt@gem_huc_copy@huc-copy:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#2190)
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (i915#2190)
> 
>   • igt@i915_pm_backlight@basic-brightness:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#1155)
>   • igt@i915_selftest@live@execlists:
> 
>   □ fi-bsw-n3050: PASS -> INCOMPLETE (i915#2940)
>   • igt@kms_chamelium@common-hpd-after-suspend:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#111827) +8 similar issues
>   • igt@kms_chamelium@dp-crc-fast:
> 
>   □ fi-bsw-nick: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +8 similar 
> issues
>   • igt@kms_chamelium@hdmi-hpd-fast:
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (fdo#111827) +8 similar issues
>   • igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#4103) +1 similar issue
>   • igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (fdo#109278) +2 similar issues
>   • igt@kms_force_connector_basic@force-load-detect:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (fdo#109285)
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (fdo#109285)
> 
>   • igt@kms_psr@primary_mmap_gtt:
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#1072) +3 similar issues
>   • igt@prime_vgem@basic-fence-flip:
> 
>   □ fi-bsw-nick: NOTRUN -> SKIP (fdo#109271) +57 similar issues
>   • igt@prime_vgem@basic-userptr:
> 
>   □ fi-icl-u2: NOTRUN -> SKIP (i915#3301)
> 
>   □ fi-tgl-1115g4: NOTRUN -> SKIP (i915#3301)
> 
>   • igt@runner@aborted:
> 
>   □ fi-bsw-n3050: NOTRUN -> FAIL (fdo#109271 / i915#1436 / i915#3428 / 
> i915
> #4312)
> 
> Possible fixes
> 
>   • igt@gem_exec_suspend@basic-s3:
> 
>   □ fi-bsw-nick: INCOMPLETE (i915#2369 / i915#3159) -> PASS
>   • igt@kms_frontbuffer_tracking@basic:
> 
>   □ fi-cfl-8109u: DMESG-FAIL (i915#295) -> PASS
>   • igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
> 
>   □ fi-cfl-8109u: DMESG-WARN (i915#295) -> PASS +10 similar issues
> 
> Build changes
> 
>   • Linux: CI_DRM_10795 -> Patchwork_21458
> 
> CI-20190529: 20190529
> CI_DRM_10795: 59f3569eebe53403249227d476e81d09c63c0f0c @ git://
> anongit.freedesktop.org/gfx-ci/linux
> IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ https://
> gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_21458: b7ef9de627b6edf88489282bddece7a342263c62 @ git://
> anongit.freedesktop.org/gfx-ci/linux
> 
> == Linux commits ==
> 
> b7ef9de627b6 drm/i915: Revert 'guc_id' from i915_request tracepoint
> 

Re: [Intel-gfx] [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig

[Joonas Lahtinen]

Quoting Matthew Brost (2021-10-25 19:34:04)
> Hide the guc_id and tail fields, for request trace points, behind
> CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
> are ABI (maybe?) so don't change them without kernel developers Kconfig
> options.

I've pushed the simple fix to eliminate the 'guc_id' field.

In my opinion a separate tracepoint with more information would be a
better choice here compared to mutating an existing one.

The idea with LOW_LEVEL_TRACEPOINTS is to make sure there are two sets
of tracepoints: one that is quasi stable and the other that is unstable.
Mutating the other set when the unstable set is enabled kind of breaks
that clean split.

Regards, Joonas

> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/i915_trace.h | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index 9795f456cccf..4f5238d02b51 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
>   __entry->ctx, __entry->seqno, __entry->flags)
>  );
>  
> +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
>  DECLARE_EVENT_CLASS(i915_request,
> TP_PROTO(struct i915_request *rq),
> TP_ARGS(rq),
> @@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
>   __entry->guc_id, __entry->ctx, __entry->seqno,
>   __entry->tail)
>  );
> +#else
> +DECLARE_EVENT_CLASS(i915_request,
> +   TP_PROTO(struct i915_request *rq),
> +   TP_ARGS(rq),
> +
> +   TP_STRUCT__entry(
> +__field(u32, dev)
> +__field(u64, ctx)
> +__field(u16, class)
> +__field(u16, instance)
> +__field(u32, seqno)
> +),
> +
> +   TP_fast_assign(
> +  __entry->dev = 
> rq->engine->i915->drm.primary->index;
> +  __entry->class = rq->engine->uabi_class;
> +  __entry->instance = rq->engine->uabi_instance;
> +  __entry->ctx = rq->fence.context;
> +  __entry->seqno = rq->fence.seqno;
> +  ),
> +
> +   TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> + __entry->dev, __entry->class, __entry->instance,
> + __entry->ctx, __entry->seqno)
> +);
> +#endif
>  
>  DEFINE_EVENT(i915_request, i915_request_add,
>  TP_PROTO(struct i915_request *rq),
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH v8] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2021-11-01 12:15:19)
> 
> On 25/10/2021 05:26, Cooper Chiou wrote:
> > This implements WaProgramMgsrForCorrectSliceSpecificMmioReads which
> > was omitted by mistake from Gen9 documentation, while it is actually
> > applicable to fused off parts.
> > 
> > Workaround consists of making sure MCR packet control register is
> > programmed to point to enabled slice/subslice pair before doing any
> > MMIO reads from the affected registers.
> > 
> > Failure do to this can result in complete system hangs when running
> > certain workloads. Two known cases which can cause system hangs are:
> > 
> > 1. "test_basic progvar_prog_scope_uninit" test which is part of
> >  Khronos OpenCL conformance suite
> >  (https://github.com/KhronosGroup/OpenCL-CTS) with the Intel
> >  OpenCL driver (https://github.com/intel/compute-runtime).
> > 
> > 2. VP8 media hardware encoding using the full-feature build of the
> >  Intel media-driver (https://github.com/intel/media-driver) and
> >  ffmpeg.
> > 
> > For the former case patch was verified to fix the hard system hang
> > when executing the OCL test on Intel Pentium CPU 6405U which contains
> > fused off GT1 graphics.
> > 
> > Reference: HSD#1508045018,1405586840, BSID#0575
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: William Tseng 
> > Cc: Shawn C Lee 
> > Cc: Pawel Wilma 
> > Signed-off-by: Cooper Chiou 
> 
> Reviewed-by: Tvrtko Ursulin 

Thanks for following through with all the testing and validation for the
patch!

Acked-by: Joonas Lahtinen 

Regards, Joonas

> 
> Regards,
> 
> Tvrtko
> 
> P.S. You could have preserved my r-b from an earlier version since it is 
> the same code, just different commit message.
> 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c | 41 +
> >   1 file changed, 41 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index e1f362530889..8ae24da601b0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -877,11 +877,52 @@ hsw_gt_workarounds_init(struct intel_gt *gt, struct 
> > i915_wa_list *wal)
> >   wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> >   }
> >   
> > +static void
> > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> > +{
> > + const struct sseu_dev_info *sseu = &i915->gt.info.sseu;
> > + unsigned int slice, subslice;
> > + u32 mcr, mcr_mask;
> > +
> > + GEM_BUG_ON(GRAPHICS_VER(i915) != 9);
> > +
> > + /*
> > +  * WaProgramMgsrForCorrectSliceSpecificMmioReads:gen9,glk,kbl,cml
> > +  * Before any MMIO read into slice/subslice specific registers, MCR
> > +  * packet control register needs to be programmed to point to any
> > +  * enabled s/ss pair. Otherwise, incorrect values will be returned.
> > +  * This means each subsequent MMIO read will be forwarded to an
> > +  * specific s/ss combination, but this is OK since these registers
> > +  * are consistent across s/ss in almost all cases. In the rare
> > +  * occasions, such as INSTDONE, where this value is dependent
> > +  * on s/ss combo, the read should be done with read_subslice_reg.
> > +  */
> > + slice = ffs(sseu->slice_mask) - 1;
> > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
> > + subslice = ffs(intel_sseu_get_subslices(sseu, slice));
> > + GEM_BUG_ON(!subslice);
> > + subslice--;
> > +
> > + /*
> > +  * We use GEN8_MCR..() macros to calculate the |mcr| value for
> > +  * Gen9 to address WaProgramMgsrForCorrectSliceSpecificMmioReads
> > +  */
> > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK;
> > +
> > + drm_dbg(&i915->drm, "MCR slice:%d/subslice:%d = %x\n", slice, 
> > subslice, mcr);
> > +
> > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
> > +}
> > +
> >   static void
> >   gen9_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> >   {
> >   struct drm_i915_private *i915 = gt->i915;
> >   
> > + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml,gen9 */
> > + gen9_wa_init_mcr(i915, wal);
> > +
> >   /* WaDisableKillLogic:bxt,skl,kbl */
> >   if (!IS_COFFEELAKE(i915) && !IS_COMETLAKE(i915))
> >   wa_write_or(wal,
> > 

Re: [Intel-gfx] [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

[Joonas Lahtinen]

Quoting Peter Zijlstra (2021-09-17 16:13:19)
> On Thu, Sep 16, 2021 at 03:28:11PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
> > 
> > > > For merge logistics, can we pls have a stable branch? I expect that the
> > > > i915 patches will be ready for 5.16.
> > > >
> > > > Or send it in for -rc2 so that the interface change doesn't cause 
> > > > needless
> > > > conflicts, whatever you think is best.
> > 
> > > Yeah, some central branch drm could pull from, would make upstreaming 
> > > patches that depends on it easier. :)
> > 
> > I think I'll make tip/locking/wwmutex and include that in
> > tip/locking/core, let me have a poke.
> 
> This is now so. Enjoy!

This is now merged to drm-intel-gt-next.

Regards, Joonas

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree

[Joonas Lahtinen]

Hi Matt,

Always use the dim tooling when applying patches, it will do the right
thing with regards to adding the S-o-b.

Regards, Joonas

Quoting Stephen Rothwell (2021-07-15 07:18:54)
> Hi all,
> 
> Commit
> 
>   db47fe727e1f ("drm/i915/step: s/_revid_tbl/_revids")
> 
> is missing a Signed-off-by from its committer.
> 
> -- 
> Cheers,
> Stephen Rothwell

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

 a bit
  drm/i915: Ditch i915 globals shrink infrastructure
  drm/i915: Check for nomodeset in i915_init() first
  drm/i915: move i915_active slab to direct module init/exit
  drm/i915: move i915_buddy slab to direct module init/exit
  drm/i915: move intel_context slab to direct module init/exit
  drm/i915: move gem_context slab to direct module init/exit
  drm/i915: move gem_objects slab to direct module init/exit
  drm/i915: move request slabs to direct module init/exit
  drm/i915: move scheduler slabs to direct module init/exit
  drm/i915: move vma slab to direct module init/exit
  drm/i915: Remove i915_globals
  drm/i915: Extract i915_module.c
  drm/i915: Disable gpu relocations
  drm/i915: delete gpu reloc code

Daniele Ceraolo Spurio (3):
  drm/i915: extract steered reg access to common function
  drm/i915/guc: Unblock GuC submission on Gen11+
  drm/i915/xehp: handle new steering options

Jason Ekstrand (46):
  drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
  drm/i915: Stop storing the ring size in the ring pointer (v3)
  drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
  drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem 
(v2)
  drm/i915/gem: Return void from context_apply_all
  drm/i915: Drop the CONTEXT_CLONE API (v2)
  drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
  drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES
  drm/i915/gem: Disallow bonding of virtual engines (v3)
  drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2)
  drm/i915/request: Remove the hook from await_execution
  drm/i915/gem: Disallow creating contexts with too many engines
  drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)
  drm/i915/gem: Add a separate validate_priority helper
  drm/i915: Add gem/i915_gem_context.h to the docs
  drm/i915/gem: Add an intermediate proto_context struct (v5)
  drm/i915/gem: Rework error handling in default_engines
  drm/i915/gem: Optionally set SSEU in intel_context_set_gem
  drm/i915: Add an i915_gem_vm_lookup helper
  drm/i915/gem: Make an alignment check more sensible
  drm/i915/gem: Use the proto-context to handle create parameters (v5)
  drm/i915/gem: Return an error ptr from context_lookup
  drm/i915/gt: Drop i915_address_space::file (v2)
  drm/i915/gem: Delay context creation (v3)
  drm/i915/gem: Don't allow changing the VM on running contexts (v4)
  drm/i915/gem: Don't allow changing the engine set on running contexts (v3)
  drm/i915/selftests: Take a VM in kernel_context()
  i915/gem/selftests: Assign the VM at context creation in 
igt_shared_ctx_exec
  drm/i915/gem: Roll all of context creation together
  drm/i915: Finalize contexts in GEM_CONTEXT_CREATE on version 13+
  drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
  Revert "drm/i915: Propagate errors on awaiting already signaled fences"
  drm/i915: Remove allow_alloc from i915_gem_object_get_sg*
  drm/i915: Drop error handling from dma_fence_work
  Revert "drm/i915: Skip over MI_NOOP when parsing"
  drm/i915: Correct the docs for intel_engine_cmd_parser
  drm/i915: Call i915_globals_exit() after i915_pmu_exit()
  drm/i915: Call i915_globals_exit() if pci_register_device() fails
  drm/i915: Use a table for i915_init/exit (v2)
  drm/i915: Make the kmem slab for i915_buddy_block a global
  drm/i915/gem: Check object_can_migrate from object_migrate
  drm/i915/gem: Refactor placement setup for i915_gem_object_create* (v2)
  drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()
  drm/i915/gem: Unify user object creation (v3)
  drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed
  drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails

John Harrison (19):
  drm/i915/huc: Update TGL and friends to HuC 7.9.3
  drm/i915/adlp: Add ADL-P GuC/HuC firmware files
  drm/i915/guc: Module load failure test for CT buffer creation
  drm/i915/selftests: Allow for larger engine counts
  drm/i915/xehp: Extra media engines - Part 1 (engine definitions)
  drm/i915/xehp: Extra media engines - Part 2 (interrupts)
  drm/i915/xehp: Extra media engines - Part 3 (reset)
  drm/i915/guc: Make hangcheck work with GuC virtual engines
  drm/i915/guc: Provide mmio list to be saved/restored on engine reset
  drm/i915/guc: Don't complain about reset races
  drm/i915/guc: Enable GuC engine reset
  drm/i915/guc: Fix for error capture after full GPU reset with GuC
  drm/i915/guc: Hook GuC scheduling policies up
  drm/i915/guc: Connect reset modparam updates to GuC policy flags
  drm/i915/guc: Include scheduling policies in the debugfs state dump
  drm/i915/guc: Add golden context to GuC ADS
 

Re: [Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-08-06 13:06:17)
> Hi Dave & Daniel,
> 
> Sorry for the big PR in advance. Had the summer vacations and did not
> notice until tool late how many patches were in already before leaving.
> 
> As requested, there is a lot of refactoring to increase the use of TTM
> allocator and prep for DRM scheduler. Note that at times the patches trade
> simplicity for performance and revert optimizations not seen as critical.
> So some performance regressions are expected.
> 
> As an example is dropping of faster GPU relocation path for older platforms,
> which should be mitigated by updating to the latest UMD versions to regain
> the perf.
> 
> This PR drops various bits of uAPI where userspace has dropped the ball after 
> reviews
> have been completed on both sides (Thanks Jason for doing the 
> due-diligence!). [1]
> Due to the complexity of tracing back who used what, I think we could do 
> better in the
> future to avoid such situations to begin with. See below for my suggestion 
> [2].
> 
> In addition to the refactoring and uAPI cleanup there is preliminay code for
> ADL-P/XeHP and DG2 platforms. Fixes for ADL-S and removal of CNL code.
> A couple of fixes that have been Cc: stable already. Removing unnecessary
> workarounds per stepping and adding missing for Gen12 iGFX.
> 
> I915_MMAP_OFFSET_FIXED is also added to to align with the static/fixed caching
> mode per BO instead of per-mapping mode (for dGFX only). There is GuC firmware
> interface update and backend code major rework that unblock enabling GuC on 
> Gen11
> (not on by default). Then there is the addition of the GuCRC power management
> feature which can be enabled for Gen12+ when submission is enabled.

There is also addition of I915_USERPTR_PROBE with userspace changes in:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044

Regards, Joonas

> 
> Then there is finally the drm-next backmerge and 3 topic branch merges.
> 
> I think that is mostly all. I tried to summarize much in the tag description 
> so
> it should hopefully not be horribly long...
> 
> Regards, Joonas
> 
> [1] Given that Jason is only human and there is no way to automate this 
> analysis, we
> may have to bring something back as fixes if we find breakage (like with the 
> MMAP IOCTL).
> 
> [2] As we first require to merge the kernel code, should we introduce some 
> further rules
> that the userspace has to land their code before the final kernel version 
> release? If
> that is not followed through, we would neuter the new uAPI with as small 
> patch as possible
> in the final release candidate and then remove it in next release. Thoughts?
> 
> ***
> 
> drm-intel-gt-next-2021-08-06-1:
> 
> UAPI Changes:
> 
> - Add I915_MMAP_OFFSET_FIXED
> 
>   On devices with local memory `I915_MMAP_OFFSET_FIXED` is the only valid
>   type. On devices without local memory, this caching mode is invalid.
> 
>   As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will
>   be used, depending on the object placement on creation. WB will be used
>   when the object can only exist in system memory, WC otherwise.
> 
>   Userspace: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11888
> 
> - Reinstate the mmap ioctl for (already released) integrated Gen12 platforms
> 
>   Rationale: Otherwise media driver breaks eg. for ADL-P. Long term goal is
>   still to sunset the IOCTL even for integrated and require using mmap_offset.
> 
> - Reject caching/set_domain IOCTLs on discrete
> 
>   Expected to become immutable property of the BO
> 
> - Disallow changing context parameters after first use on Gen12 and earlier
> - Require setting context parameters at creation on platforms after Gen12
> 
>   Rationale (for both): Allow less dynamic changes to the context to simplify
>   the implementation and avoid user shooting theirselves in the foot.
> 
> - Drop I915_CONTEXT_PARAM_RINGSIZE
> 
>   Userspace PR for compute-driver has not been merged
> 
> - Drop I915_CONTEXT_PARAM_NO_ZEROMAP
> 
>   Userspace PR for libdrm / Beignet was never landed
> 
> - Drop CONTEXT_CLONE API
> 
>   Userspace PR for Mesa was never landed
> 
> - Drop getparam support for I915_CONTEXT_PARAM_ENGINES
> 
>   Only existed for symmetry wrt. setparam, never used.
> 
> - Disallow bonding of virtual engines
> 
>   Drop the prep work, no hardware has been released needing it.
> 
> - (Implicit) Disable gpu relocations
> 
>   Media userspace was the last userspace to still use them. They
>   have converted so performance can be regained with an update.
> 
> Core Changes:
> 
> - Merge topic branch 'topic/i915-ttm-2021-06-11' (f

Re: [Intel-gfx] [PATCH 04/21] drm/i915/gvt: move the gvt code into kvmgt.ko

[Joonas Lahtinen]

Quoting Christoph Hellwig (2021-07-21 18:53:38)
> Instead of having an option to build the gvt code into the main i915
> module, just move it into the kvmgt.ko module.  This only requires
> a new struct with three entries that the main i915 module needs to
> request before enabling VGPU passthrough operations.
> 
> This also conveniently streamlines the GVT initialization and avoids
> the need for the global device pointer.
> 
> Signed-off-by: Christoph Hellwig 

Hi,

Thanks for putting the work into this. This conversion has been
requested for a long time. For clarity, should we call the module
i915_kvmgt?

How far would we be from dynamically modprobing/rmmoding the kvmgt
module in order to eliminate the enable_gvt parameter?



> +
> +/*
> + * Exported here so that the exports only get created when GVT support is
> + * actually enabled.
> + */
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_alloc, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_create_shmem, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_init, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_ggtt_pin_ww, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_pin_map, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_object_set_to_cpu_domain, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_flush_map, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(__i915_gem_object_set_pages, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_gtt_insert, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_prime_export, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_init, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_backoff, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_gem_ww_ctx_fini, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_ppgtt_create, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_request_add, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_request_create, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_request_wait, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_reserve_fence, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_unreserve_fence, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_vm_release, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(i915_vma_move_to_active, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_context_create, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_context_unpin, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_put, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(shmem_pin_map, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(shmem_unpin_map, I915_GVT);
> +EXPORT_SYMBOL_NS_GPL(__px_dma, I915_GVT);

This list is also a concern. At the least the double underscore
functions should be eliminated from being exported.

Zhi and Zhenyu, can we have some further patches to clean that up?

Regards, Joonas

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree

[Joonas Lahtinen]

+ Dave as FYI

Quoting Daniel Vetter (2021-08-10 09:27:25)
> On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> > On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > > Hi Matt,
> > > > 
> > > > Always use the dim tooling when applying patches, it will do the right
> > > > thing with regards to adding the S-o-b.
> > > 
> > > fd.o server rejects any pushes that haven't been done by dim, so how did
> > > this get through?
> > 
> > I definitely used dim for all of these patches, but I'm not sure how I
> > lost my s-o-b on this one.  Maybe when I edited the commit message after
> > 'dim extract-tags' I accidentally deleted an extra line when I removed
> > the extract-tags marker?  It's the only patch where the line is missing,
> > so it's almost certainly human error on my part rather than something
> > dim did wrong.
> 
> Yeah that's an expected failure model, and dim is supposed to catch that
> by rechecking for sobs when you push. See dim_push_branch ->
> checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> you want, dim /should/ catch it when pushing. That it didn't is kinda
> confusing and I'd like to know why that slipped through.
> 
> > > Matt, can you pls figure out and type up the patch to
> > > plug that hole?
> > 
> > Are you referring to a patch for dim here?  The i915 patch has already
> > landed, so we can't change its commit message now.
> 
> Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> baked in.
> -Daniel
> 
> > 
> > 
> > Matt
> > 
> > > 
> > > Thanks, Daniel
> > > 
> > > > 
> > > > Regards, Joonas
> > > > 
> > > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > > > > Hi all,
> > > > > 
> > > > > Commit
> > > > > 
> > > > >   db47fe727e1f ("drm/i915/step: 
> > > > > s/_revid_tbl/_revids")
> > > > > 
> > > > > is missing a Signed-off-by from its committer.
> > > > > 
> > > > > -- 
> > > > > Cheers,
> > > > > Stephen Rothwell
> > > 
> > > -- 
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [Intel-gfx] missing signoff on drm-intel-gt-next pull

[Joonas Lahtinen]

Quoting Dave Airlie (2021-08-11 06:48:39)
> dim: db47fe727e1f ("drm/i915/step:
> s/_revid_tbl/_revids"): committer Signed-off-by
> missing.
> 
> I'm not sure how much pain it is to fix that up, but
> commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
> Author: Anusha Srivatsa 
> Commit: Matt Roper 
> 
> drm/i915/step: s/_revid_tbl/_revids
> 
> Simplify the stepping info array name.
> 
> Cc: Jani Nikula 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Jani Nikula 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
> 
> It's definitely missing an S-o-b by anyone who handled the patch.
> 
> Let me know if it's insanely painful to fix that.

Added you to the earlier mail thread that discussed the incident.

There are now 277 patches on top of that patch, so means rebasing all of
those and changing the hashes and trying to fixup all the Fixes:.

So it's painful but not insanely so. Let me know if you want the tree
rebased.

Regards, Joonas

Re: [Intel-gfx] refactor the i915 GVT support

[Joonas Lahtinen]

Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this?  I'd really hate to miss this merge window.
> > > 
> > > I'm still waiting for our validation team's report on this. I'm afraid
> > > it might be missing for next version as i915 merge window is mostly
> > > till rc5...and for any change outside of gvt, it still needs to be
> > > acked by i915 maintainers.
> > 
> > Looks our validation team did have problem against recent i915 change.
> > If you like to try, we have a gvt-staging branch on
> > https://github.com/intel/gvt-linux which is generated against drm-tip
> > with gvt changes for testing, currently it's broken.
> > 
> > One issue is with i915 export that intel_context_unpin has been
> > changed into static inline function. Another is that intel_gvt.c
> > should be part of i915 for gvt interface instead of depending on KVMGT
> > config.
> 
> I'm working on below patch to resolve this. But I met a weird issue in
> case when building i915 as module and also kvmgt module, it caused
> busy wait on request_module("kvmgt") when boot, it doesn't happen if
> building i915 into kernel. I'm not sure what could be the reason?
> 
> > But the problem I see is that after moving gvt device model (gvt/*.c
> > except kvmgt.c) into kvmgt module, we'll have issue with initial mmio
> > state which current gvt relies on, that is in design supposed to get
> > initial HW state before i915 driver has taken any operation.

As mentioned in some past discussions, I think it would be best rely on
golden MMIO located in /lib/firmware or elsewhere. This way we will better
isolate the guest system from host system updates/changes.

This should also hopefully allow enabling kvmgt module after i915 has
already loaded, as the initialization would not be conditional to
capture the MMIO.

Regards, Joonas

> > Before
> > we can ensure that, I think we may only remove MPT part first but
> > still keep gvt device model as part of i915 with config. I'll try to
> > split that out.
> 
> Sorry I misread the code that as we always request kvmgt module when
> gvt init, so it should still apply original method that this isn't a
> problem. Our current validation result has shown no regression as well.
> 
> ---8<---
> From 58ff84572f1a0f9d79ca1d7ec0cff5ecbe78d280 Mon Sep 17 00:00:00 2001
> From: Zhenyu Wang 
> Date: Thu, 19 Aug 2021 16:36:33 +0800
> Subject: [PATCH] TESTONLY:drm/i915/gvt: potential fix for refactor against
>  current tip
> 
> ---
>  drivers/gpu/drm/i915/Makefile   | 4 +++-
>  drivers/gpu/drm/i915/gt/intel_context.c | 5 +
>  drivers/gpu/drm/i915/gt/intel_context.h | 3 ++-
>  drivers/gpu/drm/i915/i915_trace.h   | 1 +
>  4 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c4f953837f72..2248574428a1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -296,7 +296,9 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
>  
>  # virtual gpu code
>  i915-y += i915_vgpu.o
> -i915-$(CONFIG_DRM_I915_GVT_KVMGT) += intel_gvt.o
> +ifneq ($(CONFIG_DRM_I915_GVT_KVMGT),)
> +i915-y += intel_gvt.o
> +endif
>  
>  kvmgt-y += gvt/kvmgt.o \
> gvt/gvt.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 745e84c72c90..20e7522fed84 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -328,6 +328,11 @@ void __intel_context_do_unpin(struct intel_context *ce, 
> int sub)
> intel_context_put(ce);
>  }
>  
> +void intel_context_unpin(struct intel_context *ce)
> +{
> +   _intel_context_unpin(ce);
> +}
> +
>  static void __intel_context_retire(struct i915_active *active)
>  {
> struct intel_context *ce = container_of(active, typeof(*ce), active);
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index c41098950746..f942cbf6300a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -131,7 +131,7 @@ static inline void 
> intel_context_sched_disable_unpin(struct intel_context *ce)
> __intel_context_do_unpin(ce, 2);
>  }
>  
> -static inline void intel_context_unpin(struct intel_context *ce)
> +static inline void _intel_context_unpin(struct intel_context *ce)
>  {
> if (!ce->ops->sched_disable) {
> __intel_context_do_unpin(ce, 1);
> @@ -150,6 +150,7 @@ static inline void intel_context_unpin(struct 
> intel_context *ce)
> }
> }
>  }
> +void intel_context_unpin(struct intel_context *ce);
>  
>  void intel_context_enter_engine(struct intel_context *ce);
>  void intel_context_exit_engine(struct intel_context *ce);
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index 806ad688274

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Fix use of err in igt_reset_{fail, nop}_engine()

[Joonas Lahtinen]

Quoting Nathan Chancellor (2021-08-23 22:08:37)
> Ping? This is a pretty clear bug and it is not fixed in -next or
> drm-intel at this point.

Pushed to drm-intel-gt-next with my R-b.

Regards, Joonas

> On Fri, Aug 13, 2021 at 10:11:58AM -0700, Nathan Chancellor wrote:
> > Clang warns:
> > 
> > In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable
> > 'err' is uninitialized when used here [-Wuninitialized]
> > pr_err("[%s] Create context failed: %d!\n", engine->name, err);
> >   ^~~
> > ...
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c:580:62: warning: variable
> > 'err' is uninitialized when used here [-Wuninitialized]
> > pr_err("[%s] Create context failed: %d!\n", engine->name, err);
> >   ^~~
> > ...
> > 2 warnings generated.
> > 
> > This appears to be a copy and paste issue. Use ce directly using the %pe
> > specifier to pretty print the error code so that err is not used
> > uninitialized in these functions.
> > 
> > Fixes: 3a7b72665ea5 ("drm/i915/selftest: Bump selftest timeouts for 
> > hangcheck")
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Nathan Chancellor 
> > ---
> >  drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
> > b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > index 08f011f893b2..2c1ed32ca5ac 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> > @@ -462,7 +462,7 @@ static int igt_reset_nop_engine(void *arg)
> >  
> >   ce = intel_context_create(engine);
> >   if (IS_ERR(ce)) {
> > - pr_err("[%s] Create context failed: %d!\n", 
> > engine->name, err);
> > + pr_err("[%s] Create context failed: %pe!\n", 
> > engine->name, ce);
> >   return PTR_ERR(ce);
> >   }
> >  
> > @@ -577,7 +577,7 @@ static int igt_reset_fail_engine(void *arg)
> >  
> >   ce = intel_context_create(engine);
> >   if (IS_ERR(ce)) {
> > - pr_err("[%s] Create context failed: %d!\n", 
> > engine->name, err);
> > + pr_err("[%s] Create context failed: %pe!\n", 
> > engine->name, ce);
> >   return PTR_ERR(ce);
> >   }
> >  
> > 
> > base-commit: 927dfdd09d8c03ba100ed0c8c3915f8e1d1f5556
> > -- 
> > 2.33.0.rc2

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Remove require_force_probe protection

[Joonas Lahtinen]

Quoting Siddiqui, Ayaz A (2021-09-07 08:43:52)
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of Talla
> > Raviteja Goud
> > Sent: Friday, September 3, 2021 11:51 PM
> > To: intel-gfx@lists.freedesktop.org; Surendrakumar Upadhyay, TejaskumarX
> > ; Meena, Mahesh
> > ; Pandey, Hariom 
> > Cc: Talla, RavitejaX Goud ; De Marchi, Lucas
> > 
> > Subject: [Intel-gfx] [PATCH] drm/i915/adl_s: Remove require_force_probe
> > protection
> > 
> > From: ravitejax 

Raviteja, please check your git settings and fill in full name there.

Ayaz, Thomas, when reviewing and merging patches, please pay attention
to the From: and Signed-off-by: tags to make sure they are correct.

Regards, Joonas

Re: [Intel-gfx] [bugzilla-dae...@bugzilla.kernel.org: [Bug 213519] New: WARNING on system reboot in: drivers/gpu/drm/i915/intel_runtime_pm.c:635 intel_runtime_pm_driver_release]

[Joonas Lahtinen]

Hi Joel,

That seems like a genuine bug. Could you file it at the i915 bug tracker
with all the requested information to make sure we can take a look at
it:

https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

Are you able to try different kernel versions to bisect which kernel
version/commit introduced the WARN?

Regards, Joonas

Quoting Bjorn Helgaas (2021-06-22 00:51:32)
> [+cc Joel (reporter)]
> 
> On Mon, Jun 21, 2021 at 04:50:14PM -0500, Bjorn Helgaas wrote:
> > - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
> > 
> > Date: Mon, 21 Jun 2021 02:50:09 +
> > From: bugzilla-dae...@bugzilla.kernel.org
> > To: bj...@helgaas.com
> > Subject: [Bug 213519] New: WARNING on system reboot in:
> >   drivers/gpu/drm/i915/intel_runtime_pm.c:635 
> > intel_runtime_pm_driver_release
> > Message-ID: 
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=213519
> > 
> > Bug ID: 213519
> >Summary: WARNING on system reboot in:
> > drivers/gpu/drm/i915/intel_runtime_pm.c:635
> > intel_runtime_pm_driver_release
> >Product: Drivers
> >Version: 2.5
> > Kernel Version: 5.12.12
> >   Hardware: x86-64
> > OS: Linux
> >   Tree: Mainline
> > Status: NEW
> >   Severity: normal
> >   Priority: P1
> >  Component: PCI
> >   Assignee: drivers_...@kernel-bugs.osdl.org
> >   Reporter: j-c...@westvi.com
> > Regression: No
> > 
> > Created attachment 297517
> >   --> https://bugzilla.kernel.org/attachment.cgi?id=297517&action=edit
> > Contents of 'warning' stack trace, etc.
> > 
> > As mentioned in summary - warning message in this routine at system reboot. 
> > Try
> > as I might, I cannot include the text of the warning directly here in the
> > description without losing carriage returns, so I include it as a text
> > attachment.
> > 
> > - End forwarded message -
> > 
> > [Attachment contents below]
> > 
> > [  239.019148] [ cut here ]
> > [  239.024226] i915 :00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup
> > [  239.031561] WARNING: CPU: 4 PID: 2484 at 
> > drivers/gpu/drm/i915/intel_runtime_pm.c:635 
> > intel_runtime_pm_driver_release+0x4f/0x60
> > [  239.043974] Modules linked in: mei_wdt x86_pkg_temp_thermal 
> > ghash_clmulni_intel mei_me mei cryptd
> > [  239.053656] CPU: 4 PID: 2484 Comm: reboot Not tainted 5.12.12 #1
> > [  239.060236] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> > O.E.M./NUC-8665UE, BIOS P1.50 06/04/2021
> > [  239.070766] RIP: 0010:intel_runtime_pm_driver_release+0x4f/0x60
> > [  239.077256] Code: 10 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 59 8f 11 00 
> > 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 f8 25 7d b0 e8 06 e8 67 00 
> > <0f> 0b 5b 41 5c 41 5d 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 48
> > [  239.097700] RSP: 0018:b8c682f3bd30 EFLAGS: 00010286
> > [  239.103422] RAX:  RBX: 0001 RCX: 
> > b0af01e8
> > [  239.85] RDX:  RSI: dfff RDI: 
> > b0a401e0
> > [  239.118850] RBP: b8c682f3bd48 R08:  R09: 
> > b8c682f3bb08
> > [  239.126617] R10: b8c682f3bb00 R11: b0b20228 R12: 
> > 0001
> > [  239.134390] R13: 978680d114b0 R14: 97868197eae8 R15: 
> > fee1dead
> > [  239.142203] FS:  7f741a182580() GS:9789dc50() 
> > knlGS:
> > [  239.151044] CS:  0010 DS:  ES:  CR0: 80050033
> > [  239.157318] CR2: 0169f4c8 CR3: 00019cf14003 CR4: 
> > 003706e0
> > [  239.165098] DR0:  DR1:  DR2: 
> > 
> > [  239.172874] DR3:  DR6: fffe0ff0 DR7: 
> > 0400
> > [  239.180658] Call Trace:
> > [  239.183346]  i915_driver_shutdown+0xcf/0xe0
> > [  239.187920]  i915_pci_shutdown+0x10/0x20
> > [  239.192181]  pci_device_shutdown+0x35/0x60
> > [  239.196629]  device_shutdown+0x156/0x1b0
> > [  239.200827]  __do_sys_reboot.cold+0x2f/0x5b
> > [  239.205410]  __x64_sys_reboot+0x16/0x20
> > [  239.209586]  do_syscall_64+0x38/0x50
> > [  239.213399]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> > [  239.218837] RIP: 0033:0x7f741a0a9bc3
> > [  239.222740] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 
> > 0f 1f 44 00 00 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 
> > <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 71 c2 0c 00 f7 d8
> > [  239.243228] RSP: 002b:7ffcc2a16488 EFLAGS: 0206 ORIG_RAX: 
> > 00a9
> > [  239.251503] RAX: ffda RBX: 7ffcc2a165d8 RCX: 
> > 7f741a0a9bc3
> > [  239.259304] RDX: 01234567 RSI: 28121969 RDI: 
> > fee1dead
> > [  239.267105] RBP: 0004 R08:  R09: 
> > 0169e2e0
> > [  239.274926] R10: fd06 R1

Re: [Intel-gfx] 5.13-rc6 on thinkpad X220: graphics hangs with recent mainline

[Joonas Lahtinen]

Quoting Pavel Machek (2021-06-24 12:53:59)
> Hi!
> 
> I'm getting graphics problems with 5.13-rc:
> 
> Debian 10.9, X, chromium and flightgear is in use. Things were more
> stable than this with previous kernels.
> 
> Any ideas?

The error you are seeing:

> [185300.784992] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat 
> on rcs0
> [185300.888694] i915 :00:02.0: [drm] fgfs[27370] context reset due to GPU 
> hang

That just indicates that the rendering took too long. It could be caused
by a change in how the application renders, userspace driver or i915. So
a previously on-the-edge-of-timeout operation may have got pushed beyond
the timeout, or the rendering genuinely got completely stuck.

If you only updated the kernel, not the application or userspace, could
you bisect the commit that introduced the behavior and report:

https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

We have changes around this area, so would be helpful if you can bisect
the commit that started the behavior.

Regards, Joonas

> 
> Best regards,
> Pavel
> 
> [185233.329693] wlp3s0: deauthenticated from 5c:f4:ab:10:d2:bb (Reason: 
> 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
> [185234.040352] wlp3s0: authenticate with 5c:f4:ab:10:d2:bb
> [185234.043836] wlp3s0: send auth to 5c:f4:ab:10:d2:bb (try 1/3)
> [185234.046652] wlp3s0: authenticated
> [185234.049087] wlp3s0: associate with 5c:f4:ab:10:d2:bb (try 1/3)
> [185234.052667] wlp3s0: RX AssocResp from 5c:f4:ab:10:d2:bb (capab=0x411 
> status=0 aid=1)
> [185234.055398] wlp3s0: associated
> [185300.784992] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat 
> on rcs0
> [185300.888694] i915 :00:02.0: [drm] fgfs[27370] context reset due to GPU 
> hang
> [185472.274563] usb 2-1.1: USB disconnect, device number 3
> [185472.274578] usb 2-1.1.2: USB disconnect, device number 5
> [185472.281518] hid-generic 0003:04F2:0111.0003: usb_submit_urb(ctrl) failed: 
> -19
> [185472.299837] hid-generic 0003:04F2:0111.0003: usb_submit_urb(ctrl) failed: 
> -19
> [185472.305986] hid-generic 0003:04F2:0111.0003: usb_submit_urb(ctrl) failed: 
> -19
> [185472.328012] hid-generic 0003:04F2:0111.0003: usb_submit_urb(ctrl) failed: 
> -19
> [185472.333738] usb 2-1.1.3: USB disconnect, device number 6
> [185673.454821] usb 2-1.1: new high-speed USB device number 7 using ehci-pci
> [185673.563486] usb 2-1.1: New USB device found, idVendor=1a40, 
> idProduct=0101, bcdDevice= 1.11
> [185673.563502] usb 2-1.1: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
> [185673.563509] usb 2-1.1: Product: USB 2.0 Hub
> [185673.564488] hub 2-1.1:1.0: USB hub found
> [185673.564595] hub 2-1.1:1.0: 4 ports detected
> ...
> [207277.385543] wlp3s0: deauthenticated from 5c:f4:ab:10:d2:bb (Reason: 
> 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
> [207278.062061] wlp3s0: authenticate with 5c:f4:ab:10:d2:bb
> [207278.068175] wlp3s0: send auth to 5c:f4:ab:10:d2:bb (try 1/3)
> [207278.070985] wlp3s0: authenticated
> [207278.075545] wlp3s0: associate with 5c:f4:ab:10:d2:bb (try 1/3)
> [207278.080793] wlp3s0: RX AssocResp from 5c:f4:ab:10:d2:bb (capab=0x411 
> status=0 aid=1)
> [207278.084081] wlp3s0: associated
> [207564.046469] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat 
> on rcs0
> [207564.150293] i915 :00:02.0: [drm] fgfs[25729] context reset due to GPU 
> hang
> [209075.178776] wlp3s0: deauthenticated from 5c:f4:ab:10:d2:bb (Reason: 
> 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
> [209075.841872] wlp3s0: authenticate with 5c:f4:ab:10:d2:bb
> [209075.845305] wlp3s0: send auth to 5c:f4:ab:10:d2:bb (try 1/3)
> [209075.851186] wlp3s0: authenticated
> [209075.852537] wlp3s0: associate with 5c:f4:ab:10:d2:bb (try 1/3)
> [209075.855972] wlp3s0: RX AssocResp from 5c:f4:ab:10:d2:bb (capab=0x411 
> status=0 aid=1)
> [209075.858522] wlp3s0: associated
> [210159.723726] PM: suspend entry (deep)
> [210159.741497] Filesystems sync: 0.017 seconds
> [210159.743585] Freezing user space processes ... (elapsed 0.009 seconds) 
> done.
> [210159.753345] OOM killer disabled.
> [210159.753349] Freezing remaining freezable tasks ... (elapsed 0.003 
> seconds) done.
> [210159.757357] printk: Suspending console(s) (use no_console_suspend to 
> debug)
> [210159.945365] sd 2:0:0:0: [sdb] Synchronizing SCSI cache
> [210159.945443] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [210159.945651] sd 0:0:0:0: [sda] Stopping disk
> [210159.947225] sd 2:0:0:0: [sdb] Stopping disk
> [210160.019791] wlp3s0: deauthenticating from 5c:f4:ab:10:d2:bb by local 
> choice (Reason: 3=DEAUTH_LEAVING)
> [210160.021158] e1000e: EEE TX LPI TIMER: 0011
> [210161.245106] PM: suspend devices took 1.488 seconds
> [210161.266601] ACPI: EC: interrupt blocked
> [210161.305431] ACPI: Preparing to enter system sleep state S3
> [210161.313532] ACPI: EC: event blocked
> [210161.313535] ACPI: EC: EC stopped
> [210161.313537] PM: Saving platform NVS memory
> [210161.313548] Disabl

Re: [Intel-gfx] [PATCH] drm/i915: Improve debug Kconfig texts a bit

[Joonas Lahtinen]

Quoting Daniel Vetter (2021-07-02 23:17:08)
> We're not consistently recommending these for developers only.
> 
> I stumbled over this due to DRM_I915_LOW_LEVEL_TRACEPOINTS, which was
> added in
> 
> commit 354d036fcf70654cff2e2cbdda54a835d219b9d2
> Author: Tvrtko Ursulin 
> Date:   Tue Feb 21 11:01:42 2017 +
> 
> drm/i915/tracepoints: Add request submit and execute tracepoints
> 
> to "alleviate the performance impact concerns."
> 
> Which is nonsense.

I think that was the original reason why the patch was developed and
it got merged primarily for the latter reason. Unfortunately the patch
commit messages don't always get rewritten.

> Tvrtko and Joonas pointed out on irc that the real (but undocumented
> reason) was stable abi concerns for tracepoints, see
> 
> https://lwn.net/Articles/705270/
> 
> and the specific change that was blocked around tracepoints:
> 
> https://lwn.net/Articles/442113/
> 
> Anyway to make it a notch clearer why we have this Kconfig option
> consistly add the "Recommended for driver developers only." to it and
> all the other debug options we have.
> 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc: Matthew Brost 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> ---
>  drivers/gpu/drm/i915/Kconfig.debug | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 2ca88072d30f..f27c0b5873f7 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -215,6 +215,8 @@ config DRM_I915_LOW_LEVEL_TRACEPOINTS
>   This provides the ability to precisely monitor engine utilisation
>   and also analyze the request dependency resolving timeline.
>  
> + Recommended for driver developers only.
> +
>   If in doubt, say "N".
>  
>  config DRM_I915_DEBUG_VBLANK_EVADE
> @@ -228,6 +230,8 @@ config DRM_I915_DEBUG_VBLANK_EVADE
>   is exceeded, even if there isn't an actual risk of missing
>   the vblank.
>  
> + Recommended for driver developers only.
> +
>   If in doubt, say "N".
>  
>  config DRM_I915_DEBUG_RUNTIME_PM
> @@ -240,4 +244,6 @@ config DRM_I915_DEBUG_RUNTIME_PM
>   runtime PM functionality. This may introduce overhead during
>   driver loading, suspend and resume operations.
>  
> + Recommended for driver developers only.
> +
>   If in doubt, say "N"
> -- 
> 2.32.0.rc2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Daniel,

Bit late PR due to Easter break. 

Prep work for local memory support as requested. Hard hang
fix for Sandybridge. Sanitize dma-buf size on import and
avoid GPU reset if heartbeat callback runs before timeout.

The rest is mostly small fixes and code/checkpatch cleanups.

Regards, Joonas

***

drm-intel-gt-next-2021-04-06:
Driver Changes:

- Prepare for local/device memory support on DG1 by starting
  to use it for kernel internal allocations: context, ring
  and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)

- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)

- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)

The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897:

  Merge tag 'drm-intel-next-2021-03-16' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-04-06

for you to fetch changes up to 2da21daa7d93817fa82f703c29adfcb5eed7f77d:

  drm/i915/gt: Always flush the submission queue on checking for idle 
(2021-03-24 19:31:59 +0100)


Driver Changes:

- Prepare for local/device memory support on DG1 by starting
  to use it for kernel internal allocations: context, ring
  and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)

- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)

- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)


Abdiel Janulgue (1):
  drm/i915: introduce mem->reserved

CQ Tang (1):
  drm/i915: reserve stolen for LMEM region

Chris Wilson (22):
  drm/i915: Strip out internal priorities
  drm/i915: Remove I915_USER_PRIORITY_SHIFT
  drm/i915/gt: Call stop_ring() from ring resume, again
  drm/i915/gt: SPDX cleanup
  drm/i915/gt: Add some missing blank lines after declaration
  drm/i915/gt: Remove repeated words from comments
  drm/i915/gt: Fixup misaligned function parameters
  drm/i915/gt: Remove a bonus newline
  drm/i915/gt: Wrap macro arg in ()
  drm/i915/gt: Insert spaces into GEN3_L3LOG_SIZE/4
  drm/i915/gt: Replace unnecessary ',' with '; '
  drm/i915/gt: Add a space before '('
  drm/i915/gt: Replace 'return' with a fall-through
  drm/i915/selftests: Check for engine-reset errors in the middle of 
workarounds
  drm/i915/gt: Move the defer_request waiter active assertion
  drm/i915: Protect against request freeing during cancellation on wedging
  drm/i915/selftests: Use a single copy of the mocs table
  drm/i915/gt: Retire unexpected starting state error dumping
  drm/i915/selftests: Restore previous heartbeat interval
  drm/i915/gt: Double check heartbeat timeout before resetting
  drm/i915/selftest: Synchronise with the GPU timestamp
  drm/i915/gt: Always flush the submission queue on checking for idle

Emil Renner Berthing (1):
  drm/i915/gt: use new tasklet API for execution list

Imre Deak (1):
  drm/i915/dg1: Reserve first 1MB of local memory

Matthew Auld (11):
  drm/i915/gem: don't trust the dma_buf->size
  drm/i915/gem: consolid

Re: [Intel-gfx] [PATCH v2 00/12] drm/i915: Extend GEN renames to the rest of the driver

[Joonas Lahtinen]

+ Tvrtko

Quoting Jani Nikula (2021-04-14 13:06:42)
> On Wed, 14 Apr 2021, Jani Nikula  wrote:
> > On Tue, 13 Apr 2021, Jani Nikula  wrote:
> >> On Mon, 12 Apr 2021, Lucas De Marchi  wrote:
> >>> Like was done for the display part that parted ways with INTEL_GEN(),
> >>> replacing with DISPLAY_VER(), do a similar conversion for the rest of
> >>> the driver.
> >>>
> >>> v1.1: Remove .ko that was incorrectly added as part of patch 11, making it
> >>> very big and not going through the mailing list. Sorry for those in CC
> >>> who received it.
> >>>
> >>> v2:
> >>>   - Add "drm/i915/display: rename display version macros" to rename
> >>> macro and repurpose it: s/IS_DISPLAY_RANGE/IS_DISPLAY_VER/ and convert
> >>> the current users of IS_DISPLAY_VER to use direct comparison
> >>>   - Group display patches to easily apply independently
> >>
> >> I like the direction here. Even as the version checks diversify, we
> >> manage to simplify and reduce the macros.
> >>
> >> I think we're going to have to queueu this via a topic branch, and merge
> >> that to both drm-intel-next and drm-intel-gt-next. The next time the
> >> branches can sync up is just too far away at this point, and the
> >> conflicts may be really nasty to solve later.
> >>
> >> That does mean having to solve the conflict with 70bfb30743d5
> >> ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") which is in din but not
> >> dign. The topic branch would be based on:
> >>
> >> $ git merge-base drm-intel/drm-intel-next drm-intel/drm-intel-gt-next
> >> 9c0fed84d5750e1eea6c664e073ffa2534a17743
> >>
> >> There are two (crappy?) ideas to make that easier. 1) revert
> >> 70bfb30743d5 from din and add it to the topic branch instead, 2) don't
> >> revert it but cherry-pick it to the topic branch also.
> >>
> >> Cc: Joonas and Daniel for their input on this as well.
> >
> > I've created the topic branch topic/intel-gen-to-ver where the series
> > should be applied.
> >
> > However, for the reasons above, it does not apply as-is, and the merge
> > will conflict slightly.
> >
> > Also, I think Ville's fixes [1] should land on the topic branch *first*
> > because they need to be propagated to drm-intel-next-fixes.
> 
> I went ahead and:
> 
> * Created the topic branch topic/intel-gen-to-ver with the merge-base
>   mentioned above.
> 
> * Cherry-picked 70bfb30743d5 on the topic branch to avoid major
>   conflicts, as suggested by Daniel on IRC.
> 
> * Reviewed and applied Ville's series [1] on the topic branch.
> 
> * Reviewed and applied this series on the topic branch.
> 
>   - There were a couple of tiny conflicts between patch 3 and Ville's
> series, and I fixed the conflicts while applying.
> 
>   - I also fixed my comment nitpicks while applying.
> 
>   - I usually refrain from doing any changes while applying, but in this
> case I considered the changes very small, and did not want to delay
> this any further.
> 
> Please chime in now if you have issues with this series! Explicit acks
> would be much appreciated; they can be added to the topic merge commit.

I think GT_VER() would be preferred over the more ambiguous GRAPHICS_VER()
and would better align with the attempt to consolidate the naming
difference between display and GT.

The GPU as whole is referred to as Intel Graphics, so otherwise will be
easy to draw wrong conclusions for 3rd parties looking at the code.

With GT_VER() or something else more distinctive this is:

Acked-by: Joonas Lahtinen 

Regards, Joonas

> 
> I hope to send the pull request and get this merged by Thursday, to
> avoid creating more conflicts.
> 
> 
> BR,
> Jani.
> 
> >
> >
> > [1] 
> > https://lore.kernel.org/intel-gfx/20210412054607.18133-1-ville.syrj...@linux.intel.com/
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next

[Joonas Lahtinen]

Quoting Jani Nikula (2021-04-19 12:53:11)
> 
> Hi Joonas and Rodrigo -
> 
> Here's the gen to ver conversion topic branch to be merged to both
> drm-intel-next and drm-intel-gt-next.

Pulled.

Regards, Joonas

> Lots of Cc's for heads up.
> 
> 
> BR,
> Jani.
> 
> 
> topic/intel-gen-to-ver-2021-04-19:
> Gen to ver conversions across the driver
> 
> The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
> cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
> conflicts.
> 
> [1] https://patchwork.freedesktop.org/series/88825/
> [2] https://patchwork.freedesktop.org/series/88938/
> [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")
> 
> BR,
> Jani.
> 
> The following changes since commit 9c0fed84d5750e1eea6c664e073ffa2534a17743:
> 
>   Merge tag 'drm-intel-next-2021-04-01' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-04-08 
> 14:02:21 +1000)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel 
> tags/topic/intel-gen-to-ver-2021-04-19
> 
> for you to fetch changes up to 425390c5dce6da76578389629d19517fcd79c959:
> 
>   drm/i915: split dgfx features from gen 12 (2021-04-14 13:05:06 +0300)
> 
> 
> Gen to ver conversions across the driver
> 
> The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
> cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
> conflicts.
> 
> [1] https://patchwork.freedesktop.org/series/88825/
> [2] https://patchwork.freedesktop.org/series/88938/
> [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")
> 
> 
> Lucas De Marchi (12):
>   drm/i915/display: use DISPLAY_VER() on remaining users
>   drm/i915: rename display.version to display.ver
>   drm/i915/display: rename display version macros
>   drm/i915: add macros for graphics and media versions
>   drm/i915/gt: replace gen use in intel_engine_cs
>   drm/i915/selftests: replace unused mask with simple version
>   drm/i915/selftests: eliminate use of gen_mask
>   drm/i915: finish removal of gen_mask
>   drm/i915: eliminate remaining uses of intel_device_info->gen
>   drm/i915: finish removal of gen from intel_device_info
>   drm/i915: add media and display versions to device_info print
>   drm/i915: split dgfx features from gen 12
> 
> Matt Roper (1):
>   drm/i915/display: Eliminate IS_GEN9_{BC,LP}
> 
> Ville Syrjälä (5):
>   drm/i915: Restore lost glk FBC 16bpp w/a
>   drm/i915: Restore lost glk ccs w/a
>   drm/i915: Disable LTTPR detection on GLK once again
>   drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glk
>   drm/i915: Remove a few redundant glk checks
> 
>  drivers/gpu/drm/i915/display/i9xx_plane.c  |  2 +-
>  drivers/gpu/drm/i915/display/icl_dsi.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_atomic.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_audio.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_bios.c  |  9 +--
>  drivers/gpu/drm/i915/display/intel_bw.c|  8 +--
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 42 +++---
>  drivers/gpu/drm/i915/display/intel_color.c |  6 +-
>  drivers/gpu/drm/i915/display/intel_crt.c   |  6 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_csr.c   |  4 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c   | 53 +-
>  drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 10 ++--
>  drivers/gpu/drm/i915/display/intel_display.c   | 64 
> +++---
>  .../gpu/drm/i915/display/intel_display_debugfs.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_display_power.c | 57 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c| 10 ++--
>  .../gpu/drm/i915/display/intel_dp_link_training.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_dpll.c  |  8 +--
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c  |  6 +-
>  drivers/gpu/drm/i915/display/intel_fb.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_fbc.c   | 21 +++
>  drivers/gpu/drm/i915/display/intel_fifo_underrun.c |  4 +-
>  drivers/gpu/drm/i915/display/intel_gmbus.c | 12 ++--
>  drivers/gpu/drm/i915/display/intel_hdcp.c  |  9 +--
>  drivers/gpu/drm/i915/display/intel_hdmi.c  |  9 +--
>  drivers/gpu/drm/i915/display/intel_lvds.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_overlay.c   | 10 ++--
>  drivers/gpu/drm/i915/display/intel_panel.c | 10 ++--
>  drivers/gpu/drm/i915/display/intel_pipe_crc.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_pps.c   | 14 ++---
>  drivers/gpu/drm/i915/display/intel_psr.c   |  4 +-
>  drivers/gpu/drm/i

Re: [Intel-gfx] REGRESSION with 5.12: Suspend not working on Toshiba notebook

[Joonas Lahtinen]

+ intel-gfx mailing list

Quoting Zhenyu Wang (2021-04-30 02:58:28)
> On 2021.04.29 20:14:50 +0200, Andreas Friedrich wrote:
> > Hello Joonas,
> > 
> > with kernel 5.12 suspend to memory is no longer working on my old
> > Toshiba Tecra A10 notebook.
> > 
> > After calling /sbin/pm-suspend the screen is dimmed but the CPU fan is
> > still running, the system is frozen and is not in suspended state. The
> > only way to get the system working again is to hard power off and on.
> > 
> > Kernel 5.11.16 works well.
> > 
> > Bisecting the kernel leads me to your commit, which caused the problem:
> > 
> >   commit c071a6c0fef0fade787d827c7fc0e07481512326 (HEAD, refs/bisect/bad)
> >   Merge: a2dd2ff50cde 02dd2b12a685
> >   Author: Joonas Lahtinen 
> >   Date:   Thu Jan 21 15:10:16 2021 +0200
> > 
> > Merge tag 'gvt-gt-next-2021-01-18' of 
> > https://github.com/intel/gvt-linux into drm-intel-gt-next
> > 
> > gvt-gt-next-2021-01-18
> > 
> > - GVT cmd parser enhancement against guest context (Yan)
> > 
> > Signed-off-by: Joonas Lahtinen 
> > From: Zhenyu Wang 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20210118050739.gy15...@zhen-hp.sh.intel.com

That is a merge commit, it doesn't itself change anything as there were no
conflicts. It just indicates that two trees got merged.

Bisecting should end up in a commit that has code changes. Then you should
be able to try to revert the offending commit from the latest mainline kernel.
Most of the time that can be used to confirm that reverting specific commit
fixes issue (unless the commit has a lot of dependencies). This is not
required though, if you are able to bisect to a single code change commit
that'll allow us to provide fix to try.

If you are able to provide a bisect to a one patch, please do report it
as a bug, let's then take it from there.

See:

https://01.org/linuxgraphics/documentation/how-report-bugs

> > Not every suspend results in a frozen system, so I think a race
> > condition is on the way.

This would further tip the scale towards the bisect being a false
positive. I know it can be painful to do dozens of runs per each
bisecting point, but it's really needed to arrive at the right patch.

What kind of rate you have for hitting the issue on 5.12 kernel?

> > Appendix:
> > - Kernel configuration "5.12.config.gz"
> > - My grub kernel boot parameters:
> >   root=/dev/sda5 snd-hda-intel.model=toshiba resume=/dev/sda3 printk.time=1
> > 
> > Please let me know if I could help to fix the problem.
> > 
> 
> Looks gvt is not enabled in config or runtime, so can't think that gvt merge 
> should be related...

Yes, I think the merge commit is a red herring.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] REGRESSION with 5.12: Suspend not working on Toshiba notebook

[Joonas Lahtinen]

Quoting Andreas Friedrich (2021-04-30 13:36:35)
> On Fri, Apr 30, 2021 at 11:31:47AM +0300, Joonas Lahtinen wrote:
> 
> Hello Joonas,
> 
> thank you for your quick response.
> ...
> > That is a merge commit, it doesn't itself change anything as there were no
> > conflicts. It just indicates that two trees got merged.
> ...
> > If you are able to provide a bisect to a one patch, please do report it
> > as a bug, let's then take it from there.
> 
> I have bisect the kernel 3 times and it always leads me to the wrong
> end. Because not every suspend results in a frozen system, maybe I
> have marked a 'bisect good' although it was bad.

This is most likely the problem. You should try each suggested commit
enough times to gain confidence in if it's good or bad build.

> What I surely can say is, that kernel 5.11.16 works fine and 5.12-rc1
> (v5.12-rc1-dontuse) does not.
> 
> However, on the bisecting path I saw the following commits:
>   [41a9c75d0acf23f33f012d3f9535de9e9b631051] drm/i915/gem: Move stolen node 
> into GEM object union
>   [d82afcf9caaac26ce264255bca9dacf30f41] Merge tag 
> 'drm-intel-gt-next-2021-01-21-1' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next
>   [885e1938452fc7fc37a3051d76e1ddb7ead099fa] drm/i915/gvt: statically set 
> F_CMD_WRITE_PATCH flag
>   [a2dd2ff50cde3cbbeecec72225bb18582b291f14] drm/i915/gt: Skip over completed 
> active execlists, again
>   [02dd2b12a685944c4d52c569d05f636372a7b6c7] drm/i915/gvt: unify lri cmd 
> handler and mmio handlers
>   [69b4b99842201bc24c98ba66b922d8879e190483] drm/i915/gvt: Add missing 
> forward decl of intel_vgpu for HDRTEST
>   [c071a6c0fef0fade787d827c7fc0e07481512326] Merge tag 
> 'gvt-gt-next-2021-01-18' of https://github.com/intel/gvt-linux into 
> drm-intel-gt-next

As Zhenyu mentioned, you don't even have GVT module enabled, so most of
those are guaranteed to be incorrectly bisected. And there are two merge
commits with no conflicts (== no code change).

Bisect should end so that the previous commit is good, and the new
commit is bad. If there are no code changes in the commit, there's
no way it can be the commit that is really the culprit.

Without a proper bisect, it'll be quite difficult to start the triage
on our side.

> So I think it's a drm-i915 issue. I have communicated with David
> Airlie (airl...@redhat.com) and he also bets on an i915 bug.

It's very possible that it can be i915 bug. What you can try is to
blacklist i915 module and operate the system with SSH and see if the
latest kernel still freezes?

Also, please try drm-tip kernel and see if it fixed there.

> > https://01.org/linuxgraphics/documentation/how-report-bugs
> 
> Following 
> https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
> I can give you the following infos:
>   - After calling 'echo mem > /sys/power/state' the system gets frozen
> (the screen is dimmed but the CPU fan is still running). The
> system is inaccessible from remote. The only way to get it working
> again is to hard power off and on.
>   - One out of 5 suspend tries will cause the issue, mostly the first one.
>   - Notebook: Old Toshiba Tecra A10 from 2009.
>   - x86_64, 5.12-rc1, Debian GNU/Linux 10 (buster), see dmidecode.txt.gz
> and 5.12.config.gz
>   - Because the system is frozen, I cannot read /sys/class/drm/card0/error
> before rebooting.
> 
> Please let me know if I can do anyting else to solve the problem.

Please do file a bug on the issue tracker as requested:

https://gitlab.freedesktop.org/drm/intel/issues/

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915/execlists: Move RPCS setup to context pin

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:22:46)
> From: Tvrtko Ursulin 
> 
> Configuring RPCS in context image just before pin is sufficient and will
> come extra handy in one of the following patches.
> 
> v2:
>  * Split image setup a bit differently. (Chris Wilson)
> 
> v3:
>  * Update context image after reset as well - otherwise the application
>of pinned default state clears the RPCS.
> 
> v4:
>  * Use local variable throughout the function. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Suggested-by: Chris Wilson 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 



> +static u32 make_rpcs(struct drm_i915_private *dev_priv);

This will be gotten rid of in upcoming patches, so ok.

> if (rcs) {
> regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
> -   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
> -   make_rpcs(dev_priv));
> +   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);

While here, we could poison the value with something nasty as code flow
assumes it to be overwritten in next call.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Record the sseu configuration per-context & engine

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:22:47)
> From: Lionel Landwerlin 
> 
> We want to expose the ability to reconfigure the slices, subslice and
> eu per context and per engine. To facilitate that, store the current
> configuration on the context for each engine, which is initially set
> to the device default upon creation.
> 
> v2: record sseu configuration per context & engine (Chris)
> 
> v3: introduce the i915_gem_context_sseu to store powergating
> programming, sseu_dev_info has grown quite a bit (Lionel)
> 
> v4: rename i915_gem_sseu into intel_sseu (Chris)
> use to_intel_context() (Chris)
> 
> v5: More to_intel_context() (Tvrtko)
> Switch intel_sseu from union to struct (Tvrtko)
> Move context default sseu in existing loop (Chris)
> 
> v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
> 
> Tvrtko Ursulin:
> 
> v7:
>  * Pass intel_sseu by pointer instead of value to make_rpcs.
>  * Rebase for make_rpcs changes.
> 
> v8:
>  * Rebase for RPCS edit on pin.
> 
> v9:
>  * Rebase for context image setup changes.
> 
> v10:
>  * Rename dev_priv to i915. (Chris Wilson)
> 
> v11:
>  * Rebase.
> 
> v12:
>  * Rebase for IS_GEN changes.
> 
> v13:
>  * Rebase for RUNTIME_INFO.
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915/perf: lock powergating configuration to default when active

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:22:48)
> From: Lionel Landwerlin 
> 
> If some of the contexts submitting workloads to the GPU have been
> configured to shutdown slices/subslices, we might loose the NOA
> configurations written in the NOA muxes.
> 
> One possible solution to this problem is to reprogram the NOA muxes
> when we switch to a new context. We initially tried this in the
> workaround batchbuffer but some concerns where raised about the cost
> of reprogramming at every context switch. This solution is also not
> without consequences from the userspace point of view. Reprogramming
> of the muxes can only happen once the powergating configuration has
> changed (which happens after context switch). This means for a window
> of time during the recording, counters recorded by the OA unit might
> be invalid. This requires userspace dealing with OA reports to discard
> the invalid values.
> 
> Minimizing the reprogramming could be implemented by tracking of the
> last programmed configuration somewhere in GGTT and use MI_PREDICATE
> to discard some of the programming commands, but the command streamer
> would still have to parse all the MI_LRI instructions in the
> workaround batchbuffer.
> 
> Another solution, which this change implements, is to simply disregard
> the user requested configuration for the period of time when i915/perf
> is active. There is no known issue with this apart from a performance
> penality for some media workloads that benefit from running on a
> partially powergated GPU. We already prevent RC6 from affecting the
> programming so it doesn't sound completely unreasonable to hold on
> powergating for the same reason.

Lets squash patch 6 here and update the commit message/comments to
reflect. With that done, the resulting patch is:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915/selftests: Context SSEU reconfiguration tests

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:22:52)
> From: Tvrtko Ursulin 
> 
> Exercise the context image reconfiguration logic for idle and busy
> contexts, with the resets thrown into the mix as well.
> 
> Free from the uAPI restrictions this test runs on all Gen9+ platforms
> with slice power gating.
> 
> v2:
>  * Rename some helpers for clarity.
>  * Include subtest names in error logs.
>  * Remove unnecessary function export.
> 
> v3:
>  * Rebase for RUNTIME_INFO.
> 
> Signed-off-by: Tvrtko Ursulin 

Good for now, we could look into extending the userspace tests with some
of the reset dance, too.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/icl: Support co-existence between per-context SSEU and OA

[Joonas Lahtinen]

To be squashed to patch 3. We don't want a broken tree for bisecting.

When squashed:

Reviewed-by: Joonas Lahtinen 
 
Regards, Joonas

Quoting Tvrtko Ursulin (2019-01-08 13:22:51)
> From: Tvrtko Ursulin 
> 
> When OA is active we want to lock the powergating configuration, but on
> Icelake, users like the media stack will have issues if we lock to the
> full device configuration.
> 
> Instead lock to a subset of (sub)slices which are currently a known
> working configuration for all users.
> 
> v2:
>  * Fix commit message spelling.
> 
> v3:
>  Lionel:
>  * Add bspec reference.
>  * Fix spelling in comment.
> 
> v4:
>  * Rebase for IS_GEN changes.
> 
> Signed-off-by: Tvrtko Ursulin 
> Bspec: 21140
> Cc: Lionel Landwerlin 
> Reviewed-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 2ce55bb64fca..e9c6876a5897 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2341,13 +2341,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915, 
> struct intel_sseu *req_sseu)
>  
> /*
>  * If i915/perf is active, we want a stable powergating configuration
> -* on the system. The most natural configuration to take in that case
> -* is the default (i.e maximum the hardware can do).
> +* on the system.
> +*
> +* We could choose full enablement, but on ICL we know there are use
> +* cases which disable slices for functional, apart for performance
> +* reasons. So in this case we select a known stable subset.
>  */
> -   if (unlikely(i915->perf.oa.exclusive_stream))
> -   ctx_sseu = intel_device_default_sseu(i915);
> -   else
> +   if (!i915->perf.oa.exclusive_stream) {
> ctx_sseu = *req_sseu;
> +   } else {
> +   ctx_sseu = intel_device_default_sseu(i915);
> +
> +   if (IS_GEN(i915, 11)) {
> +   /*
> +* We only need subslice count so it doesn't matter
> +* which ones we select - just turn off low bits in 
> the
> +* amount of half of all available subslices per 
> slice.
> +*/
> +   ctx_sseu.subslice_mask =
> +   ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 
> 2));
> +   ctx_sseu.slice_mask = 0x1;
> +   }
> +   }
>  
> slices = hweight8(ctx_sseu.slice_mask);
> subslices = hweight8(ctx_sseu.subslice_mask);
> -- 
> 2.19.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)

[Joonas Lahtinen]

rule.
>  * Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
> 
> v18:
>  * Update commit message. (Joonas)
>  * Restrict uAPI to VME use case. (Joonas)
> 
> v19:
>  * Rebase.
> 
> v20:
>  * Rebase for ce->active_tracker.
> 
> v21:
>  * Rebase for IS_GEN changes.
> 
> v22:
>  * Reserve uAPI for flags straight away. (Chris Wilson)
> 
> v23:
>  * Rebase for RUNTIME_INFO.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
> Issue: https://github.com/intel/media-driver/issues/267
> Signed-off-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> Cc: Dmitry Rogozhkin 
> Cc: Tvrtko Ursulin 
> Cc: Zhipeng Gong 
> Cc: Joonas Lahtinen 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Chris Wilson  # v21



> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2377,7 +2377,9 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915, 
> struct intel_sseu *req_sseu)
>  * subslices are enabled, or a count between one and four on the first
>  * slice.
>  */
> -   if (IS_GEN(i915, 11) && slices == 1 && subslices >= 4) {
> +   if (IS_GEN(i915, 11) &&
> +   slices == 1 &&
> +   subslices > min_t(u8, 4, hweight8(sseu->subslice_mask[0]) / 2)) {

Could use it's own variable max_subslices = min_t(...).

> +++ b/include/uapi/drm/i915_drm.h
> @@ -1486,9 +1486,52 @@ struct drm_i915_gem_context_param {
>  #define   I915_CONTEXT_MAX_USER_PRIORITY   1023 /* inclusive */
>  #define   I915_CONTEXT_DEFAULT_PRIORITY0
>  #define   I915_CONTEXT_MIN_USER_PRIORITY   -1023 /* inclusive */
> +   /*
> +* When using the following param, value should be a pointer to
> +* drm_i915_gem_context_param_sseu.
> +*/
> +#define I915_CONTEXT_PARAM_SSEU0x7
> __u64 value;
>  };

Maybe we should amend some comments?

/*
 * NOTE: Can currently only be used to switch between VME enabled
 *   slice configuration vs. full on Icelake (Gen11)
 *
 * NOTE: Slice configuration requests are ignored when perf is enabled.
 */

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:24:48)
> From: Lionel Landwerlin 
> 
> Verify that the per-context dynamic SSEU uAPI works as expected.
> 
> v2: Add subslice tests (Lionel)
> Use MI_SET_PREDICATE for further verification when available (Lionel)
> 
> v3: Rename to gem_ctx_rpcs (Lionel)
> 
> v4: Update kernel API (Lionel)
> Add 0 value test (Lionel)
> Exercise invalid values (Lionel)
> 
> v5: Add perf tests (Lionel)
> 
> v6: Add new sysfs entry tests (Lionel)
> 
> v7: Test rsvd fields
> Update for kernel series changes
> 
> v8: Drop test_no_sseu_support() test (Kelvin)
> Drop drm_intel_*() apis (Chris)
> 
> v9: by Chris:
> Drop all do_ioctl/do_ioctl_err()
> Use gem_context_[gs]et_param()
> Use gem_read() instead of mapping memory
> by Lionel:
> Test dynamic sseu on/off more
> 
> Tvrtko Ursulin:
> 
> v10:
>  * Various style tweaks and refactorings.
>  * New test coverage.
> 
> v11:
>  * Change platform support to just Gen11.
>  * Simplify availability test. (Chris Wilson)
>  * More invalid pointer tests. (Chris Wilson)
> 
> v12:
>  * Fix MAP_FIXED use (doh!).
>  * Fix get/set copy&paste errors.
>  * Drop supported platform test. (Chris Wilson)
>  * Add mmap__gtt test. (Chris Wilson)
> 
> v13:
>  * Commit message tweaks.
>  * Added reset/hang/suspend tests. (Chris Wilson)
>  * Assert spinner is busy. (Chris Wilson)
>  * Remove some more ABI assumptions. (Chris Wilson)
> 
> v14:
>  * Use default resume time. (Chris Wilson)
>  * Trigger hang after rpcs read batch has been submitted. (Chris Wilson)
> 
> v15:
>  * Adjust for uAPI restrictions.
> 
> v16:
>  * Build system changes.
> 
> v17:
>  * Remove all subtests which read the RPCS register. (Joonas Lahtinen)
> 
> v18:
>  * Tidy curly braces. (Joonas Lahtinen)
> 
> v19:
>  * Check flags/rsvd MBZ.
> 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Chris Wilson  # v14
> Reviewed-by: Joonas Lahtinen  # v18

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/4] tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:24:50)
> From: Tony Ye 
> 
> On Icelake we need to turn off subslices not containing the VME block or
> the VME kernel will hang.
> 
> v2: (Tvrtko Ursulin)
>  * Remove libdrm usage for setting context param.
>  * Cleanup bitmask operation.
>  * Only apply the workaround for ICL.
> 
> v3: (Tvrtko Ursulin)
>  * Added hang detector. (Chris Wilson)
> 
> v4: (Tvrtko Ursulin)
>  * Rebase for hang detector moved to previous patch.
>  * Tidy curly braces.
> 
> Signed-off-by: Tony Ye 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Tony Ye 
> ---
>  lib/gpu_cmds.c | 12 
>  lib/gpu_cmds.h |  3 ++
>  lib/media_fill.c   |  2 +-
>  tests/i915/gem_media_vme.c | 60 ++
>  4 files changed, 76 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
> index b490a63bdfef..8d270ee86229 100644
> --- a/lib/gpu_cmds.c
> +++ b/lib/gpu_cmds.c
> @@ -36,6 +36,18 @@ gen7_render_flush(struct intel_batchbuffer *batch, 
> uint32_t batch_end)
> igt_assert(ret == 0);
>  }
>  
> +void
> +gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t 
> batch_end)
> +{
> +   int ret;
> +
> +   ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
> +   if (ret == 0)
> +   ret = drm_intel_gem_bo_context_exec(batch->bo, batch->ctx,
> +   batch_end, 0);
> +   igt_assert(ret == 0);
> +}
> +
>  uint32_t
>  gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
> uint8_t color)
> diff --git a/lib/gpu_cmds.h b/lib/gpu_cmds.h
> index ca671fb52daf..1321af446161 100644
> --- a/lib/gpu_cmds.h
> +++ b/lib/gpu_cmds.h
> @@ -40,6 +40,9 @@
>  void
>  gen7_render_flush(struct intel_batchbuffer *batch, uint32_t batch_end);
>  
> +void
> +gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t 
> batch_end);
> +
>  uint32_t
>  gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
> uint8_t color);
> diff --git a/lib/media_fill.c b/lib/media_fill.c
> index b1e84727394a..03b5e71e101b 100644
> --- a/lib/media_fill.c
> +++ b/lib/media_fill.c
> @@ -338,7 +338,7 @@ __gen11_media_vme_func(struct intel_batchbuffer *batch,
> batch_end = intel_batchbuffer_align(batch, 8);
> assert(batch_end < BATCH_STATE_SPLIT);
>  
> -   gen7_render_flush(batch, batch_end);
> +   gen7_render_context_flush(batch, batch_end);
> intel_batchbuffer_reset(batch);
>  }

Above hunks could be in the previous patch, too?

> +static void shut_non_vme_subslices(int drm_fd, uint32_t ctx)
> +{
> +   struct drm_i915_gem_context_param_sseu sseu = { };
> +   struct drm_i915_gem_context_param arg = {
> +   .param = I915_CONTEXT_PARAM_SSEU,
> +   .ctx_id = ctx,
> +   .size = sizeof(sseu),
> +   .value = to_user_pointer(&sseu),
> +   };
> +   int ret;
> +
> +   if (__gem_context_get_param(drm_fd, &arg))
> +   return; /* no sseu support */

I guess we could fail at this point already, but maybe there will be a
surprise ICL stepping to prove me wrong :)

> +
> +   ret = __gem_context_set_param(drm_fd, &arg);
> +   igt_assert(ret == 0 || ret == -ENODEV || ret == -EINVAL);
> +   if (ret)
> +   return; /* no sseu support */
> +
> +   /* shutdown half subslices*/

space before */

With the hunk moved or not.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> +   sseu.subslice_mask =
> +   switch_off_n_bits(sseu.subslice_mask,
> + __builtin_popcount(sseu.subslice_mask) / 2);
> +
> +   gem_context_set_param(drm_fd, &arg);
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2019-01-08 13:24:49)
> From: Tony Ye 
> 
> Simple test which exercises the VME fixed function block.
> 
> v2: (Tvrtko Ursulin)
>  * Small cleanups like copyright date, tabs, remove unused bits.
> 
> v3: (Tony Ye)
>  * Added curbe data entry for dst surface.
>  * Read the dst surface after the VME kernel being executed.
> 
> v4: (Tony Ye)
>  * Added the media_vme.gxa kernel source code and compile instructions.
> 
> v5: (Tvrtko Ursulin)
>  * Added hang detector.
> 
> Signed-off-by: Tony Ye 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Tony Ye 

One could further improve this by checking some effect of the shader
kernel on the output surface, just to double check that it both executed
and didn't hang as suggested by Chris

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

[Joonas Lahtinen]

+ Ken/Jason for Mesa

Quoting Matt Roper (2019-01-07 21:19:31)
> On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > > According to Workaround database ICL also needs
> > > > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > > > fine-granularity preemptions per-context.
> > > 
> > > I must wonder where is the userspace component that needs this, and why
> > > it hasn't been noticed earlier?
> > > 
> > > Or is this one more of the cases when no userspace actually uses the
> > > register?
> > 
> > It's used:
> > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
> > 
> > -Michał
> 
> Wasn't this just an artificial i915-only workaround that was added to
> prevent breakage of pre-preemption UMD's?  Initial gen9 driver releases
> didn't support preemption, so when preemption support did get added to
> i915, the kernel had to force object-level off by default at context
> creation to avoid breaking old userspace that didn't build batch buffers
> with all the necessary preemption workarounds.  This CS_CHICKEN1
> register was then exposed to userspace so that newer, preemption-aware
> userspace could opt back in if it properly supported preemption.
> 
> For gen11, there shouldn't be any "old" userspace around that doesn't
> support preemption, so shouldn't the kernel just leave object-level
> preemption enabled by default (meaning there's no need to expose this
> register to userspace to allow it to explicitly opt-in)?

Makes sense to me. We should have known by know if somebody expects to
control the register, because they would be failing to do so.

Mesa could also drop the register load for Gen11+

Regards, Joonas

> 
> Matt
> 
> > 
> > > Regards, Joonas
> > > 
> > > > 
> > > > BSpec: 11348
> > > > Cc: Oscar Mateo 
> > > > Cc: Radhakrishna Sripada 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> > > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
> > > > b/drivers/gpu/drm/i915/intel_workarounds.c
> > > > index 480c53a2ecb5..bbc5a66faa07 100644
> > > > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > > > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct 
> > > > i915_wa_list *w)
> > > > /* 
> > > > WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> > > > whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> > > >  
> > > > -   /* 
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> > > > +   /* 
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl] */
> > > > whitelist_reg(w, GEN8_CS_CHICKEN1);
> > > >  
> > > > /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */
> > > > @@ -1068,6 +1068,9 @@ static void icl_whitelist_build(struct 
> > > > i915_wa_list *w)
> > > >  
> > > > /* WaAllowUMDToModifySamplerMode:icl */
> > > > whitelist_reg(w, GEN10_SAMPLER_MODE);
> > > > +
> > > > +   /* WaEnablePreemptionGranularityControlByUMD:icl */
> > > > +   whitelist_reg(w, GEN8_CS_CHICKEN1);
> > > >  }
> > > >  
> > > >  void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > > > @@ -1186,8 +1189,8 @@ static void rcs_engine_wa_init(struct 
> > > > intel_engine_cs *engine)
> > > > GEN7_DISABLE_SAMPLER_PREFETCH);
> > > > }
> > > >  
> > > > -   if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > > > -   /* 
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > > > +   if (IS_GEN_RANGE(i915, 9, 11)) {
> > > > +   /* 
> > > > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl */
> > > > wa_masked_en(wal,
> > > >  GEN7_FF_SLICE_CS_CHICKEN1,
> &g

Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

[Joonas Lahtinen]

Quoting Sripada, Radhakrishna (2019-01-09 22:38:36)
> Looks good to me.

There is already conclusion in the other thread that this should NOT be
merged.

Regards, Joonas

> 
> > -Original Message-
> > From: Souza, Jose
> > Sent: Friday, January 4, 2019 9:37 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Oscar Mateo ; Sripada, Radhakrishna
> > ; Souza, Jose 
> > Subject: [PATCH] drm/i915/icl: Apply
> > WaEnablePreemptionGranularityControlByUMD
> > 
> > According to Workaround database ICL also needs
> > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > fine-granularity preemptions per-context.
> > 
> > BSpec: 11348
> > Cc: Oscar Mateo 
> > Cc: Radhakrishna Sripada 
> > Signed-off-by: José Roberto de Souza 
> 
> Reviewed-by: Radhakrishna Sripada 
> > ---
> >  drivers/gpu/drm/i915/intel_workarounds.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> > b/drivers/gpu/drm/i915/intel_workarounds.c
> > index 480c53a2ecb5..bbc5a66faa07 100644
> > --- a/drivers/gpu/drm/i915/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> > @@ -1014,7 +1014,7 @@ static void gen9_whitelist_build(struct i915_wa_list
> > *w)
> >   /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> >   whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
> > 
> > - /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl] */
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,[cnl,icl]
> > +*/
> >   whitelist_reg(w, GEN8_CS_CHICKEN1);
> > 
> >   /* WaAllowUMDToModifyHDCChicken1:skl,bxt,kbl,glk,cfl */ @@ -
> > 1068,6 +1068,9 @@ static void icl_whitelist_build(struct i915_wa_list *w)
> > 
> >   /* WaAllowUMDToModifySamplerMode:icl */
> >   whitelist_reg(w, GEN10_SAMPLER_MODE);
> > +
> > + /* WaEnablePreemptionGranularityControlByUMD:icl */
> > + whitelist_reg(w, GEN8_CS_CHICKEN1);
> >  }
> > 
> >  void intel_engine_init_whitelist(struct intel_engine_cs *engine) @@ -1186,8
> > +1189,8 @@ static void rcs_engine_wa_init(struct intel_engine_cs *engine)
> >   GEN7_DISABLE_SAMPLER_PREFETCH);
> >   }
> > 
> > - if (IS_GEN(i915, 9) || IS_CANNONLAKE(i915)) {
> > - /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl */
> > + if (IS_GEN_RANGE(i915, 9, 11)) {
> > + /*
> > WaEnablePreemptionGranularityControlByUMD:skl,bxt,kbl,cfl,cnl,icl
> > +*/
> >   wa_masked_en(wal,
> >GEN7_FF_SLICE_CS_CHICKEN1,
> >GEN9_FFSC_PERCTX_PREEMPT_CTRL);
> > --
> > 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver

[Joonas Lahtinen]

Hi all,

I would like to have some Acked-by's from you, the distro media
folks Cc'd here, to document your intent to start using Intel's
new media driver[1]. So if you recognize yourself (or are otherwise
interested), please read on.

TL;DR Distro folks, please give your Acked-by on patch [5/6]

I believe most are already aware of the situation that Intel
is moving to the new codebase for libva backend to support new Intel
integrated graphics devices. The existing intel-libva-driver will
be continue to be be supported for pre-Icelake platforms (https://patchwork.freedesktop.org/series/49190/

The userspace changes are reviewed and rebased here:

  https://github.com/intel/media-driver/pull/271
  https://github.com/intel/media-driver/pull/463

Best Regards, Joonas Lahtinen

Cc: dri-de...@lists.freedesktop.org
Cc: Timo Aaltonen 
Cc: Takashi Iwai 
Cc: Stephane Marchesin 
Cc: Dave Airlie 
Cc: Daniel Vetter 

PS. This series might result in some CI failures reported as it adds new uAPI
and Patchwork / CI synchronization of tests and kernel is currently WIP.

[1] https://github.com/intel/media-driver
[2] 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

Lionel Landwerlin (2):
  drm/i915: Record the sseu configuration per-context & engine
  drm/i915/perf: lock powergating configuration to default when active

Tvrtko Ursulin (4):
  drm/i915/execlists: Move RPCS setup to context pin
  drm/i915: Add timeline barrier support
  drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
  drm/i915/selftests: Context SSEU reconfiguration tests

 drivers/gpu/drm/i915/i915_drv.h   |  14 +
 drivers/gpu/drm/i915/i915_gem_context.c   | 354 -
 drivers/gpu/drm/i915/i915_gem_context.h   |  10 +
 drivers/gpu/drm/i915/i915_perf.c  |  13 +-
 drivers/gpu/drm/i915/i915_request.c   |  13 +
 drivers/gpu/drm/i915/i915_request.h   |  10 +
 drivers/gpu/drm/i915/i915_timeline.c  |   3 +
 drivers/gpu/drm/i915/i915_timeline.h  |  27 +
 drivers/gpu/drm/i915/intel_lrc.c  | 100 ++--
 drivers/gpu/drm/i915/intel_lrc.h  |   2 +
 .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++
 .../gpu/drm/i915/selftests/mock_timeline.c|   2 +
 include/uapi/drm/i915_drm.h   |  64 +++
 13 files changed, 1056 insertions(+), 37 deletions(-)

-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915: Add timeline barrier support

[Joonas Lahtinen]

From: Tvrtko Ursulin 

Timeline barrier allows serialization between different timelines.

After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.

This facility will be used by the upcoming context SSEU code.

v2:
 * Assert barrier has been retired on timeline_fini. (Chris Wilson)
 * Fix mock_timeline.

v3:
 * Improved comment language. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c   | 13 +
 drivers/gpu/drm/i915/i915_timeline.c  |  3 +++
 drivers/gpu/drm/i915/i915_timeline.h  | 27 +++
 .../gpu/drm/i915/selftests/mock_timeline.c|  2 ++
 4 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index d1355154886a..496217305a00 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -509,6 +509,15 @@ i915_request_alloc_slow(struct intel_context *ce)
return kmem_cache_alloc(ce->gem_context->i915->requests, GFP_KERNEL);
 }
 
+static int add_timeline_barrier(struct i915_request *rq)
+{
+   struct i915_request *barrier =
+   i915_gem_active_raw(&rq->timeline->barrier,
+   &rq->i915->drm.struct_mutex);
+
+   return barrier ? i915_request_await_dma_fence(rq, &barrier->fence) : 0;
+}
+
 /**
  * i915_request_alloc - allocate a request structure
  *
@@ -652,6 +661,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
 */
rq->head = rq->ring->emit;
 
+   ret = add_timeline_barrier(rq);
+   if (ret)
+   goto err_unwind;
+
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c 
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(&timeline->requests);
 
i915_syncmap_init(&timeline->sync);
+
+   init_request_active(&timeline->barrier, NULL);
 }
 
 /**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
 void i915_timeline_fini(struct i915_timeline *timeline)
 {
GEM_BUG_ON(!list_empty(&timeline->requests));
+   GEM_BUG_ON(i915_gem_active_isset(&timeline->barrier));
 
i915_syncmap_free(&timeline->sync);
 
diff --git a/drivers/gpu/drm/i915/i915_timeline.h 
b/drivers/gpu/drm/i915/i915_timeline.h
index 38c1e15e927a..af6c05333d76 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -64,6 +64,16 @@ struct i915_timeline {
 */
struct i915_syncmap *sync;
 
+   /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions to this timeline be executed only after the
+* barrier has been completed.
+*/
+   struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
 
@@ -136,4 +146,21 @@ static inline bool i915_timeline_sync_is_later(struct 
i915_timeline *tl,
 
 void i915_timelines_park(struct drm_i915_private *i915);
 
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+   GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+   i915_gem_active_set(&timeline->barrier, rq);
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c 
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64 
context)
 
i915_syncmap_init(&timeline->sync);
 
+   init_request_active(&timeline->barrier, NULL);
+
INIT_LIST_HEAD(&timeline->link);
 }
 
-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)

[Joonas Lahtinen]

thub.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Cc: Dmitry Rogozhkin 
Cc: Tvrtko Ursulin 
Cc: Zhipeng Gong 
Cc: Joonas Lahtinen 
Cc: Tony Ye 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson  # v21
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 341 +++-
 drivers/gpu/drm/i915/i915_gem_context.h |   6 +
 drivers/gpu/drm/i915/intel_lrc.c|   4 +-
 include/uapi/drm/i915_drm.h |  64 +
 4 files changed, 412 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a182045e3808..f65d3e9089b6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -89,6 +89,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_trace.h"
+#include "intel_lrc_reg.h"
 #include "intel_workarounds.h"
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -321,6 +322,15 @@ static u32 default_desc_template(const struct 
drm_i915_private *i915,
return desc;
 }
 
+static void intel_context_retire(struct i915_gem_active *active,
+struct i915_request *rq)
+{
+   struct intel_context *ce =
+   container_of(active, typeof(*ce), active_tracker);
+
+   intel_context_unpin(ce);
+}
+
 static struct i915_gem_context *
 __create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
@@ -344,6 +354,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ce->gem_context = ctx;
/* Use the whole device by default */
ce->sseu = intel_device_default_sseu(dev_priv);
+
+   init_request_active(&ce->active_tracker, intel_context_retire);
}
 
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
@@ -841,6 +853,56 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
return 0;
 }
 
+static int get_sseu(struct i915_gem_context *ctx,
+   struct drm_i915_gem_context_param *args)
+{
+   struct drm_i915_gem_context_param_sseu user_sseu;
+   struct intel_engine_cs *engine;
+   struct intel_context *ce;
+   int ret;
+
+   if (args->size == 0)
+   goto out;
+   else if (args->size < sizeof(user_sseu))
+   return -EINVAL;
+
+   if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
+  sizeof(user_sseu)))
+   return -EFAULT;
+
+   if (user_sseu.flags || user_sseu.rsvd)
+   return -EINVAL;
+
+   engine = intel_engine_lookup_user(ctx->i915,
+ user_sseu.engine_class,
+ user_sseu.engine_instance);
+   if (!engine)
+   return -EINVAL;
+
+   /* Only use for mutex here is to serialize get_param and set_param. */
+   ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
+   if (ret)
+   return ret;
+
+   ce = to_intel_context(ctx, engine);
+
+   user_sseu.slice_mask = ce->sseu.slice_mask;
+   user_sseu.subslice_mask = ce->sseu.subslice_mask;
+   user_sseu.min_eus_per_subslice = ce->sseu.min_eus_per_subslice;
+   user_sseu.max_eus_per_subslice = ce->sseu.max_eus_per_subslice;
+
+   mutex_unlock(&ctx->i915->drm.struct_mutex);
+
+   if (copy_to_user(u64_to_user_ptr(args->value), &user_sseu,
+sizeof(user_sseu)))
+   return -EFAULT;
+
+out:
+   args->size = sizeof(user_sseu);
+
+   return 0;
+}
+
 int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
 {
@@ -853,15 +915,17 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
if (!ctx)
return -ENOENT;
 
-   args->size = 0;
switch (args->param) {
case I915_CONTEXT_PARAM_BAN_PERIOD:
ret = -EINVAL;
break;
case I915_CONTEXT_PARAM_NO_ZEROMAP:
+   args->size = 0;
args->value = test_bit(UCONTEXT_NO_ZEROMAP, &ctx->user_flags);
break;
case I915_CONTEXT_PARAM_GTT_SIZE:
+   args->size = 0;
+
if (ctx->ppgtt)
args->value = ctx->ppgtt->vm.total;
else if (to_i915(dev)->mm.aliasing_ppgtt)
@@ -870,14 +934,20 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
args->value = to_i915(dev)->ggtt.vm.total;
break;
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
+   args->size = 0;
args->value 

[Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin

[Joonas Lahtinen]

From: Tvrtko Ursulin 

Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.

v2:
 * Split image setup a bit differently. (Chris Wilson)

v3:
 * Update context image after reset as well - otherwise the application
   of pinned default state clears the RPCS.

v4:
 * Use local variable throughout the function. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 45 
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 608458b92db3..24328745a0ea 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,6 +1169,24 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
+
+static void
+__execlists_update_reg_state(struct intel_engine_cs *engine,
+struct intel_context *ce)
+{
+   u32 *regs = ce->lrc_reg_state;
+   struct intel_ring *ring = ce->ring;
+
+   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(ring->vma);
+   regs[CTX_RING_HEAD + 1] = ring->head;
+   regs[CTX_RING_TAIL + 1] = ring->tail;
+
+   /* RPCS */
+   if (engine->class == RENDER_CLASS)
+   regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915);
+}
+
 static struct intel_context *
 __execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
@@ -1207,10 +1225,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
 
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
-   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
-   i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
-   ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
+
+   __execlists_update_reg_state(engine, ce);
 
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -1834,14 +1850,14 @@ static void execlists_reset(struct intel_engine_cs 
*engine,
   engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
   engine->context_size - PAGE_SIZE);
}
-   execlists_init_reg_state(regs,
-request->gem_context, engine, request->ring);
 
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
-   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
-
request->ring->head = intel_ring_wrap(request->ring, request->postfix);
-   regs[CTX_RING_HEAD + 1] = request->ring->head;
+
+   execlists_init_reg_state(regs, request->gem_context, engine,
+request->ring);
+
+   __execlists_update_reg_state(engine, request->hw_context);
 
intel_ring_update_space(request->ring);
 
@@ -2530,8 +2546,7 @@ static void execlists_init_reg_state(u32 *regs,
 
if (rcs) {
regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
-   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
-   make_rpcs(dev_priv));
+   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);
 
i915_oa_init_reg_state(engine, ctx, regs);
}
@@ -2692,12 +2707,8 @@ void intel_lr_context_resume(struct drm_i915_private 
*i915)
 
intel_ring_reset(ce->ring, 0);
 
-   if (ce->pin_count) { /* otherwise done in context_pin */
-   u32 *regs = ce->lrc_reg_state;
-
-   regs[CTX_RING_HEAD + 1] = ce->ring->head;
-   regs[CTX_RING_TAIL + 1] = ce->ring->tail;
-   }
+   if (ce->pin_count) /* otherwise done in context_pin */
+   __execlists_update_reg_state(engine, ce);
}
}
 }
-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active

[Joonas Lahtinen]

From: Lionel Landwerlin 

If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.

One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.

Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.

Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active.

On most platforms there are no issues with this apart from a performance
penality for some media workloads that benefit from running on a partially
powergated GPU. We already prevent RC6 from affecting the programming so
it doesn't sound completely unreasonable to hold on powergating for the
same reason.

On Icelake however there would a functional problem if the slices not-
containing the VME block were left enabled with a running media workload
which explicitly disabled them. To avoid a GPU hang in this case, on
Icelake we lock the enablement to only slices which contain VME blocks.
Downside is that it means degraded GPU performance when OA is active but
there is no known alternative solution for this.

v2: Leave RPCS programming in intel_lrc.c (Lionel)

v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)

Tvrtko Ursulin:

v4:
 * Rebase for make_rpcs changes.

v5:
 * Apply OA restriction from make_rpcs directly.

v6:
 * Rebase for context image setup changes.

v7:
 * Move stream assignment before metric enable.

v8-9:
 * Rebase.

v10:
 * Squashed with ICL support patch.

Bspec: 21140
Co-Developed-by: Tvrtko Ursulin 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Tvrtko Ursulin 
Cc: Lionel Landwerlin 
Reviewed-by: Chris Wilson  # v9
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_perf.c | 13 ++---
 drivers/gpu/drm/i915/intel_lrc.c | 46 
 drivers/gpu/drm/i915/intel_lrc.h |  2 ++
 3 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index faff6cf1aaa1..07170e49ecb3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct 
i915_gem_context *ctx,
 
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+   CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+   gen8_make_rpcs(dev_priv,
+  &to_intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
 }
 
 /*
@@ -2098,21 +2103,21 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret)
goto err_lock;
 
+   stream->ops = &i915_oa_stream_ops;
+   dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(stream);
if (ret) {
DRM_DEBUG("Unable to enable metric set\n");
goto err_enable;
}
 
-   stream->ops = &i915_oa_stream_ops;
-
-   dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(&dev_priv->drm.struct_mutex);
 
return 0;
 
 err_enable:
+   dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 31bf84b22e61..f32be56ec503 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,9 +1169,6 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
 static void
 __execlists_update_reg_state(struct intel_engine_cs *engine,
 struct intel_context *ce)
@@ -1185,8 +1182,8 @@ __execlists_update_reg_state(struct intel_engine_cs 
*en

[Intel-gfx] [PATCH 6/6] drm/i915/selftests: Context SSEU reconfiguration tests

[Joonas Lahtinen]

From: Tvrtko Ursulin 

Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.

Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.

v2:
 * Rename some helpers for clarity.
 * Include subtest names in error logs.
 * Remove unnecessary function export.

v3:
 * Rebase for RUNTIME_INFO.

v4:
 * Fix incomplete unexport from v2. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c   |  31 +-
 .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++
 2 files changed, 502 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f65d3e9089b6..0444cfa96cf5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1042,23 +1042,19 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
 }
 
 static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+   struct intel_engine_cs *engine,
+   struct intel_sseu sseu)
 {
struct intel_context *ce = to_intel_context(ctx, engine);
-   int ret;
+   int ret = 0;
 
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
GEM_BUG_ON(engine->id != RCS);
 
-   ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
-   if (ret)
-   return ret;
-
/* Nothing to do if unmodified. */
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
-   goto out;
+   return 0;
 
/*
 * If context is not idle we have to submit an ordered request to modify
@@ -1071,7 +1067,22 @@ i915_gem_context_reconfigure_sseu(struct 
i915_gem_context *ctx,
if (!ret)
ce->sseu = sseu;
 
-out:
+   return ret;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+   int ret;
+
+   ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
+   if (ret)
+   return ret;
+
+   ret = __i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
+
mutex_unlock(&ctx->i915->drm.struct_mutex);
 
return ret;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 4cba50679607..91ceacd81de6 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -27,6 +27,8 @@
 #include "../i915_selftest.h"
 #include "i915_random.h"
 #include "igt_flush_test.h"
+#include "igt_reset.h"
+#include "igt_spinner.h"
 
 #include "mock_drm.h"
 #include "mock_gem_device.h"
@@ -653,6 +655,484 @@ static int igt_ctx_exec(void *arg)
return err;
 }
 
+static struct i915_vma *rpcs_query_batch(struct i915_vma *vma)
+{
+   struct drm_i915_gem_object *obj;
+   u32 *cmd;
+   int err;
+
+   if (INTEL_GEN(vma->vm->i915) < 8)
+   return ERR_PTR(-EINVAL);
+
+   obj = i915_gem_object_create_internal(vma->vm->i915, PAGE_SIZE);
+   if (IS_ERR(obj))
+   return ERR_CAST(obj);
+
+   cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+   if (IS_ERR(cmd)) {
+   err = PTR_ERR(cmd);
+   goto err;
+   }
+
+   *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
+   *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE);
+   *cmd++ = lower_32_bits(vma->node.start);
+   *cmd++ = upper_32_bits(vma->node.start);
+   *cmd = MI_BATCH_BUFFER_END;
+
+   i915_gem_object_unpin_map(obj);
+
+   err = i915_gem_object_set_to_gtt_domain(obj, false);
+   if (err)
+   goto err;
+
+   vma = i915_vma_instance(obj, vma->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_USER);
+   if (err)
+   goto err;
+
+   return vma;
+
+err:
+   i915_gem_object_put(obj);
+   return ERR_PTR(err);
+}
+
+static int
+emit_rpcs_query(struct drm_i915_gem_object *obj,
+   struct i915_gem_context *ctx,
+   struct intel_engine_cs *engine,
+   struct i915_request **rq_out)
+{
+   struct i915_address_space *vm;
+   struct i915_request *rq;
+   struct i915_vma *batch;
+   struct i915_vma *vma;
+   int err;
+
+   GEM_BUG_ON(!ctx-

[Intel-gfx] [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine

[Joonas Lahtinen]

From: Lionel Landwerlin 

We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.

v2: record sseu configuration per context & engine (Chris)

v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)

v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)

v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)

v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)

Tvrtko Ursulin:

v7:
 * Pass intel_sseu by pointer instead of value to make_rpcs.
 * Rebase for make_rpcs changes.

v8:
 * Rebase for RPCS edit on pin.

v9:
 * Rebase for context image setup changes.

v10:
 * Rename dev_priv to i915. (Chris Wilson)

v11:
 * Rebase.

v12:
 * Rebase for IS_GEN changes.

v13:
 * Rebase for RUNTIME_INFO.

Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 14 +++
 drivers/gpu/drm/i915/i915_gem_context.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_context.h |  4 
 drivers/gpu/drm/i915/i915_request.h | 10 
 drivers/gpu/drm/i915/intel_lrc.c| 31 +
 5 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 956c1c86f90d..d9120b70d9b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3331,6 +3331,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)INTEL_INFO(dev_priv);
 }
 
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+   const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
+   struct intel_sseu value = {
+   .slice_mask = sseu->slice_mask,
+   .subslice_mask = sseu->subslice_mask[0],
+   .min_eus_per_subslice = sseu->max_eus_per_subslice,
+   .max_eus_per_subslice = sseu->max_eus_per_subslice,
+   };
+
+   return value;
+}
+
 /* modesetting */
 extern void intel_modeset_init_hw(struct drm_device *dev);
 extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5933adbe3d99..a182045e3808 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -342,6 +342,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = &ctx->__engine[n];
 
ce->gem_context = ctx;
+   /* Use the whole device by default */
+   ce->sseu = intel_device_default_sseu(dev_priv);
}
 
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..ef04e422cf9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
 
 #include "i915_gem.h"
 #include "i915_scheduler.h"
+#include "intel_device_info.h"
 
 struct pid;
 
@@ -171,6 +172,9 @@ struct i915_gem_context {
int pin_count;
 
const struct intel_context_ops *ops;
+
+   /** sseu: Control eu/slice partitioning */
+   struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
 
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index d014b0605445..907bd8f11aeb 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -38,6 +38,16 @@ struct drm_i915_gem_object;
 struct i915_request;
 struct i915_timeline;
 
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+   u8 slice_mask;
+   u8 subslice_mask;
+   u8 min_eus_per_subslice;
+   u8 max_eus_per_subslice;
+};
+
 struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 24328745a0ea..31bf84b22e61 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1169,7 +1169,8 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_s

Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

[Joonas Lahtinen]

Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
> 
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it from hanging the box, but otherwise left it
> > enabled. So if we make a policy change to also disable it anywhere
> > where it doesn't work well (instead of not at all), there's a pile
> > more platforms to switch.
> 
> I think its best to just disable iommu for the igfx devices on these
> platforms. Can you pick up Eric's patch and extend it with the list of
> affected platforms?

We've been discussing this again more actively since a few months ago,
and the discussion is still ongoing internally.

According to our IOMMU folks there exists some desire to be able to assign
the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
due to how the devices might be grouped in IOMMU groups. Even when you
would not be using the iGFX device.

So for some uses, the fact that the device (group) is assignable seems
to be more important than the iGFX device to be working. I'm afraid
that retroactively disabling the assignment for such an old platform
might break those usage scenarios. By my quick reading of the code,
there's no way for user to turn the iGFX DMAR on once the quirk
disables it.

I guess one solution would be to default to intel_iommu=igfx_off for
platforms that are older than certain threshold. But still allow
user to enable. But that then requires duplicating the PCI ID database
into iommu code.

I don't really have winning moves to present, but I'm open to hearing
how we can avoid more damage than starting to default to intel_iommu=on
did already.

Regards, Joonas

> 
> Thanks,
> 
> Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> With the currently available parameters for the i915-perf stream,
> there are still situations that are not well covered :
> 
> If an application opens the stream with polling disable or at very low
> frequency and OA interrupt enabled, no data will be available even
> though somewhere between nothing and half of the OA buffer worth of
> data might have landed in memory.
> 
> To solve this issue we have a new flush ioctl on the perf stream that
> forces the i915-perf driver to look at the state of the buffer when
> called and makes any data available through both poll() & read() type
> syscalls.
> 
> Signed-off-by: Lionel Landwerlin 

Link to userspace changes?

Regards, Joonas

> ---
>  drivers/gpu/drm/i915/i915_perf.c | 17 +
>  include/uapi/drm/i915_drm.h  | 19 +++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index da721fce2543..6c98ffa2135e 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct 
> i915_perf_stream *stream)
> stream->ops->disable(stream);
>  }
>  
> +/**
> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
> + * @stream: An enabled i915 perf stream
> + *
> + * The intention is to flush all the data available for reading from the OA
> + * buffer
> + */
> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
> +{
> +   struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> +   dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
> +}
> +
>  /**
>   * i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
>   * @stream: An i915 perf stream
> @@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct 
> i915_perf_stream *stream,
> case I915_PERF_IOCTL_DISABLE:
> i915_perf_disable_locked(stream);
> return 0;
> +   case I915_PERF_IOCTL_FLUSH_DATA:
> +   i915_perf_flush_data(stream);
> +   return 0;
> }
>  
> return -EINVAL;
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index b6db5e544a35..0f0d20080572 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
>   */
>  #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
>  
> +/**
> + * Actively check the availability of data from a stream.
> + *
> + * A stream data availability can be driven by two types of events :
> + *
> + *   - if enabled, the kernel's hrtimer checking the amount of available data
> + * in the OA buffer through head/tail registers.
> + *
> + *   - if enabled, the OA unit's interrupt mechanism
> + *
> + * The kernel hrtimer incur a cost of running callback at fixed time
> + * intervals, while the OA interrupt might only happen rarely. In the
> + * situation where the application has disabled the kernel's hrtimer and only
> + * uses the OA interrupt to know about available data, the application can
> + * request an active check of the available OA data through this ioctl. This
> + * will make any data in the OA buffer available with either poll() or 
> read().
> + */
> +#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
> +
>  /**
>   * Common to all i915 perf records
>   */
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something

[Joonas Lahtinen]

The subject of this patch could really be bit more specific "... on DDI clock
selection".

Regards, Joonas

Quoting Lucas De Marchi (2019-01-17 22:21:10)
> Even if we don't have the correct clock and get a warning, we should not
> skip the return.
> 
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
> Cc: Paulo Zanoni 
> Cc:  # v4.19+
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8dbf6c9e22fb..4dc03e8c6c10 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1021,7 +1021,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct 
> intel_encoder *encoder,
> return DDI_CLK_SEL_TBT_810;
> default:
> MISSING_CASE(clock);
> -   break;
> +   return DDI_CLK_SEL_NONE;
> }
> case DPLL_ID_ICL_MGPLL1:
> case DPLL_ID_ICL_MGPLL2:
> -- 
> 2.20.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/draw: Align mmap requests to page boundaries

[Joonas Lahtinen]

Quoting Chris Wilson (2019-01-07 12:56:36)
> Since we trust fb->size as either calculated by calc_fb_size() or the
> supplied by the user, it invariably isn't page aligned. The mmap
> routines and ioctls only deal in pages...
> 
> Not sure if fb->size should be page aligned, but that may break
> some other drawing tests, so opt to just fix up the mmap requests.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

[Joonas Lahtinen]

Quoting Joerg Roedel (2019-01-22 18:51:35)
> On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> > According to our IOMMU folks there exists some desire to be able to assign
> > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> > due to how the devices might be grouped in IOMMU groups. Even when you
> > would not be using the iGFX device.
> 
> You can force the igfx device into a SI domain, or does that also
> trigger the iommu issues on the chipset?

To be honest, we've had a mixture different issues on different SKUs
that have not been hit in the past when intel_iommu was just disabled by
default.

I know that in one group of the problems, the issue has been debugged
into the GPU having its own set of virtualization mapping translation
hardware with caching and it fails to track changes to the mapping. So
if a identity mapping was established and never changed, I'd assume that
to fix at least that class of problems.

Would just passing intel_iommu=on already cause a non-identity mapping to
possibly be used for the integrated GPU? If it did, then it would
explain quite few of the issues.

We have many reports where just having intel_iommu=on (and using the
system normally, without any virtualization stuff going on) will cause
unexplained GPU hangs. For those users, simply switching to
intel_iommu=igfx_off solves the problems, and the debug often ends
there.

Regards, Joonas

> In any case, if iommu=on breaks these systems I want to make them work
> again with opt-out, even at the cost of breaking assignability.
> 
> Regards,
> 
> Joerg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: De-inline intel_context_init()

[Joonas Lahtinen]

Quoting Chris Wilson (2019-01-24 10:37:10)
> Nip some inline spaghetti in the bud before the problem gets too bad.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 7/7] drm/i915/icl: Define MOCS table for Icelake

[Joonas Lahtinen]

Quoting Lucas De Marchi (2019-01-24 02:06:04)
> From: Tomasz Lis 
> 
> The table has been unified across OSes to minimize virtualization overhead.
> 
> The MOCS table is now published as part of bspec, and versioned. Entries
> are supposed to never be modified, but new ones can be added. Adding
> entries increases table version. The patch includes version 1 entries.
> 
> Meaning of each entry is now explained in bspec, and user mode clients
> are expected to know what each entry means. The 3 entries used for previous
> platforms are still compatible with their legacy definitions, but that is
> not guaranteed to be true for future platforms.
> 
> v2: Fixed SCC values, improved commit comment (Daniele)
> v3: Improved MOCS table comment (Daniele)
> v4: Moved new entries below gen9 ones. Put common entries into
> definition to be used in multiple arrays. (Lucas)
> v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
> to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
> v6: Removed definitions of reserved entries. (Michal)
> Increased limit of entries sent to the hardware on gen11+.
> v7: Simplify table as done for previou gens (Lucas)
> v8: Rebase on cached number of entries per-platform and use new
> MOCS_ENTRY() macro (Lucas)
> v9: Update comment (from Tomasz)
> 
> BSpec: 34007
> BSpec: 560
> 
> Signed-off-by: Tomasz Lis 
> Reviewed-by: Daniele Ceraolo Spurio 
> Reviewed-by: Lucas De Marchi 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Tomasz Lis 

I don't think we should have A-b/R-b from patch authors.

If you add you S-o-b to the code, you can remove the R-b, and if you
wrote portion of the code, you don't really add Reviewed-by or Acked-by.

Similarly, if the code is modified after some R-bs are given, you should
indicate those reviews to be stale.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/33] drm/i915/selftests: Apply a subtest filter

[Joonas Lahtinen]

Quoting Chris Wilson (2019-01-25 04:29:39)
> In bringup on simulated HW even rudimentary tests are slow, and so many
> may fail that we want to be able to filter out the noise to focus on the
> specific problem. Even just the tests groups provided for igt is not
> specific enough, and we would like to isolate one particular subtest
> (and probably subsubtests!). For simplicity, allow the user to provide a
> command line parameter such as
> 
> i915.st_filter=i915_timeline_mock_selftests/igt_sync
> 
> to restrict ourselves to only running on subtest. The exact name to use
> is given during a normal run, highlighted as an error if it failed,
> debug otherwise. The test group is optional, and then all subtests are
> compared for an exact match with the filter (most subtests have unique
> names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
> then all tests but those that match will be run. More than one match can
> be supplied separated by a comma, e.g.
> 
> i915.st_filter=igt_vma_create,igt_vma_pin1
> 
> to only run those specified, or
> 
> i915.st_filter=!igt_vma_create,!igt_vma_pin1
> 
> to run all but those named. Mixing a blacklist and whitelist will only
> execute those subtests matching the whitelist so long as they are
> previously excluded in the blacklist.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

I don't think we have time budger pressure for O(1) solution, so
this is:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Enable fastboot by default on Skylake and newer

[Joonas Lahtinen]

Quoting Hans de Goede (2019-01-25 10:36:48)
> Hi Rodrigo and Maarten,
> 
> On 24-01-19 23:20, Rodrigo Vivi wrote:
> > On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
> >> From: Hans de Goede 
> >>
> >> We really want to have fastboot enabled by default to avoid an ugly
> >> modeset during boot.
> >>
> >> Rather then enabling it everywhere, lets start with enabling it on
> >> Skylake and newer.
> >>
> >> Signed-off-by: Hans de Goede 
> >> Signed-off-by: Maarten Lankhorst 
> > 
> > 
> > I believe at this point you both addressed all of my concerns.
> > And CI is happy. Let's give a try ;)
> 
> Great, thank you.
> 
> On IRC Maarten asked me about if we should also enable this for
> VLV/CHV. As you may know, as a spare time/weekend project, I've been
> working on making Linux support Bay and Cherry Trail based hardware,
> better. As such I've about 40 different devices with these SoCs and
> I've tested fastboot=1 on all of them. fastboot=1 not only works on
> all of them, on 2 devices the display goes black when we have
> fastboot=0 for some reason which I've been unable to figure out.
> These 2 devices do survive a full-modeset just fine after the initial
> one ?

You're not talking about PIPO X8(s) by any chance? I also happen to own
those devices for side projects.

The verdict is that some revisions of them are missing the VBT sequences
to actually bring up the display. So if you try to change the display
mode after boot from Linux, the display won't ever come back up, as the
GPIO sequences to bring them up do not exist.

Those information blocks are simply empty or missing, and the sequences
have been hacked into the GOP driver and the Android/Windows display
drivers. It also involved programming a mux configuration in addition to
bringing up the display.

I even found some Android source dumps for the platform, but as I'm not
that much of a display side guy and it was not a straightforward matter
I gave up and got my devices exchanged for ones that include the VBT :P

Porting the code (they had basically re-used big portions of the GMA
drivers) seemed like a doable although big task.

Regards, Joonas

PS. I'm huge fan of this non-flicker boot effort! I contributed the
original splashscreen patches for gummiboot (now systemd-boot) for a
project. Hopefully we soon have a completely smooth graphical
boot process :)

> So my response to Maarten was, yes we should enable fastboot=1 by
> default on VLV/CHV too and I plan to submit a follow-up patch for
> that once we have agreement on this patch.
> 
> Maarten suggested to just go for enabling it on gen7+ instead of
> the current gen9+.
> 
> I personally tend towards merging this patch with your
> Reviewed-by + doing a follow-up patch for just VLV/CHV, but
> Maarten prefers doing the gen7+ solution, what is your take on this?
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> > 
> > 
> > Reviewed-by: Rodrigo Vivi 
> > 
> > 
> > 
> >> ---
> >>   drivers/gpu/drm/i915/i915_params.c   |  6 --
> >>   drivers/gpu/drm/i915/i915_params.h   |  2 +-
> >>   drivers/gpu/drm/i915/intel_display.c | 11 ++-
> >>   3 files changed, 15 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> >> b/drivers/gpu/drm/i915/i915_params.c
> >> index 9f0539bdaa39..b5be0abbba35 100644
> >> --- a/drivers/gpu/drm/i915/i915_params.c
> >> +++ b/drivers/gpu/drm/i915/i915_params.c
> >> @@ -97,8 +97,10 @@ i915_param_named_unsafe(disable_power_well, int, 0400,
> >>
> >>   i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: 
> >> true)");
> >>
> >> -i915_param_named(fastboot, bool, 0600,
> >> -"Try to skip unnecessary mode sets at boot time (default: false)");
> >> +i915_param_named(fastboot, int, 0600,
> >> +"Try to skip unnecessary mode sets at boot time "
> >> +"(0=disabled, 1=enabled) "
> >> +"Default: -1 (use per-chip default)");
> >>
> >>   i915_param_named_unsafe(prefault_disable, bool, 0600,
> >>  "Disable page prefaulting for pread/pwrite/reloc (default:false). "
> >> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> >> b/drivers/gpu/drm/i915/i915_params.h
> >> index 6efcf330bdab..3f14e9881a0d 100644
> >> --- a/drivers/gpu/drm/i915/i915_params.h
> >> +++ b/drivers/gpu/drm/i915/i915_params.h
> >> @@ -63,10 +63,10 @@ struct drm_printer;
> >>  param(int, edp_vswing, 0) \
> >>  param(int, reset, 2) \
> >>  param(unsigned int, inject_load_failure, 0) \
> >> +param(int, fastboot, -1) \
> >>  /* leave bools at the end to not create holes */ \
> >>  param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) 
> >> \
> >>  param(bool, enable_hangcheck, true) \
> >> -param(bool, fastboot, false) \
> >>  param(bool, prefault_disable, false) \
> >>  param(bool, load_detect_test, false) \
> >>  param(bool, force_reset_modeset_test, false) \
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 36c1126

[Intel-gfx] [PATCH v2 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set

[Joonas Lahtinen]

Make sure the underlying VMA in the process address space is the
same as it was during vm_mmap to avoid applying WC to wrong VMA.

A more long-term solution would be to have vm_mmap_locked variant
in linux/mmap.h for when caller wants to hold mmap_sem for an
extended duration.

v2:
- Refactor the compare function

Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings 
for objects")
Reported-by: Adam Zabrocki 
Suggested-by: Linus Torvalds 
Signed-off-by: Joonas Lahtinen 
Cc:  # v4.0+
Cc: Akash Goel 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Adam Zabrocki 
Reviewed-by: Chris Wilson  #v1
Reviewed-by: Tvrtko Ursulin  #v1
---
 drivers/gpu/drm/i915/i915_gem.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05627000b77d..7ca78c06b22c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
return 0;
 }
 
+static inline bool
+__vma_matches(struct vm_area_struct *vma, struct file *filp,
+ unsigned long addr, unsigned long size)
+{
+   if (vma->vm_file != filp)
+   return false;
+
+   return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
+}
+
 /**
  * i915_gem_mmap_ioctl - Maps the contents of an object, returning the address
  *  it is mapped to.
@@ -1739,7 +1749,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
return -EINTR;
}
vma = find_vma(mm, addr);
-   if (vma)
+   if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
vma->vm_page_prot =

pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
else
-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/2] drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set

[Joonas Lahtinen]

Add err goto label and use it when VMA can't be established or changes
underneath.

v2:
- Dropping Fixes: as it's indeed impossible to race an object to the
  error address. (Chris)

Reported-by: Adam Zabrocki 
Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Adam Zabrocki 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ca78c06b22c..f2933a8a506d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1740,6 +1740,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
addr = vm_mmap(obj->base.filp, 0, args->size,
   PROT_READ | PROT_WRITE, MAP_SHARED,
   args->offset);
+   if (IS_ERR((void *)addr))
+   goto err;
+
if (args->flags & I915_MMAP_WC) {
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
@@ -1755,17 +1758,22 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
else
addr = -ENOMEM;
up_write(&mm->mmap_sem);
+   if (IS_ERR((void *)addr))
+   goto err;
 
/* This may race, but that's ok, it only gets set */
WRITE_ONCE(obj->frontbuffer_ggtt_origin, ORIGIN_CPU);
}
i915_gem_object_put(obj);
-   if (IS_ERR((void *)addr))
-   return addr;
 
args->addr_ptr = (u64)addr;
 
return 0;
+
+err:
+   i915_gem_object_put(obj);
+
+   return addr;
 }
 
 static unsigned int tile_row_pages(const struct drm_i915_gem_object *obj)
-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] i915/selftest: Allow filtering of individual subtests

[Joonas Lahtinen]

Quoting Chris Wilson (2019-01-30 01:44:58)
> Take an environment variable, SELFTESTS=foo,bar, and pass that along to
> the kernel (as i915.st_filter=foo,bar) to provide fine grained test
> selection. This can be either as an exact match to select only that
> test, or to exclude only test. For example,
> 
> SELFTESTS=igt_vma_create,igt_vma_pin1 i915_selftest --run mock_vma
> SELFTESTS=!igt_vma_create i915_selftest --run mock_vma
> 
> v2: Replace NULL with the empty string.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v31 4/5] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)

[Joonas Lahtinen]

 error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
> 
> v18:
>  * Update commit message. (Joonas)
>  * Restrict uAPI to VME use case. (Joonas)
> 
> v19:
>  * Rebase.
> 
> v20:
>  * Rebase for ce->active_tracker.
> 
> v21:
>  * Rebase for IS_GEN changes.
> 
> v22:
>  * Reserve uAPI for flags straight away. (Chris Wilson)
> 
> v23:
>  * Rebase for RUNTIME_INFO.
> 
> v24:
>  * Added some headline docs for the uapi usage. (Joonas/Chris)
> 
> v25:
>  * Renamed class/instance to engine_class/engine_instance to avoid clash
>with C++ keyword. (Tony Ye)
> 
> v26:
>  * Rebased for runtime pm api changes.
> 
> v27:
>  * Rebased for intel_context_init.
>  * Wrap commit msg to 75.
> 
> v28:
>  (Chris Wilson)
>  * Use i915_gem_ggtt.
>  * Use i915_request_await_dma_fence to show a better example.
> 
> v29:
>  * i915_timeline_set_barrier can now fail. (Chris Wilson)
> 
> v30:
>  * Capture some acks.
> 
> v31:
>  * Drop the WARN_ON from use controllable paths. (Chris Wilson)
>  * Use overflows_type for all checks.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
> Issue: https://github.com/intel/media-driver/issues/267
> Signed-off-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> Cc: Dmitry Rogozhkin 
> Cc: Tvrtko Ursulin 
> Cc: Zhipeng Gong 
> Cc: Joonas Lahtinen 
> Cc: Tony Ye 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Chris Wilson  # v21
> Reviewed-by: Joonas Lahtinen  # v27

You could mention the locking characteristics of active_tracker in the
comment. We should start such a habit.

Anyway, this is:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: whitelist needed predicate registers for Anv

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2019-01-11 19:53:36)
> There is no reason not to whitelist those registers. In particular
> MI_PREDICATE_RESULT can be loaded outside of MI_PREDICATE through
> other registers to predicate other commands.

Link to userspace changes?

Regards, Joonas

> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 6 +-
>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 95478db9998b..c5bf14c3f540 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -549,6 +549,8 @@ static const struct drm_i915_reg_descriptor 
> gen7_render_regs[] = {
> REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
> REG64(MI_PREDICATE_SRC0),
> REG64(MI_PREDICATE_SRC1),
> +   REG64(MI_PREDICATE_DATA),
> +   REG32(MI_PREDICATE_RESULT),
> REG32(GEN7_3DPRIM_END_OFFSET),
> REG32(GEN7_3DPRIM_START_VERTEX),
> REG32(GEN7_3DPRIM_VERTEX_COUNT),
> @@ -1382,6 +1384,8 @@ int i915_cmd_parser_get_version(struct drm_i915_private 
> *dev_priv)
>  *the parser enabled.
>  * 9. Don't whitelist or handle oacontrol specially, as ownership
>  *for oacontrol state is moving to i915-perf.
> +* 10. Whitelist predicate data/result registers for conditional
> +* rendering in Anv.
>  */
> -   return 9;
> +   return 10;
>  }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ca8026ec0655..5c05d73eec8f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -461,6 +461,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define MI_PREDICATE_SRC0_UDW  _MMIO(0x2400 + 4)
>  #define MI_PREDICATE_SRC1  _MMIO(0x2408)
>  #define MI_PREDICATE_SRC1_UDW  _MMIO(0x2408 + 4)
> +#define MI_PREDICATE_DATA  _MMIO(0x2410)
> +#define MI_PREDICATE_RESULT_MMIO(0x2418)
>  
>  #define MI_PREDICATE_RESULT_2  _MMIO(0x2214)
>  #define  LOWER_SLICE_ENABLED   (1 << 0)
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

A quick fix to unbreak media driver, worthy inclusion before the merge window.

Best Regards,
Joonas

***

drm-intel-next-fixes-2019-05-02:

- Whitelist a register to avoid media driver from hanging

The following changes since commit 879a4e70f96a26a9368a3caed2f552aa67105852:

  drm/i915: Fix ICL output CSC programming (2019-04-29 09:49:21 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2019-05-02

for you to fetch changes up to 9628e15ca9d5f7595ba886173e98a139d0a56cd1:

  drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 
+0300)


- Whitelist a register to avoid media driver from hanging


Tvrtko Ursulin (1):
  drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1

 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next-fixes

[Joonas Lahtinen]

Thanks, pulled this now.

Regards, Joonas

Quoting Zhenyu Wang (2019-05-07 12:05:58)
> 
> Hi,
> 
> Here's gvt-next-fixes for 5.2-rc, which includes one revert for BXT
> regression, one missed context mmio reg after RCS renaming, sanitize
> display buffer size calculation and some klocwork warning/error fixes.
> 
> Thanks
> --
> The following changes since commit 447811a686e8da7325516a78069ccfbd139ef1a7:
> 
>   drm/i915/icl: Fix MG_DP_MODE() register programming (2019-04-24 09:39:11 
> +0300)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2019-05-07
> 
> for you to fetch changes up to 75fdb811d93c8aa4a9f73b63db032b1e6a8668ef:
> 
>   drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list (2019-05-05 
> 17:02:25 +0800)
> 
> 
> gvt-next-fixes-2019-05-07
> 
> - Revert MCHBAR save range change for BXT regression (Yakui)
> - Align display dmabuf size for bytes instead of error-prone pages (Xiong)
> - Fix one context MMIO save/restore after RCS0 name change (Colin)
> - Misc klocwork warning/errors fixes (Aleksei)
> 
> 
> Aleksei Gimbitskii (4):
>   drm/i915/gvt: Remove typedef and let the enumeration starts from zero
>   drm/i915/gvt: Do not copy the uninitialized pointer from fb_info
>   drm/i915/gvt: Use snprintf() to prevent possible buffer overflow.
>   drm/i915/gvt: Check if get_next_pt_type() always returns a valid value
> 
> Colin Xu (1):
>   drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list
> 
> Xiong Zhang (1):
>   drm/i915/gvt: Change fb_info->size from pages to bytes
> 
> Zhao Yakui (1):
>   drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 
> MCHBAR to optimize gvt-g boot time"
> 
>  drivers/gpu/drm/i915/gvt/debugfs.c  |  4 ++--
>  drivers/gpu/drm/i915/gvt/dmabuf.c   | 19 ---
>  drivers/gpu/drm/i915/gvt/gtt.c  | 15 +--
>  drivers/gpu/drm/i915/gvt/gtt.h  | 16 
>  drivers/gpu/drm/i915/gvt/handlers.c |  4 ++--
>  drivers/gpu/drm/i915/gvt/mmio_context.c |  1 +
>  drivers/gpu/drm/i915/gvt/reg.h  |  3 ---
>  drivers/gpu/drm/i915/gvt/scheduler.c|  2 +-
>  8 files changed, 31 insertions(+), 33 deletions(-)
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-tip:drm-tip 5/8] drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 'i915_request_await_start'

[Joonas Lahtinen]

This was caused by a silent merge conflict, and is now fixed.

Regards, Joonas

Quoting kbuild test robot (2019-05-07 13:53:48)
> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head:   73db4ec12f05160528884c0b2c845b1c6b7c6718
> commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Merge remote-tracking 
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-rhel (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout b9a2acf7709f52c77dc752ec99e3873e392d8df6
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All errors (new ones prefixed by >>):
> 
> >> drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 
> >> 'i915_request_await_start'
> i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 
> 'i915_request_await_start' was here
> i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: warning: 
> 'i915_request_await_start' defined but not used [-Wunused-function]
> 
> vim +/i915_request_await_start +827 drivers/gpu/drm/i915/i915_request.c
> 
> ca6e56f65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-04  
> 825  
> a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson 2016-09-09  
> 826  static int
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01 
> @827  i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 828  {
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 829  if (list_is_first(&signal->ring_link, 
> &signal->ring->request_list))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 830  return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 831  
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 832  signal = list_prev_entry(signal, ring_link);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 833  if (i915_timeline_sync_is_later(rq->timeline, &signal->fence))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 834  return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 835  
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 836  return i915_sw_fence_await_dma_fence(&rq->submit,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 837   &signal->fence, 0,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 838   I915_FENCE_GFP);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 839  }
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson 2019-05-01  
> 840  
> 
> :: The code at line 827 was first introduced by commit
> :: e766fde6511e2be83acbca1d603035e08de23f3b drm/i915: Delay semaphore 
> submission until the start of the signaler
> 
> :: TO: Chris Wilson 
> :: CC: Joonas Lahtinen 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-tip:drm-tip /8] drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 'already_busywaiting'

[Joonas Lahtinen]

This too was caused by a merge conflict and one missing Fixes:.

Regards, Joonas

Quoting kbuild test robot (2019-05-07 14:08:25)
> tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head:   ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
> commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Merge remote-tracking 
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-rhel (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout 47f4a14297839cb4cedd725fb916a5da5eb9b5ba
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> Note: the drm-tip/drm-tip HEAD ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a 
> builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/i915/i915_request.c:827:1: error: redefinition of 
> 'i915_request_await_start'
> i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> ^~~~
>drivers/gpu/drm/i915/i915_request.c:794:1: note: previous definition of 
> 'i915_request_await_start' was here
> i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> ^~~~
> >> drivers/gpu/drm/i915/i915_request.c:842:1: error: redefinition of 
> >> 'already_busywaiting'
> already_busywaiting(struct i915_request *rq)
> ^~~
>drivers/gpu/drm/i915/i915_request.c:809:1: note: previous definition of 
> 'already_busywaiting' was here
> already_busywaiting(struct i915_request *rq)
> ^~~
>drivers/gpu/drm/i915/i915_request.c:809:1: warning: 'already_busywaiting' 
> defined but not used [-Wunused-function]
>drivers/gpu/drm/i915/i915_request.c:794:1: warning: 
> 'i915_request_await_start' defined but not used [-Wunused-function]
> i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> ^~~~
> 
> vim +/already_busywaiting +842 drivers/gpu/drm/i915/i915_request.c
> 
> 47f4a1429 drivers/gpu/drm/i915/i915_request.c Joonas Lahtinen 2019-05-07  
> 825  
> a2bc4695b drivers/gpu/drm/i915/i915_gem_request.c Chris Wilson2016-09-09  
> 826  static int
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01 
> @827  i915_request_await_start(struct i915_request *rq, struct i915_request 
> *signal)
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 828  {
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 829   if (list_is_first(&signal->ring_link, &signal->ring->request_list))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 830   return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 831  
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 832   signal = list_prev_entry(signal, ring_link);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 833   if (i915_timeline_sync_is_later(rq->timeline, &signal->fence))
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 834   return 0;
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 835  
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 836   return i915_sw_fence_await_dma_fence(&rq->submit,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 837&signal->fence, 0,
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 838I915_FENCE_GFP);
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 839  }
> e766fde65 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-01  
> 840  
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
> 841  static intel_engine_mask_t
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04 
> @842  already_busywaiting(struct i915_request *rq)
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
> 843  {
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
> 844   /*
> 2564fe708 drivers/gpu/drm/i915/i915_request.c Chris Wilson2019-05-04  
> 845 

[Intel-gfx] [PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Still rather quiet, most issues seem to have been fixed during CI testing.

For i915, just two fixes to the request semaphore ordering code.

For GVT a couple regression and static checker fixes.

Best Regards,
Joonas

***

drm-intel-next-fixes-2019-05-09:

- Two fixes for the freshly enabled semaphore ordering code
- Includes gvt-next-fixes-2019-05-07

The following changes since commit 9628e15ca9d5f7595ba886173e98a139d0a56cd1:

  drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 
+0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2019-05-09

for you to fetch changes up to 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe:

  Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux 
into drm-intel-next-fixes (2019-05-07 15:29:15 +0300)


- Two fixes for the freshly enabled semaphore ordering code
- Includes gvt-next-fixes-2019-05-07


Aleksei Gimbitskii (4):
  drm/i915/gvt: Remove typedef and let the enumeration starts from zero
  drm/i915/gvt: Do not copy the uninitialized pointer from fb_info
  drm/i915/gvt: Use snprintf() to prevent possible buffer overflow.
  drm/i915/gvt: Check if get_next_pt_type() always returns a valid value

Chris Wilson (2):
  drm/i915: Delay semaphore submission until the start of the signaler
  drm/i915: Disable semaphore busywaits on saturated systems

Colin Xu (1):
  drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list

Joonas Lahtinen (1):
  Merge tag 'gvt-next-fixes-2019-05-07' of 
https://github.com/intel/gvt-linux into drm-intel-next-fixes

Xiong Zhang (1):
  drm/i915/gvt: Change fb_info->size from pages to bytes

Zhao Yakui (1):
  drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 
MCHBAR to optimize gvt-g boot time"

 drivers/gpu/drm/i915/gvt/debugfs.c |  4 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  | 19 --
 drivers/gpu/drm/i915/gvt/gtt.c | 15 +---
 drivers/gpu/drm/i915/gvt/gtt.h | 16 
 drivers/gpu/drm/i915/gvt/handlers.c|  4 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c|  1 +
 drivers/gpu/drm/i915/gvt/reg.h |  3 --
 drivers/gpu/drm/i915/gvt/scheduler.c   |  2 +-
 drivers/gpu/drm/i915/i915_request.c| 59 +-
 drivers/gpu/drm/i915/intel_context.c   |  1 +
 drivers/gpu/drm/i915/intel_context_types.h |  3 ++
 11 files changed, 93 insertions(+), 34 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

A fix to close a race opportunity between IRQ handler and RCU. 

Two fixes that are also stable, disabling FBC on GLK and HSW EDP fastset
correction.

These patches definitely caused conflicts when merged, resolutions should
be all good.

Regards, Joonas

***

drm-intel-next-fixes-2019-05-15:

- Disable framebuffer compression on Geminilake
- Fixes for HSW EDP fastset and a IRQ handler vs. RCU race

The following changes since commit 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe:

  Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux 
into drm-intel-next-fixes (2019-05-07 15:29:15 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2019-05-15

for you to fetch changes up to c36beba6b296b3c05a0f29753b04775e5ae23886:

  drm/i915: Seal races between async GPU cancellation, retirement and signaling 
(2019-05-13 13:53:35 +0300)


- Disable framebuffer compression on Geminilake
- Fixes for HSW EDP fastset and a IRQ handler vs. RCU race


Chris Wilson (1):
  drm/i915: Seal races between async GPU cancellation, retirement and 
signaling

Daniel Drake (1):
  drm/i915/fbc: disable framebuffer compression on GeminiLake

Ville Syrjälä (1):
  drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder

 drivers/dma-buf/dma-fence.c |  1 +
 drivers/gpu/drm/i915/i915_request.c |  1 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c| 78 +
 drivers/gpu/drm/i915/intel_display.c|  9 
 drivers/gpu/drm/i915/intel_fbc.c|  4 ++
 drivers/gpu/drm/i915/intel_guc_submission.c |  1 -
 drivers/gpu/drm/i915/intel_pipe_crc.c   | 13 +++--
 7 files changed, 82 insertions(+), 25 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-fixes

[Joonas Lahtinen]

Quoting Zhenyu Wang (2019-05-21 09:24:08)
> 
> Hi,
> 
> Here's gvt-fixes for 5.2-rc. It contains vgpu reset fix with
> proper timeline handling, fixes for guest TRTT setting which
> should be handled in context state instead of pushing directly
> to hardware and one error return fix.

This is now pulled. Thanks for the PR.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel tree

[Joonas Lahtinen]

Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
> 
> In commit
> 
>   0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the 
> signaler")
> 
> Fixes tag
> 
>   Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
> 
> has these problem(s):
> 
>   - Subject has leading but no trailing parentheses
>   - Subject has leading but no trailing quotes
> 
> Please don't split Fixes tags across more than one line.

Thanks for the report.

This was a copy'n paste mishap, detected by our tooling (and fixed by
me) at the time of creating a PR. Unfortunately the check was not being
enforced by tooling at commit time. We'll fix that.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Comments in Fixes: line (Was: Re: linux-next: Fixes tag needs some work in the drm-intel tree)

[Joonas Lahtinen]

We also have an incoming patch where the Fixes: line has a comment in
it. Does your tooling account for this when checking the Fixes: line?

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Two scheduling fixes for to oversaturated (media transcoding
scenarios) and their dependencies.

On GVT side a reset robustness fix and context state restoring
fix + error path fix caught by static checker.

Regards, Joonas

PS. As you are aware, -rc1 caused an explosion on the CI due to the ext4
regression, which in turn let other regressions creep in momentarily.
Now there is huge backlog, so the CI results are interpreted from multiple
runs. I have a good confidence on the PR, so decided to send anyway.

***

drm-intel-fixes-2019-05-23:

- Fix boosting of new client to be non-preemptive
- Fix to actually bump ready tasks ahead of busywaits
- Includes gvt-fixes-2019-05-21

The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-05-23

for you to fetch changes up to 57cb853d1d5b07ed4e4647ad61b0c16a9c21996e:

  Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2019-05-21 14:37:38 +0300)


- Fix boosting of new client to be non-preemptive
- Fix to actually bump ready tasks ahead of busywaits
- Includes gvt-fixes-2019-05-21


Chris Wilson (5):
  drm/i915: Rearrange i915_scheduler.c
  drm/i915: Pass i915_sched_node around internally
  drm/i915: Bump signaler priority on adding a waiter
  drm/i915: Downgrade NEWCLIENT to non-preemptive
  drm/i915: Truly bump ready tasks ahead of busywaits

Dan Carpenter (1):
  drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry()

Joonas Lahtinen (1):
  Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Weinan (1):
  drm/i915/gvt: emit init breadcrumb for gvt request

Yan Zhao (4):
  drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform
  drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+
  drm/i915/gvt: add 0x4dfc to gen9 save-restore list
  drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  14 +-
 drivers/gpu/drm/i915/gvt/gtt.c  |   4 +-
 drivers/gpu/drm/i915/gvt/handlers.c |  15 --
 drivers/gpu/drm/i915/gvt/mmio_context.c |  23 ++-
 drivers/gpu/drm/i915/gvt/scheduler.c|  23 ++-
 drivers/gpu/drm/i915/i915_priolist_types.h  |   5 +-
 drivers/gpu/drm/i915/i915_request.c |  42 ++---
 drivers/gpu/drm/i915/i915_scheduler.c   | 255 +++-
 drivers/gpu/drm/i915/i915_scheduler_types.h |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c|   2 +-
 drivers/gpu/drm/i915/selftests/intel_lrc.c  |  12 +-
 11 files changed, 202 insertions(+), 196 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded

[Joonas Lahtinen]

Quoting Ye, Tony (2019-05-22 14:32:41)
>  From UMD perspective, when HuC is not working as expected, usually we 
> look into the kernel log and i915_huc_load_status debugfs to find out 
> why it's not working. It will be helpful to know the reason of the 
> failure from the error code. The typically failures we encountered are 
> "HuC FW not loaded (FW not built into initramfs)" and "HuC FW 
> authentication failed".
> 
> And it looks clearer to me if we can define 0 as "disabled by user" to 
> distinguish it from other errors like ENODEV, ENOPKG and "not 
> authenticated".

Suggestion by Chris for 0/1 for huc_status makes sense to me to reflect if
HuC authentication was succesful or not. Mostly because the name of the
debugfs and func is huc_status. It also nicely maps to a register.

One could have huc_enabled which would then collapse to easy 0/1, but that'd
be bit redundant.

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 01/22] drm/i915/guc: Change platform default GuC mode

[Joonas Lahtinen]

Quoting Michal Wajdeczko (2019-05-24 02:30:28)
> Today our most desired GuC configuration is to only enable HuC
> if it is available and we really don't care about GuC submission.
> Change platform default GuC mode to match our desire.

You should amend here that the HuC authentication is needed to enable
all media codecs on the hardware.

> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Cc: Daniele Ceraolo Spurio 
> Cc: John Spotswood 
> Cc: Vinay Belgaumkar 
> Cc: Tony Ye 
> Cc: Anusha Srivatsa 
> Cc: Jeff Mcgee 
> Cc: Antonio Argenziano 
> Cc: Sujaritha Sundaresan 
> Acked-by: Tony Ye 
> Reviewed-by: Sujaritha Sundaresan 

With the patch message amended, this is:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx