Re: [Intel-gfx] [bug report] drm/i915: Move submission tasklet to i915_sched_engine

[Tvrtko Ursulin]

On 06/10/2023 19:50, John Harrison wrote:

Tvrtko, would you have any thoughts on this one?


I wasn't really involved in that work so without digging deep can only 
say that smatch seems to be noticing a genuine inconsistency. Whether or 
not it is possible at runtime Matt should know better.


3e28d37146db ("drm/i915: Move priolist to new i915_sched_engine object") 
is what added the if (ve->base.sched_engine) guard - maybe that isn't 
needed, I don't know.


Regards,

Tvrtko



On 10/4/2023 02:57, Dan Carpenter wrote:

Hello Matthew Brost,

This is a semi-automatic email about new static checker warnings.

The patch 22916bad07a5: "drm/i915: Move submission tasklet to
i915_sched_engine" from Jun 17, 2021, leads to the following Smatch
complaint:

 drivers/gpu/drm/i915/gt/intel_execlists_submission.c:3659 
rcu_virtual_context_destroy()
 warn: variable dereferenced before check 've->base.sched_engine' 
(see line 3633)


drivers/gpu/drm/i915/gt/intel_execlists_submission.c
   3632 */
   3633    tasklet_kill(&ve->base.sched_engine->tasklet);
  ^^^
The patch introduced a new dereference here

   3634
   3635    /* Decouple ourselves from the siblings, no more access 
allowed. */

   3636    for (n = 0; n < ve->num_siblings; n++) {
   3637    struct intel_engine_cs *sibling = ve->siblings[n];
   3638    struct rb_node *node = &ve->nodes[sibling->id].rb;
   3639
   3640    if (RB_EMPTY_NODE(node))
   3641    continue;
   3642
   3643    spin_lock_irq(&sibling->sched_engine->lock);
   3644
   3645    /* Detachment is lazily performed in the 
sched_engine->tasklet */

   3646    if (!RB_EMPTY_NODE(node))
   3647    rb_erase_cached(node, 
&sibling->execlists.virtual);

   3648
   3649    spin_unlock_irq(&sibling->sched_engine->lock);
   3650    }
   3651
GEM_BUG_ON(__tasklet_is_scheduled(&ve->base.sched_engine->tasklet));

   3652    GEM_BUG_ON(!list_empty(virtual_queue(ve)));
   3653
   3654    lrc_fini(&ve->context);
   3655    intel_context_fini(&ve->context);
   3656
   3657    if (ve->base.breadcrumbs)
   3658    intel_breadcrumbs_put(ve->base.breadcrumbs);
   3659    if (ve->base.sched_engine)
 ^
But previous code had assumed the sched_engine could be NULL.

   3660    i915_sched_engine_put(ve->base.sched_engine);
   3661    intel_engine_free_request_pool(&ve->base);

regards,
dan carpenter

Re: [Intel-gfx] [PATCH] drm/i915/lnl: Remove watchdog timers for PSR

[Kahola, Mika]

> -Original Message-
> From: Hogander, Jouni 
> Sent: Friday, October 6, 2023 3:12 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/lnl: Remove watchdog timers for PSR
> 
> On Fri, 2023-10-06 at 14:42 +0300, Mika Kahola wrote:
> > Currently we are not using watchdog timers for PSR/PSR2.
> > The patch disables these timers so they are not in use.
> >
> > BSpec: 69895
> >
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 24 +-
> > --
> >  1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 850b11f20285..13b58dceb2bf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -672,11 +672,15 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > u32 max_sleep_time = 0x1f;
> > -   u32 val = EDP_PSR_ENABLE;
> > +   u32 val = 0;
> 
> This is not related to the commit message. I.e. PSR1 is left disabled 
> completely for DISPLAY_VER >= 20.
 Ah, ok. Just spotted these from the spec that these are not in use for 
DISPLAY_VER >= 20. But since PSR1
is disabled completely, I will drop these.

> >
> > -   val |=
> > EDP_PSR_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
> >
> > -   val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
> > +   if (DISPLAY_VER(dev_priv) < 20) {
> > +   val =  EDP_PSR_ENABLE;
> > +   val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
> > +   }
> > +
> > +   val |=
> > EDP_PSR_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
> > if (IS_HASWELL(dev_priv))
> > val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> >
> > @@ -1398,10 +1402,16 @@ static void intel_psr_enable_source(struct
> > intel_dp *intel_dp,
> >  * runtime_pm besides preventing  other hw tracking issues now
> > we
> >  * can rely on frontbuffer tracking.
> >  */
> > -   mask = EDP_PSR_DEBUG_MASK_MEMUP |
> > -  EDP_PSR_DEBUG_MASK_HPD |
> > -  EDP_PSR_DEBUG_MASK_LPSP |
> > -  EDP_PSR_DEBUG_MASK_MAX_SLEEP;
> > +   if (DISPLAY_VER(dev_priv) >= 20)
> > +   mask = EDP_PSR_DEBUG_MASK_MEMUP |
> > +  EDP_PSR_DEBUG_MASK_HPD |
> > +  EDP_PSR_DEBUG_MASK_LPSP;
> > +   else
> > +   mask = EDP_PSR_DEBUG_MASK_MEMUP |
> > +  EDP_PSR_DEBUG_MASK_HPD |
> > +  EDP_PSR_DEBUG_MASK_LPSP |
> > +  EDP_PSR_DEBUG_MASK_MAX_SLEEP;
> 
> I would choose this:
> 
>mask = EDP_PSR_DEBUG_MASK_MEMUP |
>   EDP_PSR_DEBUG_MASK_HPD |
>   EDP_PSR_DEBUG_MASK_LPSP;
> 
>if (DISPLAY_VER(dev_priv) < 20)
>mask |= EDP_PSR_DEBUG_MASK_MAX_SLEEP;
Right. This looks a bit cleaner solution. I will update

Thanks for the comments and review!

-Mika-

> 
> BR,
> 
> Jouni Högander
> 
> > +
> >
> > /*
> >  * No separate pipe reg write mask on hsw/bdw, so have to
> > unmask all

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Tvrtko Ursulin]

On 06/10/2023 19:20, Jonathan Cavitt wrote:

From: Prathap Kumar Valsan 

The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation.  We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table.  The invalidation is submitted as
a wait request and is performed in the CT event handler.  This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.

With this new invalidation routine, we can perform GuC-based GGTT
invalidations.  GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.

Purpose of xarray:
The tlb_lookup table is allocated as an xarray because the set of
pending TLB invalidations may have no upper bound.  The consequence of
this is that all actions interfacing with this table need to use the
xarray functions, such as xa_alloc_cyclic_irq for array insertion.

Purpose of must_wait_woken:
Our wait for the G2H ack for the completion of a TLB invalidation is
mandatory; we must wait for the HW to confirm that the physical
addresses are no longer accessible before we return those to the system.

On switching to using the wait_woken() convenience routine, we
introduced ourselves to an issue where wait_woken() may complete early
under a kthread that is stopped. Since we send a TLB invalidation when
we try to release pages from the shrinker, we can be called from any
process; including kthreads.

Using wait_woken() from any process context causes another issue. The
use of is_kthread_should_stop() assumes that any task with PF_KTHREAD
set was made by kthread_create() and has called set_kthread_struct().
This is not true for the raw kernel_thread():


This explanation misses the main point of my ask - which is to explain 
why a simpler scheme isn't sufficient. Simpler scheme aka not needed the 
xarray or any flavour of wait_token().


In other words it is obvious we have to wait for the invalidation ack, 
but not obvious why we need a complicated scheme.



BUG: kernel NULL pointer dereference, address: 
[ 3089.759660] Call Trace:
[ 3089.762110]  wait_woken+0x4f/0x80
[ 3089.765496]  guc_send_invalidate_tlb+0x1fe/0x310 [i915]
[ 3089.770725]  ? syscall_return_via_sysret+0xf/0x7f
[ 3089.775426]  ? do_wait_intr_irq+0xb0/0xb0
[ 3089.779430]  ? __switch_to_asm+0x40/0x70
[ 3089.783349]  ? __switch_to_asm+0x34/0x70
[ 3089.787273]  ? __switch_to+0x7a/0x3e0
[ 3089.790930]  ? __switch_to_asm+0x34/0x70
[ 3089.794883]  intel_guc_invalidate_tlb_full+0x92/0xa0 [i915]
[ 3089.800487]  intel_invalidate_tlb_full+0x94/0x190 [i915]
[ 3089.805824]  intel_invalidate_tlb_full_sync+0x1b/0x30 [i915]
[ 3089.811508]  __i915_gem_object_unset_pages+0x138/0x150 [i915]
[ 3089.817279]  __i915_gem_object_put_pages+0x25/0x90 [i915]
[ 3089.822706]  i915_gem_shrink+0x532/0x7e0 [i915]
[ 3089.827264]  i915_gem_shrinker_scan+0x3d/0xd0 [i915]
[ 3089.832230]  do_shrink_slab+0x12c/0x2a0
[ 3089.836065]  shrink_slab+0xad/0x2b0
[ 3089.839550]  shrink_node+0xcc/0x410
[ 3089.843035]  do_try_to_free_pages+0xc6/0x380
[ 3089.847306]  try_to_free_pages+0xec/0x1c0
[ 3089.851312]  __alloc_pages_slowpath+0x3ad/0xd10
[ 3089.855845]  ? update_sd_lb_stats+0x636/0x710
[ 3089.860204]  __alloc_pages_nodemask+0x2d5/0x310
[ 3089.864737]  new_slab+0x265/0xa80
[ 3089.868053]  ___slab_alloc+0y_to_free_pages+0xec/0x1c0
[ 3089.871798]  ? copy_process+0x1e5/0x1a00
[ 3089.875717]  ? load_balance+0x165/0xb20
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.898977]  ? __switch_to_asm+0x34/0x70
[ 3089.902903]  ? __switch_to_asm+0x40/0x70
[ 3089.906828]  ? __switch_to_asm+0x34/0x70
[ 3089.910745]  _do_fork+0x83/0x350
[ 3089.913969]  ? __switch_to+0x7a/0x3e0
[ 3089.917626]  ? __switch_to_asm+0x34/0x70
[ 3089.921545]  kernel_thread+0x58/0x80
[ 3089.925124]  ? kthread_park+0x80/0x80
[ 3089.928788]  kthreadd+0x162/0x1b0
[ 3089.932098]  ? kthread_create_on_cpu+0xa0/0xa0
[ 3089.936538]  ret_from_fork+0x1f/0x40

Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Bruce Chang 
Signed-off-by: Chris Wilson 
Signed-off-by: Umesh Nerlige Ramappa 
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Aravind Iddam

Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: No TLB invalidation on suspended GT

[Tvrtko Ursulin]

On 06/10/2023 19:20, Jonathan Cavitt wrote:

In case of GT is suspended, don't allow submission of new TLB invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.

Signed-off-by: Fei Yang 
Signed-off-by: Jonathan Cavitt 
CC: John Harrison 
---
  drivers/gpu/drm/i915/gt/intel_gt.h|  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  1 +
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 +++
  drivers/gpu/drm/i915/gt/uc/intel_uc.c |  8 +++
  drivers/gpu/drm/i915/i915_driver.c|  2 ++
  5 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a7..4e3bb221d2f4d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -179,4 +179,5 @@ enum i915_map_type intel_gt_coherent_map_type(struct 
intel_gt *gt,
  void intel_gt_bind_context_set_ready(struct intel_gt *gt);
  void intel_gt_bind_context_set_unready(struct intel_gt *gt);
  bool intel_gt_is_bind_context_ready(struct intel_gt *gt);
+


Zap this.


  #endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 88deb43bbdc48..add74000e621e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -536,4 +536,5 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct 
drm_printer *p);
  
  int intel_guc_sched_disable_gucid_threshold_max(struct intel_guc *guc);
  
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);

  #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c5ccda1b3e87..4ed6e9e759007 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,13 +1796,23 @@ static void __guc_reset_context(struct intel_context 
*ce, intel_engine_mask_t st
intel_context_put(parent);
  }
  
-void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t stalled)

+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
  {
struct intel_guc_tlb_wait *wait;
+   unsigned long i;
+
+   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
+   return;
+   xa_for_each(&guc->tlb_lookup, i, wait) {
+   wake_up(&wait->wq);
+   }


Drop the curlies?


+}
+
+void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t 
stalled)
+{
struct intel_context *ce;
unsigned long index;
unsigned long flags;
-   unsigned long i;
  
  	if (unlikely(!guc_submission_initialized(guc))) {

/* Reset called during driver load? GuC not yet initialised! */
@@ -1838,8 +1848,7 @@ void intel_guc_submission_reset(struct intel_guc *guc, 
intel_engine_mask_t stall
 * invalidations on GT reset, and there's a large window of time
 * between the GT reset and GuC becoming available.
 */
-   xa_for_each(&guc->tlb_lookup, i, wait)
-   wake_up(&wait->wq);
+   wake_up_all_tlb_invalidate(guc);
  }
  
  static void guc_cancel_context_requests(struct intel_context *ce)

@@ -1935,6 +1944,12 @@ void intel_guc_submission_cancel_requests(struct 
intel_guc *guc)
  
  	/* GuC is blown away, drop all references to contexts */

xa_destroy(&guc->context_lookup);
+
+   /*
+* Wedged GT won't respond to any TLB invalidation request. Simply
+* release all the blocked waiters.
+*/
+   wake_up_all_tlb_invalidate(guc);


This goes to the following patch I think.


  }
  
  void intel_guc_submission_reset_finish(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 98b103375b7ab..8d6a4d8ce61bb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -688,6 +688,9 @@ void intel_uc_suspend(struct intel_uc *uc)
/* flush the GSC worker */
intel_gsc_uc_flush_work(&uc->gsc);
  
+	if (HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))

+   wake_up_all_tlb_invalidate(guc);
+
if (!intel_guc_is_ready(guc)) {
guc->interrupts.enabled = false;
return;
@@ -736,6 +739,11 @@ static int __uc_resume(struct intel_uc *uc, bool 
enable_communication)
  
  	intel_gsc_uc_resume(&uc->gsc);
  
+	if (HAS_GUC_TLB_INVALIDATION(gt->i915)) {

+   intel_guc_invalidate_tlb_engines(guc);
+   intel_guc_invalidate_tlb_guc(guc);
+   }
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c

index ccbb2834cde07..85ac9400c2dc7 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -72,6 +72,7 @@
  #include "gt/intel_gt.h"
  #include "gt/intel_gt_pm.h"

Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Move checks for gsc health status

[Shankar, Uma]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Wednesday, September 20, 2023 12:06 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Shankar, Uma
> ; Kandpal, Suraj 
> Subject: [PATCH 1/2] drm/i915/hdcp: Move checks for gsc health status
> 
> Move checks for gsc components required for HDCP 2.2 to work into
> intel_hdcp_gsc.c. This will also help with XE refactor on HDCP's side.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
>  3 files changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 8cca4793cf92..c89da3568ebd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector
> *connector)
> 
>   /* If MTL+ make sure gsc is loaded and proxy is setup */
>   if (intel_hdcp_gsc_cs_required(i915)) {
> - struct intel_gt *gt = i915->media_gt;
> - struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> -
> - if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> - drm_dbg_kms(&i915->drm,
> - "GSC components required for HDCP2.2 are
> not ready\n");
> + if (!intel_hdcp_gsc_check_status(i915))
>   return false;
> - }
>   }
> 
>   /* MEI/GSC interface is solid depending on which is used */ diff --git
> a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> index d753db3eef15..d355d610bc9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct drm_i915_private
> *i915)
>   return DISPLAY_VER(i915) >= 14;
>  }
> 
> +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915) {
> + struct intel_gt *gt = i915->media_gt;
> + struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> +
> + if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> + drm_dbg_kms(&i915->drm,
> + "GSC components required for HDCP2.2 are not
> ready\n");
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static int
>  gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> struct hdcp2_ake_init *ake_data)
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> index cbf96551e534..eba2057c5a9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> @@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private
> *i915, u8 *msg_in,
>   size_t msg_out_len);
>  int intel_hdcp_gsc_init(struct drm_i915_private *i915);  void
> intel_hdcp_gsc_fini(struct drm_i915_private *i915);
> +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
> 
>  #endif /* __INTEL_HDCP_GCS_H__ */
> --
> 2.25.1

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/hdcp: Move common message filling function to its own file

[Shankar, Uma]

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, September 21, 2023 11:08 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nikula, Jani
> ; Kandpal, Suraj 
> Subject: [PATCH v4 2/2] drm/i915/hdcp: Move common message filling function
> to its own file
> 
> Create a new file intel_hdcp_gsc_message that contain functions which fill the
> hdcp messages we send to gsc cs this refactor will help us reuse code for Xe 
> later
> on
> 
> --v2
> -add the missed file for proper build
> 
> --v3
> -use forward declarations instead of #includes [Jani]
> 
> --v4
> -move linux/err.h to intel_hdcp_gsc_message.c from intel_hdcp_gsc_message.h
> [Jani]
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 615 +-
> .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
> .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
>  4 files changed, 682 insertions(+), 598 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1b2e02e9d92c..27b3da6e0e43 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -265,6 +265,7 @@ i915-y += \
>   display/intel_global_state.o \
>   display/intel_hdcp.o \
>   display/intel_hdcp_gsc.o \
> + display/intel_hdcp_gsc_message.o \
>   display/intel_hotplug.o \
>   display/intel_hotplug_irq.o \
>   display/intel_hti.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> index d355d610bc9f..18117b789b16 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -11,6 +11,7 @@
>  #include "i915_drv.h"
>  #include "i915_utils.h"
>  #include "intel_hdcp_gsc.h"
> +#include "intel_hdcp_gsc_message.h"
> 
>  bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)  { @@ -31,604
> +32,6 @@ bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
>   return true;
>  }
> 
> -static int
> -gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> -   struct hdcp2_ake_init *ake_data)
> -{
> - struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
> - struct wired_cmd_initiate_hdcp2_session_out
> - session_init_out = { { 0 } };
> - struct drm_i915_private *i915;
> - ssize_t byte;
> -
> - if (!dev || !data || !ake_data)
> - return -EINVAL;
> -
> - i915 = kdev_to_i915(dev);
> - if (!i915) {
> - dev_err(dev, "DRM not initialized, aborting HDCP.\n");
> - return -ENODEV;
> - }
> -
> - session_init_in.header.api_version = HDCP_API_VERSION;
> - session_init_in.header.command_id =
> WIRED_INITIATE_HDCP2_SESSION;
> - session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
> - session_init_in.header.buffer_len =
> -
>   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> -
> - session_init_in.port.integrated_port_type = data->port_type;
> - session_init_in.port.physical_port = (u8)data->hdcp_ddi;
> - session_init_in.port.attached_transcoder = (u8)data->hdcp_transcoder;
> - session_init_in.protocol = data->protocol;
> -
> - byte = intel_hdcp_gsc_msg_send(i915, (u8 *)&session_init_in,
> -sizeof(session_init_in),
> -(u8 *)&session_init_out,
> -sizeof(session_init_out));
> - if (byte < 0) {
> - drm_dbg_kms(&i915->drm, "intel_hdcp_gsc_msg_send failed.
> %zd\n", byte);
> - return byte;
> - }
> -
> - if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
> - drm_dbg_kms(&i915->drm, "FW cmd 0x%08X Failed. Status:
> 0x%X\n",
> - WIRED_INITIATE_HDCP2_SESSION,
> - session_init_out.header.status);
> - return -EIO;
> - }
> -
> - ake_data->msg_id = HDCP_2_2_AKE_INIT;
> - ake_data->tx_caps = session_init_out.tx_caps;
> - memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
> -
> - return 0;
> -}
> -
> -static int
> -gsc_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
> -  struct hdcp_port_data *data,
> -  struct hdcp2_ake_send_cert *rx_cert,
> -  bool *km_stored,
> -  struct hdcp2_ake_no_stored_km
> - *ek_pub_km,
> -  size_t *msg_sz)
> -{
> - struct wired_cmd_verify_receiver_cert_in ver

Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: No TLB invalidation on suspended GT

[Jani Nikula]

On Mon, 09 Oct 2023, Tvrtko Ursulin  wrote:
> On 06/10/2023 19:20, Jonathan Cavitt wrote:
>> In case of GT is suspended, don't allow submission of new TLB invalidation
>> request and cancel all pending requests. The TLB entries will be
>> invalidated either during GuC reload or on system resume.
>> 
>> Signed-off-by: Fei Yang 
>> Signed-off-by: Jonathan Cavitt 
>> CC: John Harrison 
>> ---
>>   drivers/gpu/drm/i915/gt/intel_gt.h|  1 +
>>   drivers/gpu/drm/i915/gt/uc/intel_guc.h|  1 +
>>   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 +++
>>   drivers/gpu/drm/i915/gt/uc/intel_uc.c |  8 +++
>>   drivers/gpu/drm/i915/i915_driver.c|  2 ++
>>   5 files changed, 31 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
>> b/drivers/gpu/drm/i915/gt/intel_gt.h
>> index 970bedf6b78a7..4e3bb221d2f4d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
>> @@ -179,4 +179,5 @@ enum i915_map_type intel_gt_coherent_map_type(struct 
>> intel_gt *gt,
>>   void intel_gt_bind_context_set_ready(struct intel_gt *gt);
>>   void intel_gt_bind_context_set_unready(struct intel_gt *gt);
>>   bool intel_gt_is_bind_context_ready(struct intel_gt *gt);
>> +
>
> Zap this.
>
>>   #endif /* __INTEL_GT_H__ */
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>> index 88deb43bbdc48..add74000e621e 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>> @@ -536,4 +536,5 @@ void intel_guc_dump_time_info(struct intel_guc *guc, 
>> struct drm_printer *p);
>>   
>>   int intel_guc_sched_disable_gucid_threshold_max(struct intel_guc *guc);
>>   
>> +void wake_up_all_tlb_invalidate(struct intel_guc *guc);
>>   #endif
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> index 0c5ccda1b3e87..4ed6e9e759007 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> @@ -1796,13 +1796,23 @@ static void __guc_reset_context(struct intel_context 
>> *ce, intel_engine_mask_t st
>>  intel_context_put(parent);
>>   }
>>   
>> -void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t 
>> stalled)
>> +void wake_up_all_tlb_invalidate(struct intel_guc *guc)
>>   {
>>  struct intel_guc_tlb_wait *wait;
>> +unsigned long i;
>> +
>> +if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
>> +return;
>> +xa_for_each(&guc->tlb_lookup, i, wait) {
>> +wake_up(&wait->wq);
>> +}
>
> Drop the curlies?
>
>> +}
>> +
>> +void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t 
>> stalled)
>> +{
>>  struct intel_context *ce;
>>  unsigned long index;
>>  unsigned long flags;
>> -unsigned long i;
>>   
>>  if (unlikely(!guc_submission_initialized(guc))) {
>>  /* Reset called during driver load? GuC not yet initialised! */
>> @@ -1838,8 +1848,7 @@ void intel_guc_submission_reset(struct intel_guc *guc, 
>> intel_engine_mask_t stall
>>   * invalidations on GT reset, and there's a large window of time
>>   * between the GT reset and GuC becoming available.
>>   */
>> -xa_for_each(&guc->tlb_lookup, i, wait)
>> -wake_up(&wait->wq);
>> +wake_up_all_tlb_invalidate(guc);
>>   }
>>   
>>   static void guc_cancel_context_requests(struct intel_context *ce)
>> @@ -1935,6 +1944,12 @@ void intel_guc_submission_cancel_requests(struct 
>> intel_guc *guc)
>>   
>>  /* GuC is blown away, drop all references to contexts */
>>  xa_destroy(&guc->context_lookup);
>> +
>> +/*
>> + * Wedged GT won't respond to any TLB invalidation request. Simply
>> + * release all the blocked waiters.
>> + */
>> +wake_up_all_tlb_invalidate(guc);
>
> This goes to the following patch I think.
>
>>   }
>>   
>>   void intel_guc_submission_reset_finish(struct intel_guc *guc)
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> index 98b103375b7ab..8d6a4d8ce61bb 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>> @@ -688,6 +688,9 @@ void intel_uc_suspend(struct intel_uc *uc)
>>  /* flush the GSC worker */
>>  intel_gsc_uc_flush_work(&uc->gsc);
>>   
>> +if (HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
>> +wake_up_all_tlb_invalidate(guc);
>> +
>>  if (!intel_guc_is_ready(guc)) {
>>  guc->interrupts.enabled = false;
>>  return;
>> @@ -736,6 +739,11 @@ static int __uc_resume(struct intel_uc *uc, bool 
>> enable_communication)
>>   
>>  intel_gsc_uc_resume(&uc->gsc);
>>   
>> +if (HAS_GUC_TLB_INVALIDATION(gt->i915)) {
>> +intel_guc_invalidate_tlb_engines(guc);
>> +intel_guc_invalidate_tlb_guc(guc);
>> + 

Re: [Intel-gfx] [PATCH] drm/i915: Add wrapper for getting display step

[Shankar, Uma]

> -Original Message-
> From: Borah, Chaitanya Kumar 
> Sent: Tuesday, October 3, 2023 12:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> ; Manna, Animesh
> 
> Subject: [PATCH] drm/i915: Add wrapper for getting display step
> 
> Add a wrapper around intel_step_name that takes in driver data as an argument.
> This wrapper will help maintain compatibility with the proposed xe driver.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Chaitanya Kumar Borah 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
>  drivers/gpu/drm/i915/intel_step.c| 5 +
>  drivers/gpu/drm/i915/intel_step.h| 1 +
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 1623c0c5e8a1..63e080e07023 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -309,7 +309,7 @@ static const struct stepping_info *
> intel_get_stepping_info(struct drm_i915_private *i915,
>   struct stepping_info *si)
>  {
> - const char *step_name = intel_step_name(RUNTIME_INFO(i915)-
> >step.display_step);
> + const char *step_name = intel_display_step_name(i915);
> 
>   si->stepping = step_name[0];
>   si->substepping = step_name[1];
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index ee4e5a2c0220..b4162f1be765 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -353,3 +353,8 @@ const char *intel_step_name(enum intel_step step)
>   return "**";
>   }
>  }
> +
> +const char *intel_display_step_name(struct drm_i915_private *i915) {
> + return intel_step_name(RUNTIME_INFO(i915)->step.display_step);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_step.h
> b/drivers/gpu/drm/i915/intel_step.h
> index 96dfca4cba73..b6f43b624774 100644
> --- a/drivers/gpu/drm/i915/intel_step.h
> +++ b/drivers/gpu/drm/i915/intel_step.h
> @@ -78,5 +78,6 @@ enum intel_step {
> 
>  void intel_step_init(struct drm_i915_private *i915);  const char
> *intel_step_name(enum intel_step step);
> +const char *intel_display_step_name(struct drm_i915_private *i915);
> 
>  #endif /* __INTEL_STEP_H__ */
> --
> 2.25.1

[Intel-gfx] [PATCH v5 0/2] Refactor i915 HDCP for XE

[Suraj Kandpal]

This patch series contains some refactors for i915 side of things
which will help with a cleaner code and maximum reuse of code
for XE going forward.

Signed-off-by: Suraj Kandpal 

Suraj Kandpal (2):
  drm/i915/hdcp: Move checks for gsc health status
  drm/i915/hdcp: Move common message filling function to its own file

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp.c |   8 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 617 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |   1 +
 .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
 .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
 6 files changed, 692 insertions(+), 599 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h

-- 
2.25.1

[Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc health status

[Suraj Kandpal]

Move checks for gsc components required for HDCP 2.2
to work into intel_hdcp_gsc.c. This will also help
with XE refactor on HDCP's side.

Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 8cca4793cf92..c89da3568ebd 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector *connector)
 
/* If MTL+ make sure gsc is loaded and proxy is setup */
if (intel_hdcp_gsc_cs_required(i915)) {
-   struct intel_gt *gt = i915->media_gt;
-   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
-
-   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
-   drm_dbg_kms(&i915->drm,
-   "GSC components required for HDCP2.2 are 
not ready\n");
+   if (!intel_hdcp_gsc_check_status(i915))
return false;
-   }
}
 
/* MEI/GSC interface is solid depending on which is used */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index d753db3eef15..d355d610bc9f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct drm_i915_private 
*i915)
return DISPLAY_VER(i915) >= 14;
 }
 
+bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
+{
+   struct intel_gt *gt = i915->media_gt;
+   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
+
+   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
+   drm_dbg_kms(&i915->drm,
+   "GSC components required for HDCP2.2 are not 
ready\n");
+   return false;
+   }
+
+   return true;
+}
+
 static int
 gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
  struct hdcp2_ake_init *ake_data)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
index cbf96551e534..eba2057c5a9e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
@@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private 
*i915, u8 *msg_in,
size_t msg_out_len);
 int intel_hdcp_gsc_init(struct drm_i915_private *i915);
 void intel_hdcp_gsc_fini(struct drm_i915_private *i915);
+bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
 
 #endif /* __INTEL_HDCP_GCS_H__ */
-- 
2.25.1

[Intel-gfx] [PATCH v5 2/2] drm/i915/hdcp: Move common message filling function to its own file

[Suraj Kandpal]

Create a new file intel_hdcp_gsc_message that contain functions
which fill the hdcp messages we send to gsc cs this refactor will
help us reuse code for Xe later on

--v2
-add the missed file for proper build

--v3
-use forward declarations instead of #includes [Jani]

--v4
-move linux/err.h to intel_hdcp_gsc_message.c from
intel_hdcp_gsc_message.h [Jani]

--v5
-move linux include on top of drm includes [Uma]

Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 615 +-
 .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
 .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
 4 files changed, 682 insertions(+), 598 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dec78efa452a..332ff7021cf2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -269,6 +269,7 @@ i915-y += \
display/intel_global_state.o \
display/intel_hdcp.o \
display/intel_hdcp_gsc.o \
+   display/intel_hdcp_gsc_message.o \
display/intel_hotplug.o \
display/intel_hotplug_irq.o \
display/intel_hti.o \
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index d355d610bc9f..18117b789b16 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -11,6 +11,7 @@
 #include "i915_drv.h"
 #include "i915_utils.h"
 #include "intel_hdcp_gsc.h"
+#include "intel_hdcp_gsc_message.h"
 
 bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
 {
@@ -31,604 +32,6 @@ bool intel_hdcp_gsc_check_status(struct drm_i915_private 
*i915)
return true;
 }
 
-static int
-gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
- struct hdcp2_ake_init *ake_data)
-{
-   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
-   struct wired_cmd_initiate_hdcp2_session_out
-   session_init_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !ake_data)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(dev);
-   if (!i915) {
-   dev_err(dev, "DRM not initialized, aborting HDCP.\n");
-   return -ENODEV;
-   }
-
-   session_init_in.header.api_version = HDCP_API_VERSION;
-   session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
-   session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
-   session_init_in.header.buffer_len =
-   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
-
-   session_init_in.port.integrated_port_type = data->port_type;
-   session_init_in.port.physical_port = (u8)data->hdcp_ddi;
-   session_init_in.port.attached_transcoder = (u8)data->hdcp_transcoder;
-   session_init_in.protocol = data->protocol;
-
-   byte = intel_hdcp_gsc_msg_send(i915, (u8 *)&session_init_in,
-  sizeof(session_init_in),
-  (u8 *)&session_init_out,
-  sizeof(session_init_out));
-   if (byte < 0) {
-   drm_dbg_kms(&i915->drm, "intel_hdcp_gsc_msg_send failed. 
%zd\n", byte);
-   return byte;
-   }
-
-   if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
-   drm_dbg_kms(&i915->drm, "FW cmd 0x%08X Failed. Status: 0x%X\n",
-   WIRED_INITIATE_HDCP2_SESSION,
-   session_init_out.header.status);
-   return -EIO;
-   }
-
-   ake_data->msg_id = HDCP_2_2_AKE_INIT;
-   ake_data->tx_caps = session_init_out.tx_caps;
-   memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
-
-   return 0;
-}
-
-static int
-gsc_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
-struct hdcp_port_data *data,
-struct hdcp2_ake_send_cert *rx_cert,
-bool *km_stored,
-struct hdcp2_ake_no_stored_km
-   *ek_pub_km,
-size_t *msg_sz)
-{
-   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
-   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(de

[Intel-gfx] [PATCH v5 0/2] Refactor i915 HDCP for XE

[Suraj Kandpal]

This patch series contains some refactors for i915 side of things
which will help with a cleaner code and maximum reuse of code
for XE going forward.

Signed-off-by: Suraj Kandpal 

Suraj Kandpal (2):
  drm/i915/hdcp: Move checks for gsc health status
  drm/i915/hdcp: Move common message filling function to its own file

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp.c |   8 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 617 +-
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |   1 +
 .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
 .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
 6 files changed, 692 insertions(+), 599 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h

-- 
2.25.1

[Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc health status

[Suraj Kandpal]

Move checks for gsc components required for HDCP 2.2
to work into intel_hdcp_gsc.c. This will also help
with XE refactor on HDCP's side.

Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 8cca4793cf92..c89da3568ebd 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector *connector)
 
/* If MTL+ make sure gsc is loaded and proxy is setup */
if (intel_hdcp_gsc_cs_required(i915)) {
-   struct intel_gt *gt = i915->media_gt;
-   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
-
-   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
-   drm_dbg_kms(&i915->drm,
-   "GSC components required for HDCP2.2 are 
not ready\n");
+   if (!intel_hdcp_gsc_check_status(i915))
return false;
-   }
}
 
/* MEI/GSC interface is solid depending on which is used */
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index d753db3eef15..d355d610bc9f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct drm_i915_private 
*i915)
return DISPLAY_VER(i915) >= 14;
 }
 
+bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
+{
+   struct intel_gt *gt = i915->media_gt;
+   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
+
+   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
+   drm_dbg_kms(&i915->drm,
+   "GSC components required for HDCP2.2 are not 
ready\n");
+   return false;
+   }
+
+   return true;
+}
+
 static int
 gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
  struct hdcp2_ake_init *ake_data)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
index cbf96551e534..eba2057c5a9e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
@@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private 
*i915, u8 *msg_in,
size_t msg_out_len);
 int intel_hdcp_gsc_init(struct drm_i915_private *i915);
 void intel_hdcp_gsc_fini(struct drm_i915_private *i915);
+bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
 
 #endif /* __INTEL_HDCP_GCS_H__ */
-- 
2.25.1

[Intel-gfx] [PATCH v5 2/2] drm/i915/hdcp: Move common message filling function to its own file

[Suraj Kandpal]

Create a new file intel_hdcp_gsc_message that contain functions
which fill the hdcp messages we send to gsc cs this refactor will
help us reuse code for Xe later on

--v2
-add the missed file for proper build

--v3
-use forward declarations instead of #includes [Jani]

--v4
-move linux/err.h to intel_hdcp_gsc_message.c from
intel_hdcp_gsc_message.h [Jani]

--v5
-move linux include on top of drm includes [Uma]

Signed-off-by: Suraj Kandpal 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 615 +-
 .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
 .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
 4 files changed, 682 insertions(+), 598 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dec78efa452a..332ff7021cf2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -269,6 +269,7 @@ i915-y += \
display/intel_global_state.o \
display/intel_hdcp.o \
display/intel_hdcp_gsc.o \
+   display/intel_hdcp_gsc_message.o \
display/intel_hotplug.o \
display/intel_hotplug_irq.o \
display/intel_hti.o \
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index d355d610bc9f..18117b789b16 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -11,6 +11,7 @@
 #include "i915_drv.h"
 #include "i915_utils.h"
 #include "intel_hdcp_gsc.h"
+#include "intel_hdcp_gsc_message.h"
 
 bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
 {
@@ -31,604 +32,6 @@ bool intel_hdcp_gsc_check_status(struct drm_i915_private 
*i915)
return true;
 }
 
-static int
-gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
- struct hdcp2_ake_init *ake_data)
-{
-   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
-   struct wired_cmd_initiate_hdcp2_session_out
-   session_init_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !ake_data)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(dev);
-   if (!i915) {
-   dev_err(dev, "DRM not initialized, aborting HDCP.\n");
-   return -ENODEV;
-   }
-
-   session_init_in.header.api_version = HDCP_API_VERSION;
-   session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
-   session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
-   session_init_in.header.buffer_len =
-   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
-
-   session_init_in.port.integrated_port_type = data->port_type;
-   session_init_in.port.physical_port = (u8)data->hdcp_ddi;
-   session_init_in.port.attached_transcoder = (u8)data->hdcp_transcoder;
-   session_init_in.protocol = data->protocol;
-
-   byte = intel_hdcp_gsc_msg_send(i915, (u8 *)&session_init_in,
-  sizeof(session_init_in),
-  (u8 *)&session_init_out,
-  sizeof(session_init_out));
-   if (byte < 0) {
-   drm_dbg_kms(&i915->drm, "intel_hdcp_gsc_msg_send failed. 
%zd\n", byte);
-   return byte;
-   }
-
-   if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
-   drm_dbg_kms(&i915->drm, "FW cmd 0x%08X Failed. Status: 0x%X\n",
-   WIRED_INITIATE_HDCP2_SESSION,
-   session_init_out.header.status);
-   return -EIO;
-   }
-
-   ake_data->msg_id = HDCP_2_2_AKE_INIT;
-   ake_data->tx_caps = session_init_out.tx_caps;
-   memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
-
-   return 0;
-}
-
-static int
-gsc_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
-struct hdcp_port_data *data,
-struct hdcp2_ake_send_cert *rx_cert,
-bool *km_stored,
-struct hdcp2_ake_no_stored_km
-   *ek_pub_km,
-size_t *msg_sz)
-{
-   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
-   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(de

[Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

[Suraj Kandpal]

Free hw_crtc_state in verify_crtc_state after we are done using
this or else it's just a resource leak.

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 303eb68fec11..5e1c2c780412 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
}
 
if (!sw_crtc_state->hw.active)
-   return;
+   goto destroy_state;
 
intel_pipe_config_sanity_check(hw_crtc_state);
 
@@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
}
+
+destroy_state:
+   intel_crtc_destroy_state(&crtc->base, &hw_crtc_state->uapi);
 }
 
 void intel_modeset_verify_crtc(struct intel_atomic_state *state,
-- 
2.25.1

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc health status

[Jani Nikula]

On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> Move checks for gsc components required for HDCP 2.2
> to work into intel_hdcp_gsc.c. This will also help
> with XE refactor on HDCP's side.
>
> Signed-off-by: Suraj Kandpal 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 8cca4793cf92..c89da3568ebd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector 
> *connector)
>  
>   /* If MTL+ make sure gsc is loaded and proxy is setup */
>   if (intel_hdcp_gsc_cs_required(i915)) {
> - struct intel_gt *gt = i915->media_gt;
> - struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> -
> - if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> - drm_dbg_kms(&i915->drm,
> - "GSC components required for HDCP2.2 are 
> not ready\n");
> + if (!intel_hdcp_gsc_check_status(i915))

Naming nitpick, though not intended to block the patch:

I always stop at functions named "check" that return a value. What does
the return value mean? The above code reads, "if not check status".

So I usually try to name functions so that it's obvious on both sides
what it means, when you read it aloud. For example, "if not status ok".

Just something to consider for the future.


BR,
Jani.



>   return false;
> - }
>   }
>  
>   /* MEI/GSC interface is solid depending on which is used */
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> index d753db3eef15..d355d610bc9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct drm_i915_private 
> *i915)
>   return DISPLAY_VER(i915) >= 14;
>  }
>  
> +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
> +{
> + struct intel_gt *gt = i915->media_gt;
> + struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> +
> + if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> + drm_dbg_kms(&i915->drm,
> + "GSC components required for HDCP2.2 are not 
> ready\n");
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static int
>  gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> struct hdcp2_ake_init *ake_data)
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h 
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> index cbf96551e534..eba2057c5a9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> @@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private 
> *i915, u8 *msg_in,
>   size_t msg_out_len);
>  int intel_hdcp_gsc_init(struct drm_i915_private *i915);
>  void intel_hdcp_gsc_fini(struct drm_i915_private *i915);
> +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
>  
>  #endif /* __INTEL_HDCP_GCS_H__ */

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc health status

[Kandpal, Suraj]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, October 9, 2023 3:37 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc
> health status
> 
> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > Move checks for gsc components required for HDCP 2.2 to work into
> > intel_hdcp_gsc.c. This will also help with XE refactor on HDCP's side.
> >
> > Signed-off-by: Suraj Kandpal 
> > Reviewed-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
> >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
> > drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
> >  3 files changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 8cca4793cf92..c89da3568ebd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector
> > *connector)
> >
> > /* If MTL+ make sure gsc is loaded and proxy is setup */
> > if (intel_hdcp_gsc_cs_required(i915)) {
> > -   struct intel_gt *gt = i915->media_gt;
> > -   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> > -
> > -   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> > -   drm_dbg_kms(&i915->drm,
> > -   "GSC components required for HDCP2.2 are
> not ready\n");
> > +   if (!intel_hdcp_gsc_check_status(i915))
> 
> Naming nitpick, though not intended to block the patch:
> 
> I always stop at functions named "check" that return a value. What does the
> return value mean? The above code reads, "if not check status".
> 
> So I usually try to name functions so that it's obvious on both sides what it
> means, when you read it aloud. For example, "if not status ok".
> 
> Just something to consider for the future.
> 
> 

Got it Jani will keep this in mind in future

Regards,
Suraj Kandpal
> BR,
> Jani.
> 
> 
> 
> > return false;
> > -   }
> > }
> >
> > /* MEI/GSC interface is solid depending on which is used */ diff
> > --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > index d753db3eef15..d355d610bc9f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > @@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct
> drm_i915_private *i915)
> > return DISPLAY_VER(i915) >= 14;
> >  }
> >
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915) {
> > +   struct intel_gt *gt = i915->media_gt;
> > +   struct intel_gsc_uc *gsc = gt ? >->uc.gsc : NULL;
> > +
> > +   if (!gsc || !intel_uc_fw_is_running(&gsc->fw)) {
> > +   drm_dbg_kms(&i915->drm,
> > +   "GSC components required for HDCP2.2 are not
> ready\n");
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> >  static int
> >  gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> >   struct hdcp2_ake_init *ake_data) diff --git
> > a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > index cbf96551e534..eba2057c5a9e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > @@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct
> drm_i915_private *i915, u8 *msg_in,
> > size_t msg_out_len);
> >  int intel_hdcp_gsc_init(struct drm_i915_private *i915);  void
> > intel_hdcp_gsc_fini(struct drm_i915_private *i915);
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
> >
> >  #endif /* __INTEL_HDCP_GCS_H__ */
> 
> --
> Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

[Jani Nikula]

On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> Free hw_crtc_state in verify_crtc_state after we are done using
> this or else it's just a resource leak.

Fixes: ?

>
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
> b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> index 303eb68fec11..5e1c2c780412 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
>   }
>  
>   if (!sw_crtc_state->hw.active)
> - return;
> + goto destroy_state;
>  
>   intel_pipe_config_sanity_check(hw_crtc_state);
>  
> @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
>   intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
>   intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
>   }
> +
> +destroy_state:
> + intel_crtc_destroy_state(&crtc->base, &hw_crtc_state->uapi);
>  }
>  
>  void intel_modeset_verify_crtc(struct intel_atomic_state *state,

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

[Kandpal, Suraj]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, October 9, 2023 4:07 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in
> verify_crtc_state
> 
> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > Free hw_crtc_state in verify_crtc_state after we are done using this
> > or else it's just a resource leak.
> 
> Fixes: ?

Cant really trace when this was introduced as this function was split from
Intel_display.c to intel_modeset_verify.c and then this is the last commit that 
introduces it
df17ff62b626 drm/i915/display: split out modeset verification code

Should I use this commit in the fixes tag?

Regards,
Suraj Kandpal
> 
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > index 303eb68fec11..5e1c2c780412 100644
> > --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
> > }
> >
> > if (!sw_crtc_state->hw.active)
> > -   return;
> > +   goto destroy_state;
> >
> > intel_pipe_config_sanity_check(hw_crtc_state);
> >
> > @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
> > intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
> > intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
> > }
> > +
> > +destroy_state:
> > +   intel_crtc_destroy_state(&crtc->base, &hw_crtc_state->uapi);
> >  }
> >
> >  void intel_modeset_verify_crtc(struct intel_atomic_state *state,
> 
> --
> Jani Nikula, Intel

Re: [Intel-gfx] [PATCH 02/19] drm/i915/dp: Store DSC DPCD capabilities in the connector

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:10PM +0300, Imre Deak wrote:
> In an MST topology the DSC capabilities are specific to each connector,
> retrieved either from the sink if it decompresses the stream, or from a
> branch device between the source and the sink in case this branch device
> does the decompression. Accordingly each connector needs to cache its
> own DSC DPCD and FEC capabilities, along with the AUX device through
> which the decompression can be enabled. This patch prepares for that by
> storing the capabilities and the DSC AUX device in the connector, for
> now these just matching the version stored in intel_dp. The follow-up
> patches will convert all users to look up these in the connector instead
> of intel_dp, after which the intel_dp copies are removed.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  .../drm/i915/display/intel_display_types.h|  6 +++
>  drivers/gpu/drm/i915/display/intel_dp.c   | 53 +--
>  2 files changed, 43 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8d8b2f8d37a99..d6600079bcf74 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -620,6 +620,12 @@ struct intel_connector {
>  
>   struct intel_dp *mst_port;
>  
> + struct {
> + struct drm_dp_aux *dsc_decompression_aux;
> + u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
> + u8 fec_capability;
> + } dp;
> +
>   /* Work struct to schedule a uevent on link train failure */
>   struct work_struct modeset_retry_work;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1bd11f9e308c1..c7dd65a27a1b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3467,7 +3467,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp 
> *intel_dp)
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> -static void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp)
> +static void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp,
> +   struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  
> @@ -3475,35 +3476,46 @@ static void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, 
> struct intel_dp *intel_dp)
>* Clear the cached register set to avoid using stale values
>* for the sinks that do not support DSC.
>*/
> - memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> + memset(connector->dp.dsc_dpcd, 0, sizeof(connector->dp.dsc_dpcd));
>  
>   /* Clear fec_capable to avoid using stale values */
> - intel_dp->fec_capable = 0;
> + connector->dp.fec_capability = 0;
>  
>   /* Cache the DSC DPCD if eDP or DP rev >= 1.4 */
>   if ((intel_dp_is_edp(intel_dp) && dpcd_rev >= DP_EDP_14) ||
>   (!intel_dp_is_edp(intel_dp) && dpcd_rev >= 0x14)) {
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_DSC_SUPPORT,
> -  intel_dp->dsc_dpcd,
> -  sizeof(intel_dp->dsc_dpcd)) < 0)
> + if (drm_dp_dpcd_read(connector->dp.dsc_decompression_aux,
> +  DP_DSC_SUPPORT,
> +  connector->dp.dsc_dpcd,
> +  sizeof(connector->dp.dsc_dpcd)) < 0)
>   drm_err(&i915->drm,
>   "Failed to read DPCD register 0x%x\n",
>   DP_DSC_SUPPORT);
>  
>   drm_dbg_kms(&i915->drm, "DSC DPCD: %*ph\n",
> - (int)sizeof(intel_dp->dsc_dpcd),
> - intel_dp->dsc_dpcd);
> + (int)sizeof(connector->dp.dsc_dpcd),
> + connector->dp.dsc_dpcd);
>  
>   /* FEC is supported only on DP 1.4 */
>   if (!intel_dp_is_edp(intel_dp) &&
> - drm_dp_dpcd_readb(&intel_dp->aux, DP_FEC_CAPABILITY,
> -   &intel_dp->fec_capable) < 0)
> + drm_dp_dpcd_readb(connector->dp.dsc_decompression_aux,
> +   DP_FEC_CAPABILITY,
> +   &connector->dp.fec_capability) < 0)
>   drm_err(&i915->drm,
>   "Failed to read FEC DPCD register\n");
>  
>   drm_dbg_kms(&i915->drm, "FEC CAPABILITY: %x\n",
> - intel_dp->fec_capable);
> + connector->dp.fec_capability);
>   }
> +
> + /*
> +  * TODO: remove the following intel_dp copies once all users
> +  * are converted to look up DSC DPCD/FEC capability via the
> +  * connector.
> +  */

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Andi Shyti]

Hi,

...

> > @@ -131,11 +132,23 @@ void intel_gt_invalidate_tlb_full(struct intel_gt 
> > *gt, u32 seqno)
> > return;
> > with_intel_gt_pm_if_awake(gt, wakeref) {
> > +   struct intel_guc *guc = >->uc.guc;
> > +
> > mutex_lock(>->tlb.invalidate_lock);
> > if (tlb_seqno_passed(gt, seqno))
> > goto unlock;
> > -   mmio_invalidate_full(gt);
> > +   if (HAS_GUC_TLB_INVALIDATION(gt->i915)) {
> > +   /*
> > +* Only perform GuC TLB invalidation if GuC is ready.
> > +* If GuC is not ready, then there are no TLBs to
> > +* invalidate.  Ergo, skip invalidation.
> > +*/
> > +   if (intel_guc_is_ready(guc))
> > +   intel_guc_invalidate_tlb_engines(guc);
> 
> What was the answer to John's question on why it is okay to just skip and
> not maybe fall back to mmio?

this maybe can be written as:

if (HAS_GUC_TLB_INVALIDATION(gt->i915) &&
intel_guc_is_ready(guc))
intel_guc_invalidate_tlb_engines(guc);
else
mmio_invalidate_full(gt);

> > +   } else {
> > +   mmio_invalidate_full(gt);
> > +   }
> > write_seqcount_invalidate(>->tlb.seqno);
> >   unlock:

...

> > +   /*
> > +* The full GT reset will have cleared the TLB caches and flushed the
> > +* G2H message queue; we can release all the blocked waiters.
> > +*
> > +* This is safe to do unlocked because the xarray is not dependent
> > +* on the GT reset, and there's a separate execution path for TLB
> > +* invalidations on GT reset, and there's a large window of time
> > +* between the GT reset and GuC becoming available.
> > +*/
> > +   xa_for_each(&guc->tlb_lookup, i, wait)
> > +   wake_up(&wait->wq);
> 
> If you are confident there can be no failures to wake up someone, who maybe
> just added themselves to the xarray (via put pages for instance), while
> reset in ongoing. Or even removed themselves after say timing out the wait
> and so freed their entry...

I guess yuo are suggesting here to spinlock around this. The
reset is protected by the uncore->spinlock, but I don't really
see it colliding with reset, to be honest.

> >   }
> >   static void guc_cancel_context_requests(struct intel_context *ce)
> > @@ -1948,6 +1962,50 @@ void intel_guc_submission_reset_finish(struct 
> > intel_guc *guc)
> >   static void destroyed_worker_func(struct work_struct *w);
> >   static void reset_fail_worker_func(struct work_struct *w);
> > +static int init_tlb_lookup(struct intel_guc *guc)
> > +{
> > +   struct intel_guc_tlb_wait *wait;
> > +   int err;
> > +
> > +   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
> > +   return 0;
> > +
> > +   xa_init_flags(&guc->tlb_lookup, XA_FLAGS_ALLOC);
> > +
> > +   wait = kzalloc(sizeof(*wait), GFP_KERNEL);
> > +   if (!wait)
> > +   return -ENOMEM;
> > +
> > +   init_waitqueue_head(&wait->wq);
> > +
> > +   /* Preallocate a shared id for use under memory pressure. */
> > +   err = xa_alloc_cyclic_irq(&guc->tlb_lookup, &guc->serial_slot, wait,
> > + xa_limit_32b, &guc->next_seqno, GFP_KERNEL);
> > +   /* Only error if out of memory, not when busy (list full)*/
> > +   if (err == -ENOMEM) {
> > +   kfree(wait);
> > +   return err;
> > +   }
> 
> I agreed with John here that only looking at ENOMEM reads odd and I did not
> see that answered. Did I miss it?

xa_alloc_cyclic_irq() can also fail with -EBUSY... so that I
think this is a matter...

> Otherwise, I _know_ it is not likely to get any other error having *just*
> created a new xarray, but still, why not simply catch all? It is not like
> the slot fallback code at runtime would handle guc->serial_slot being
> empty?! It appears it would just explode in guc_send_invalidate_tlb if it
> would hit it..

... of what we want to do for such errors. E.g. Jonathan decided
here not to fail, but ignore the error. Should we fail for every
error?

> > +
> > +   return 0;
> > +}
> > +
> > +static void fini_tlb_lookup(struct intel_guc *guc)
> > +{
> > +   struct intel_guc_tlb_wait *wait;
> > +
> > +   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
> > +   return;
> > +
> > +   wait = xa_load(&guc->tlb_lookup, guc->serial_slot);
> > +   if (wait) {
> > +   guc_dbg(guc, "fini_tlb_lookup: Unexpected item in 
> > tlb_lookup\n");
> 
> Hm wait, why is this unexpected when init_tlb_lookup() pre-allocated that
> entry? Who frees it? guc_send_invalidate_tlb() does not appear to.

I think this links with my answer above, right? With th
refactoring of the if's for not skipping tlb invalidation.

> > +   kfree(wait);
> > +   }
> > +
> > +   xa_destroy(&guc->tlb_lookup);
> > +}
> > +
> >   /*
> >* Set up the memory resources to be shared with the GuC (via the GG

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)
URL   : https://patchwork.freedesktop.org/series/124744/
State : warning

== Summary ==

Error: dim checkpatch failed
5214d0d5d9ab drm/i915: Add GuC TLB Invalidation device info flags
2ee0cfbd271a drm/i915/guc: Add CT size delay helper
d86b647b81a9 drm/i915: Define and use GuC and CTB TLB invalidation routines
-:411: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to 
using 'fini_tlb_lookup', this function's name, in a string
#411: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2002:
+   guc_dbg(guc, "fini_tlb_lookup: Unexpected item in 
tlb_lookup\n");

total: 0 errors, 1 warnings, 0 checks, 442 lines checked
d094564be8e6 drm/i915: No TLB invalidation on suspended GT
863e68385952 drm/i915: No TLB invalidation on wedged GT
1bcbf4c6c3b2 drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck
-:23: ERROR:TRAILING_WHITESPACE: trailing whitespace
#23: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:140:
+^I * Short sleep to sanitycheck the batch is spinning before we begin $

-:29: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.rst
#29: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:146:
+   msleep(10);

total: 1 errors, 1 warnings, 0 checks, 17 lines checked
f84657534d2a drm/i915: Enable GuC TLB invalidations for MTL

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)
URL   : https://patchwork.freedesktop.org/series/124744/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)
URL   : https://patchwork.freedesktop.org/series/124744/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13728 -> Patchwork_124744v3


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/index.html

Participating hosts (37 -> 34)
--

  Missing(3): fi-bsw-nick fi-snb-2520m fi-pnv-d510 

Known issues


  Here are the changes found in Patchwork_124744v3 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: [ABORT][1] ([i915#8213] / [i915#9262]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
- fi-blb-e6850:   [ABORT][3] -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][7] ([IGT#3]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
  [i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262


Build changes
-

  * Linux: CI_DRM_13728 -> Patchwork_124744v3

  CI-20190529: 20190529
  CI_DRM_13728: e642685fe494c1893ab2fd94e6dc7b6827303d90 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7520: 6435c8825e9269bdac515ca96cba4502b5b770f5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_124744v3: e642685fe494c1893ab2fd94e6dc7b6827303d90 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

91e7ad1a7eb3 drm/i915: Enable GuC TLB invalidations for MTL
2c10f277e70f drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck
d003a77528e1 drm/i915: No TLB invalidation on wedged GT
619f08570c19 drm/i915: No TLB invalidation on suspended GT
180934d654ff drm/i915: Define and use GuC and CTB TLB invalidation routines
72a1d206a610 drm/i915/guc: Add CT size delay helper
f7cec4fecc6d drm/i915: Add GuC TLB Invalidation device info flags

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/index.html

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Nirmoy Das]

On 10/6/2023 8:20 PM, Jonathan Cavitt wrote:

From: Prathap Kumar Valsan

The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation.  We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table.  The invalidation is submitted as
a wait request and is performed in the CT event handler.  This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.

With this new invalidation routine, we can perform GuC-based GGTT
invalidations.  GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.

Purpose of xarray:
The tlb_lookup table is allocated as an xarray because the set of
pending TLB invalidations may have no upper bound.  The consequence of
this is that all actions interfacing with this table need to use the
xarray functions, such as xa_alloc_cyclic_irq for array insertion.

Purpose of must_wait_woken:
Our wait for the G2H ack for the completion of a TLB invalidation is
mandatory; we must wait for the HW to confirm that the physical
addresses are no longer accessible before we return those to the system.

On switching to using the wait_woken() convenience routine, we
introduced ourselves to an issue where wait_woken() may complete early
under a kthread that is stopped. Since we send a TLB invalidation when
we try to release pages from the shrinker, we can be called from any
process; including kthreads.

Using wait_woken() from any process context causes another issue. The
use of is_kthread_should_stop() assumes that any task with PF_KTHREAD
set was made by kthread_create() and has called set_kthread_struct().
This is not true for the raw kernel_thread():

BUG: kernel NULL pointer dereference, address: 
[ 3089.759660] Call Trace:
[ 3089.762110]  wait_woken+0x4f/0x80
[ 3089.765496]  guc_send_invalidate_tlb+0x1fe/0x310 [i915]
[ 3089.770725]  ? syscall_return_via_sysret+0xf/0x7f
[ 3089.775426]  ? do_wait_intr_irq+0xb0/0xb0
[ 3089.779430]  ? __switch_to_asm+0x40/0x70
[ 3089.783349]  ? __switch_to_asm+0x34/0x70
[ 3089.787273]  ? __switch_to+0x7a/0x3e0
[ 3089.790930]  ? __switch_to_asm+0x34/0x70
[ 3089.794883]  intel_guc_invalidate_tlb_full+0x92/0xa0 [i915]
[ 3089.800487]  intel_invalidate_tlb_full+0x94/0x190 [i915]
[ 3089.805824]  intel_invalidate_tlb_full_sync+0x1b/0x30 [i915]
[ 3089.811508]  __i915_gem_object_unset_pages+0x138/0x150 [i915]
[ 3089.817279]  __i915_gem_object_put_pages+0x25/0x90 [i915]
[ 3089.822706]  i915_gem_shrink+0x532/0x7e0 [i915]
[ 3089.827264]  i915_gem_shrinker_scan+0x3d/0xd0 [i915]
[ 3089.832230]  do_shrink_slab+0x12c/0x2a0
[ 3089.836065]  shrink_slab+0xad/0x2b0
[ 3089.839550]  shrink_node+0xcc/0x410
[ 3089.843035]  do_try_to_free_pages+0xc6/0x380
[ 3089.847306]  try_to_free_pages+0xec/0x1c0
[ 3089.851312]  __alloc_pages_slowpath+0x3ad/0xd10
[ 3089.855845]  ? update_sd_lb_stats+0x636/0x710
[ 3089.860204]  __alloc_pages_nodemask+0x2d5/0x310
[ 3089.864737]  new_slab+0x265/0xa80
[ 3089.868053]  ___slab_alloc+0y_to_free_pages+0xec/0x1c0
[ 3089.871798]  ? copy_process+0x1e5/0x1a00
[ 3089.875717]  ? load_balance+0x165/0xb20
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.898977]  ? __switch_to_asm+0x34/0x70
[ 3089.902903]  ? __switch_to_asm+0x40/0x70
[ 3089.906828]  ? __switch_to_asm+0x34/0x70
[ 3089.910745]  _do_fork+0x83/0x350
[ 3089.913969]  ? __switch_to+0x7a/0x3e0
[ 3089.917626]  ? __switch_to_asm+0x34/0x70
[ 3089.921545]  kernel_thread+0x58/0x80
[ 3089.925124]  ? kthread_park+0x80/0x80
[ 3089.928788]  kthreadd+0x162/0x1b0
[ 3089.932098]  ? kthread_create_on_cpu+0xa0/0xa0
[ 3089.936538]  ret_from_fork+0x1f/0x40

Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c  |  34 ++-
  drivers/gpu/drm/i915/gt/intel_tlb.c   |  15 +-
  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  33 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  22 ++
  drivers/gpu/drm/i915/gt/uc/intel_guc_c

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor i915 HDCP for XE (rev6)

[Patchwork]

== Series Details ==

Series: Refactor i915 HDCP for XE (rev6)
URL   : https://patchwork.freedesktop.org/series/123955/
State : warning

== Summary ==

Error: dim checkpatch failed
403c1e8a869e drm/i915/hdcp: Move checks for gsc health status
07a1c8692adb drm/i915/hdcp: Move common message filling function to its own file
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:680: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#680: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 1304 lines checked

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor i915 HDCP for XE (rev6)

[Patchwork]

== Series Details ==

Series: Refactor i915 HDCP for XE (rev6)
URL   : https://patchwork.freedesktop.org/series/123955/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic

Re: [Intel-gfx] [PATCH] drm/i915/guc: Annotate struct ct_incoming_msg with __counted_by

[Andi Shyti]

Hi Kees,

On Fri, Oct 06, 2023 at 01:17:45PM -0700, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
> array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
> 
> As found with Coccinelle[1], add __counted_by for struct ct_incoming_msg.
> 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: "Gustavo A. R. Silva" 
> Cc: John Harrison 
> Cc: Matthew Brost 
> Cc: Michal Wajdeczko 
> Cc: Matt Roper 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-harden...@vger.kernel.org
> Link: 
> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
>  [1]
> Signed-off-by: Kees Cook 

merged in drm-intel-gt-next.

Thanks,
Andi

Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

[Ville Syrjälä]

On Mon, Oct 09, 2023 at 10:58:22AM +, Kandpal, Suraj wrote:
> 
> 
> > -Original Message-
> > From: Jani Nikula 
> > Sent: Monday, October 9, 2023 4:07 PM
> > To: Kandpal, Suraj ; 
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in
> > verify_crtc_state
> > 
> > On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > > Free hw_crtc_state in verify_crtc_state after we are done using this
> > > or else it's just a resource leak.
> > 
> > Fixes: ?
> 
> Cant really trace when this was introduced as this function was split from
> Intel_display.c to intel_modeset_verify.c and then this is the last commit 
> that introduces it
> df17ff62b626 drm/i915/display: split out modeset verification code
> 
> Should I use this commit in the fixes tag?
>

Mea culpa
Fixes: 2745bdda2095 ("drm/i915: Stop clobbering old crtc state during state 
check")
Reviewed-by: Ville Syrjälä 

BTW looks like intel_encoder_current_mode() can also leak some stuff
on account of using kfree() instead of intel_crtc_destroy_state().
Can you cook up a patch to fix that one as well?

And while vlv_force_pll_on() isn't actually leaking, it'd probably
a good idea to switch over to intel_crtc_destroy_state() there as well...

> Regards,
> Suraj Kandpal
> > 
> > >
> > > Signed-off-by: Suraj Kandpal 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > index 303eb68fec11..5e1c2c780412 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
> > >   }
> > >
> > >   if (!sw_crtc_state->hw.active)
> > > - return;
> > > + goto destroy_state;
> > >
> > >   intel_pipe_config_sanity_check(hw_crtc_state);
> > >
> > > @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
> > >   intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
> > >   intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
> > >   }
> > > +
> > > +destroy_state:
> > > + intel_crtc_destroy_state(&crtc->base, &hw_crtc_state->uapi);
> > >  }
> > >
> > >  void intel_modeset_verify_crtc(struct intel_atomic_state *state,
> > 
> > --
> > Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor i915 HDCP for XE (rev6)

[Patchwork]

== Series Details ==

Series: Refactor i915 HDCP for XE (rev6)
URL   : https://patchwork.freedesktop.org/series/123955/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13728 -> Patchwork_123955v6


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/index.html

Participating hosts (37 -> 36)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): bat-dg2-9 fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_123955v6 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-bsw-n3050/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271]) +9 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-kbl-soraka/igt@kms_...@dsc-basic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: [ABORT][7] ([i915#8213] / [i915#9262]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
- fi-blb-e6850:   [ABORT][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-blb-e6850/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][11] ([i915#5334]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][13] ([IGT#3]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
  [i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262


Build changes
-

  * Linux: CI_DRM_13728 -> Patchwork_123955v6

  CI-20190529: 20190529
  CI_DRM_13728: e642685fe494c1893ab2fd94e6dc7b6827303d90 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7520: 6435c8825e9269bdac515ca96cba4502b5b770f5 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_123955v6: e642685fe494c1893ab2fd94e6dc7b6827303d90 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

da3035aa9ae4 drm/i915/hdcp: Move common message filling function to its own file
4b81a86361fc drm/i915/hdcp: Move checks for gsc health status

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v6/index.html

[Intel-gfx] [PATCH i-g-t v2 00/11] Kunit fixes and improvements

[Janusz Krzysztofik]

v2: Add a new patch that provides all results cleanup helper,
  - split out changes in handling of modprobe errors and kernel taints from
"Fetch a list of test cases in advance" to separate patches (Kamil),
  - prepare for KTAP parsing after modprobe completed in a separate
patch,
  - drop other modprobe and kernel taint related changes from the series,
  - fix some string duplicates referenced from filtered out test cases not
freed,
  - always pass last result to next dynamic sub-subtest, fetch first
result right after loading the kunit test module for execution,
  - still break the loop of test cases on unexpected return codes from
kunit_kmsg_get_result(),
  - fix typos (Kamil),
  - update commit descriptions.

Janusz Krzysztofik (11):
  lib/kunit: Fix handling of potential errors from F_GETFL
  lib/kunit: Be more verbose on errors
  lib/kunit: Fix misplaced igt_kunit() doc
  lib/kunit: Parse KTAP report from the main process thread
  lib/kunit: Omit suite name prefix if the same as subtest name
  tests/kms_selftest: Let subtest names match suite names
  lib/ktap: Drop workaround for missing top level KTAP headers
  lib/kunit: Provide all results cleanup helper
  lib/kunit: Prepare for KTAP parsing after modprobe completed
  lib/kunit: Fetch a list of test cases in advance
  lib/kunit: Execute kunit test cases only when needed

 lib/igt_kmod.c  | 418 ++
 lib/igt_ktap.c  | 580 
 lib/igt_ktap.h  |  22 --
 lib/tests/igt_ktap_parser.c |   3 +-
 tests/kms_selftest.c|  37 +--
 5 files changed, 374 insertions(+), 686 deletions(-)

-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 02/11] lib/kunit: Be more verbose on errors

[Janusz Krzysztofik]

Use a more verbose variant of igt_fail() when failing a dynamic sub-
subtest on kernel taint.  Also, print a debug message on string
duplication failure.

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Kamil Konieczny 
---
 lib/igt_kmod.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 05ff178b27..df0e650d49 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -834,7 +834,7 @@ static void __igt_kunit(struct igt_ktest *tst, const char 
*opts)
if (!pthread_tryjoin_np(modprobe_thread, NULL))
igt_assert_eq(modprobe.err, 0);
 
-   igt_fail_on(igt_kernel_tainted(&taints));
+   igt_assert_eq(igt_kernel_tainted(&taints), 0);
}
 
free(result);
@@ -861,7 +861,7 @@ void igt_kunit(const char *module_name, const char *name, 
const char *opts)
 */
if (!name) {
name = strdup(module_name);
-   if (name) {
+   if (!igt_debug_on(!name)) {
char *suffix = strstr(name, "_test");
 
if (!suffix)
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 01/11] lib/kunit: Fix handling of potential errors from F_GETFL

[Janusz Krzysztofik]

Function fcntl(..., F_GETFL, ...) that returns file status flags may also
return a negative error code.  Handle that error instead of blindly using
the returned value as flags.

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Kamil Konieczny 
---
 lib/igt_kmod.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index d98e6c5f9e..05ff178b27 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -783,8 +783,8 @@ static void __igt_kunit(struct igt_ktest *tst, const char 
*opts)
 
igt_skip_on_f(tst->kmsg < 0, "Could not open /dev/kmsg\n");
 
-   flags = fcntl(tst->kmsg, F_GETFL, 0) & ~O_NONBLOCK;
-   igt_skip_on_f(fcntl(tst->kmsg, F_SETFL, flags) == -1,
+   igt_skip_on((flags = fcntl(tst->kmsg, F_GETFL, 0), flags < 0));
+   igt_skip_on_f(fcntl(tst->kmsg, F_SETFL, flags & ~O_NONBLOCK) == -1,
  "Could not set /dev/kmsg to blocking mode\n");
 
igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 03/11] lib/kunit: Fix misplaced igt_kunit() doc

[Janusz Krzysztofik]

When igt_kunit() was converted to a helper and wrapped with a new function
promoted to take the name and role of the library API, related
documentation was left unchanged and still placed in front the demoted
function.  Update that documentation and move it to where it now belongs.

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Kamil Konieczny 
---
 lib/igt_kmod.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index df0e650d49..426ae5b26f 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -762,15 +762,6 @@ static void *modprobe_task(void *arg)
return NULL;
 }
 
-/**
- * igt_kunit:
- * @module_name: the name of the module
- * @opts: options to load the module
- *
- * Loads the test module, parses its (k)tap dmesg output, then unloads it
- *
- * Returns: IGT default codes
- */
 static void __igt_kunit(struct igt_ktest *tst, const char *opts)
 {
struct modprobe_data modprobe = { tst->kmod, opts, 0, };
@@ -849,6 +840,14 @@ static void __igt_kunit(struct igt_ktest *tst, const char 
*opts)
igt_skip_on_f(ret, "KTAP parser failed\n");
 }
 
+/**
+ * igt_kunit:
+ * @module_name: the name of the module
+ * @name: the name of subtest, if different from that derived from module name
+ * @opts: options to load the module
+ *
+ * Loads the test module, parses its (k)tap dmesg output, then unloads it
+ */
 void igt_kunit(const char *module_name, const char *name, const char *opts)
 {
struct igt_ktest tst = { .kmsg = -1, };
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 04/11] lib/kunit: Parse KTAP report from the main process thread

[Janusz Krzysztofik]

There was an attempt to parse KTAP reports in the background while a kunit
test module is loading.  However, since dynamic sub-subtests can be
executed only from the main thread, that attempt was not quite successful,
as IGT results from all executed kunit test cases were generated only
after loading of kunit test module completed.

Now that the parser maintains its state and we can call it separately for
each input line of a KTAP report, it is perfectly possible to call the
parser from the main thread while the module is loading in the background,
and convert results from kunit test cases immediately to results of IGT
dynamic sub-subtests by running an igt_dynamic() section for each result
as soon as returned by the parser.

Drop igt_ktap_parser() thread and execute igt_dynamic() for each kunit
result obtained from igt_ktap_parse() called from the main thread.

Also, drop no longer needed functions from igt_ktap soruces.

v3: Fix ktap structure not freed on lseek error,
  - fix initial SIGCHLD handler not restored,
  - fix missing handling of potential errors returned by sigaction,
  - fix potential race of read() vs. ptherad_kill(), use robust mutex for
synchronization with modprobe thread,
  - fix potentially illegal use of igt_assert() called outside of
dynamic sub-subtest section,
  - fix unsupported exit code potentially passed to igt_fail(),
  - no need to fail a dynamic sub-subtest on potential KTAP parser error
after a valid result from the parser has been processed,
  - fix trailing newlines missing from error messages,
  - add more debug statements,
  - integrate common code around kunit_result_free() into it.
v2: Interrupt blocking read() on modprobe failure.

Signed-off-by: Janusz Krzysztofik 
Acked-by: Mauro Carvalho Chehab  # v2
---
 lib/igt_kmod.c | 261 +++
 lib/igt_ktap.c | 568 -
 lib/igt_ktap.h |  22 --
 3 files changed, 222 insertions(+), 629 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 426ae5b26f..7bca4cdaab 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -1,5 +1,5 @@
 /*
- * Copyright © 2016 Intel Corporation
+ * Copyright © 2016-2023 Intel Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -26,7 +26,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+
+#include "assembler/brw_compat.h"  /* [un]likely() */
 
 #include "igt_aux.h"
 #include "igt_core.h"
@@ -748,9 +753,12 @@ void igt_kselftest_get_tests(struct kmod_module *kmod,
 }
 
 struct modprobe_data {
+   pthread_t parent;
struct kmod_module *kmod;
const char *opts;
int err;
+   pthread_mutex_t lock;
+   pthread_t thread;
 };
 
 static void *modprobe_task(void *arg)
@@ -759,16 +767,132 @@ static void *modprobe_task(void *arg)
 
data->err = modprobe(data->kmod, data->opts);
 
+   if (igt_debug_on(data->err)) {
+   int err;
+
+   while (err = pthread_mutex_trylock(&data->lock),
+  err && !igt_debug_on(err != EBUSY))
+   igt_debug_on(pthread_kill(data->parent, SIGCHLD));
+   } else {
+   /* let main thread use mutex to detect modprobe completion */
+   igt_debug_on(pthread_mutex_lock(&data->lock));
+   }
+
return NULL;
 }
 
+static void kunit_sigchld_handler(int signal)
+{
+   return;
+}
+
+static int kunit_kmsg_result_get(struct igt_list_head *results,
+struct modprobe_data *modprobe,
+int fd, struct igt_ktap_results *ktap)
+{
+   struct sigaction sigchld = { .sa_handler = kunit_sigchld_handler, },
+*saved;
+   char record[BUF_LEN + 1], *buf;
+   unsigned long taints;
+   int ret;
+
+   do {
+   int err;
+
+   if (igt_debug_on(igt_kernel_tainted(&taints)))
+   return -ENOTRECOVERABLE;
+
+   err = igt_debug_on(sigaction(SIGCHLD, &sigchld, saved));
+   if (err == -1)
+   return -errno;
+   else if (unlikely(err))
+   return err;
+
+   err = pthread_mutex_lock(&modprobe->lock);
+   switch (err) {
+   case EOWNERDEAD:
+   /* leave the mutex unrecoverable */
+   igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
+   __attribute__ ((fallthrough));
+   case ENOTRECOVERABLE:
+   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
+   if (igt_debug_on(modprobe->err))
+   return modprobe->err;
+   break;
+   case 0:
+   break;
+   default:
+   igt_debug("pt

[Intel-gfx] [PATCH i-g-t v2 05/11] lib/kunit: Omit suite name prefix if the same as subtest name

[Janusz Krzysztofik]

Kunit test modules usually contain one test suite, named after the module
name with the trailing "_test" or "_kunit" suffix omitted.  Since we
follow the same convention when we derive subtest names from module names,
there is a great chance that those two names match.  Take this into
account when composing names for IGT dynamic sub-subtest names and drop
the leading test suite name component when it is the same as subtest name.

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Mauro Carvalho Chehab 
---
 lib/igt_kmod.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 7bca4cdaab..387efbb59f 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -885,7 +885,8 @@ static void kunit_result_free(struct igt_ktap_result **r,
*r = NULL;
 }
 
-static void __igt_kunit(struct igt_ktest *tst, const char *opts)
+static void
+__igt_kunit(struct igt_ktest *tst, const char *name, const char *opts)
 {
struct modprobe_data modprobe = { pthread_self(), tst->kmod, opts, 0, };
char *suite_name = NULL, *case_name = NULL;
@@ -928,7 +929,11 @@ static void __igt_kunit(struct igt_ktest *tst, const char 
*opts)
 
r = igt_list_first_entry(&results, r, link);
 
-   igt_dynamic_f("%s-%s", r->suite_name, r->case_name) {
+   igt_dynamic_f("%s%s%s",
+ strcmp(r->suite_name, name) ?  r->suite_name : "",
+ strcmp(r->suite_name, name) ? "-" : "",
+ r->case_name) {
+
if (r->code == IGT_EXIT_INVALID) {
/* parametrized test case, get actual result */
kunit_result_free(&r, &suite_name, &case_name);
@@ -1069,7 +1074,7 @@ void igt_kunit(const char *module_name, const char *name, 
const char *opts)
 * and for documentation.
 */
igt_subtest_with_dynamic(name)
-   __igt_kunit(&tst, opts);
+   __igt_kunit(&tst, name, opts);
 
igt_fixture
igt_ktest_end(&tst);
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 07/11] lib/ktap: Drop workaround for missing top level KTAP headers

[Janusz Krzysztofik]

A workaround was implemented in IGT KTAP parser so it could accepted KTAP
reports with missing top level KTAP version and test suite plan headers.
Since kernel side commit c95e7c05c139 ("kunit: Report the count of test
suites in a module"), included in the mainline kernel since v6.6-rc1, has
fixed that issue, that workaround is no longer needed.  Drop it.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_ktap.c  | 12 
 lib/tests/igt_ktap_parser.c |  3 +--
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/lib/igt_ktap.c b/lib/igt_ktap.c
index 53a6c63288..7c52ba11ed 100644
--- a/lib/igt_ktap.c
+++ b/lib/igt_ktap.c
@@ -84,18 +84,6 @@ int igt_ktap_parse(const char *buf, struct igt_ktap_results 
*ktap)
   igt_debug_on(sscanf(buf,
   "%*1[ ]%*1[ ]%*1[ ]%*1[ ]KTAP%*[ 
]version%*[ ]%u %n",
   &n, &len) == 1 && len == strlen(buf))) {
-   /*
-* TODO: drop the following workaround as soon as
-* kernel side issue of missing lines with top level
-* KTAP version and test suite plan is fixed.
-*/
-   if (ktap->expect == KTAP_START) {
-   ktap->suite_count = 1;
-   ktap->suite_last = 0;
-   ktap->suite_name = NULL;
-   ktap->expect = SUITE_START;
-   }
-
if (igt_debug_on(ktap->expect != SUITE_START))
return -EPROTO;
 
diff --git a/lib/tests/igt_ktap_parser.c b/lib/tests/igt_ktap_parser.c
index 6357bdf6a5..476e14092f 100644
--- a/lib/tests/igt_ktap_parser.c
+++ b/lib/tests/igt_ktap_parser.c
@@ -190,8 +190,7 @@ static void ktap_top_version(void)
 
ktap = igt_ktap_alloc(&results);
igt_require(ktap);
-   /* TODO: change to -EPROTO as soon as related workaround is dropped */
-   igt_assert_eq(igt_ktap_parse("KTAP version 1\n", ktap), 
-EINPROGRESS);
+   igt_assert_eq(igt_ktap_parse("KTAP version 1\n", ktap), -EPROTO);
igt_ktap_free(ktap);
 
ktap = igt_ktap_alloc(&results);
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 06/11] tests/kms_selftest: Let subtest names match suite names

[Janusz Krzysztofik]

There is a rule specified in Kunit Test Style and Nomenclature guidelines
[1] that states modules should be named after the test suite, followed by
_test.  Of course, that rule applies only to modules that provide one test
suite per module.

As long as that rule is obeyed by authors of Kunit test modules, there is
no need to hardcode related IGT subtest names in IGT source code.  We are
already able to derive subtest names from module names, with their _test
or _kunit suffixes stripped.  We may expect those names will match Kunit
suite names provided by the modules.

Drop custom subtest names from IGT Kunit tests that still use them.
However, keep the mechanism that allows us to provide a name that differs
from that derived from module name.  That will be required if we ever need
to support a kunit test module that provides multiple test suites (think
of i915 selftests code converted to kunit and the i915 module potentially
providing three test suites: mock, live and perf).

[1] https://docs.kernel.org/dev-tools/kunit/style.html

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Kamil Konieczny 
---
 tests/kms_selftest.c | 37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/tests/kms_selftest.c b/tests/kms_selftest.c
index 080ffdf2c0..6618dbe50b 100644
--- a/tests/kms_selftest.c
+++ b/tests/kms_selftest.c
@@ -37,35 +37,30 @@
  *
  * arg[1]:
  *
- * @drm_cmdline:drm cmdline
- * @drm_damage: drm damage
- * @drm_dp_mst: drm dp mst
+ * @drm_cmdline_parser: drm cmdline parser
+ * @drm_damage_helper:  drm damage helper
+ * @drm_dp_mst_helper:  drm dp mst helper
  * @drm_format_helper:  drm format helper
  * @drm_format: drm format
- * @drm_plane:  drm plane
- * @framebuffer:framebuffer
+ * @drm_plane_helper:   drm plane helper
+ * @drm_framebuffer:drm framebuffer
  */
 
 IGT_TEST_DESCRIPTION("Basic sanity check of KMS selftests.");
 
-struct kms_kunittests {
-   const char *kunit;
-   const char *name;
-};
-
 igt_main
 {
-   static const struct kms_kunittests kunit_subtests[] = {
-   { "drm_cmdline_parser_test","drm_cmdline" },
-   { "drm_damage_helper_test", "drm_damage" },
-   { "drm_dp_mst_helper_test", "drm_dp_mst" },
-   { "drm_format_helper_test", "drm_format_helper" },
-   { "drm_format_test","drm_format" },
-   { "drm_framebuffer_test",   "framebuffer" },
-   { "drm_plane_helper_test",  "drm_plane" },
-   { NULL, NULL}
+   static const char *kunit_subtests[] = {
+   "drm_cmdline_parser_test",
+   "drm_damage_helper_test",
+   "drm_dp_mst_helper_test",
+   "drm_format_helper_test",
+   "drm_format_test",
+   "drm_framebuffer_test",
+   "drm_plane_helper_test",
+   NULL,
};
 
-   for (int i = 0; kunit_subtests[i].kunit != NULL; i++)
-   igt_kunit(kunit_subtests[i].kunit, kunit_subtests[i].name, 
NULL);
+   for (int i = 0; kunit_subtests[i] != NULL; i++)
+   igt_kunit(kunit_subtests[i], NULL, NULL);
 }
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 08/11] lib/kunit: Provide all results cleanup helper

[Janusz Krzysztofik]

Planned changes require a couple of loops around kunit_result_free().
Since we already have such loop, move it into a helper in preparation for
future uses.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_kmod.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 387efbb59f..fed0855c84 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -885,13 +885,25 @@ static void kunit_result_free(struct igt_ktap_result **r,
*r = NULL;
 }
 
+static void kunit_results_free(struct igt_list_head *results,
+  char **suite_name, char **case_name)
+{
+   struct igt_ktap_result *r, *rn;
+
+   igt_list_for_each_entry_safe(r, rn, results, link)
+   kunit_result_free(&r, suite_name, case_name);
+
+   free(*case_name);
+   free(*suite_name);
+}
+
 static void
 __igt_kunit(struct igt_ktest *tst, const char *name, const char *opts)
 {
struct modprobe_data modprobe = { pthread_self(), tst->kmod, opts, 0, };
char *suite_name = NULL, *case_name = NULL;
-   struct igt_ktap_result *r, *rn;
struct igt_ktap_results *ktap;
+   struct igt_ktap_result *r;
pthread_mutexattr_t attr;
IGT_LIST_HEAD(results);
unsigned long taints;
@@ -997,11 +1009,7 @@ __igt_kunit(struct igt_ktest *tst, const char *name, 
const char *opts)
 
} while (ret == -EINPROGRESS);
 
-   igt_list_for_each_entry_safe(r, rn, &results, link)
-   kunit_result_free(&r, &suite_name, &case_name);
-
-   free(case_name);
-   free(suite_name);
+   kunit_results_free(&results, &suite_name, &case_name);
 
switch (pthread_mutex_lock(&modprobe.lock)) {
case 0:
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 09/11] lib/kunit: Prepare for KTAP parsing after modprobe completed

[Janusz Krzysztofik]

We are going to add support for reading a list of kunit test cases
provided by a kunit test module prior to executing those test cases.  That
will be done by first loading kunit modules in list only mode, then
reading the list from /dev/kmsg with our KTAP parser.  Since that parsing
will be performed after the kunit test module is successfully loaded and
there will be no concurrently running modprobe thread, we need to make
synchronization of reads from /dev/kmsg with potential errors modprobe
thread optional.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_kmod.c | 50 ++
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index fed0855c84..ed41aa1235 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -802,34 +802,36 @@ static int kunit_kmsg_result_get(struct igt_list_head 
*results,
if (igt_debug_on(igt_kernel_tainted(&taints)))
return -ENOTRECOVERABLE;
 
-   err = igt_debug_on(sigaction(SIGCHLD, &sigchld, saved));
-   if (err == -1)
-   return -errno;
-   else if (unlikely(err))
-   return err;
-
-   err = pthread_mutex_lock(&modprobe->lock);
-   switch (err) {
-   case EOWNERDEAD:
-   /* leave the mutex unrecoverable */
-   igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
-   __attribute__ ((fallthrough));
-   case ENOTRECOVERABLE:
-   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
-   if (igt_debug_on(modprobe->err))
-   return modprobe->err;
-   break;
-   case 0:
-   break;
-   default:
-   igt_debug("pthread_mutex_lock() error: %d\n", err);
-   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
-   return -err;
+   if (modprobe) {
+   err = igt_debug_on(sigaction(SIGCHLD, &sigchld, saved));
+   if (err == -1)
+   return -errno;
+   else if (unlikely(err))
+   return err;
+
+   err = pthread_mutex_lock(&modprobe->lock);
+   switch (err) {
+   case EOWNERDEAD:
+   /* leave the mutex unrecoverable */
+   
igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
+   __attribute__ ((fallthrough));
+   case ENOTRECOVERABLE:
+   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
+   if (igt_debug_on(modprobe->err))
+   return modprobe->err;
+   break;
+   case 0:
+   break;
+   default:
+   igt_debug("pthread_mutex_lock() error: %d\n", 
err);
+   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
+   return -err;
+   }
}
 
ret = read(fd, record, BUF_LEN);
 
-   if (!err) {
+   if (modprobe && !err) {
igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
igt_debug_on(sigaction(SIGCHLD, saved, NULL));
}
-- 
2.42.0

[Intel-gfx] [PATCH i-g-t v2 10/11] lib/kunit: Fetch a list of test cases in advance

[Janusz Krzysztofik]

Recent improvements to the kernel kunit framework allow us to obtain a
list of test cases provided by a kunit test module without actually
running them.  Use that feature to get a list of expected test cases
before we enter a loop around igt_dynamic().  Once done, enter the
igt_dynamic() section for each consecutive test case immediately, even
before first line of a related KTAP report appears, then look for a result
from that test case.  That should make our IGT results output still better
synchronized with related kernel messages.

The list of test cases provided by a kunit test module can be obtained by
loading the kunit base module with specific options, then loading the test
module.  For that to be possible, take care of unloading the kunit base
module before each kunit subtest (I was wrong when in one of my previous
commit messages I suggested that on final unload of a kunit test module
the kunit base module is unloaded automatically as its dependency,
however, that didn't matter before, then no separate fix was required).
Since that module can then be left loaded with non-default options if an
error occurs, unload it explicitly before returning from igt_kunit().

There are two possible ways of getting a list of test cases: by loading
the base kunit module with action=list module option, or by filtering
out all test cases from being executed while asking for SKIP results from
those filtered out.  Since the latter provides regular KTAP report that we
can already parse perfectly, use it instead of trying to identify an
unstructured list of test cases of unknown length submitted by the former.

If an IGT test that calls igt_kunit() provides a subtest name then use
that name to filter out potential test cases that don't belong to the
named test suite from the list.

To avoid loading any modules if no subtest is going to be executed (e.g.,
if a nonexistent subtest has been requested), load the kunit modules in
list mode from inside the igt_subtest_with_dynamic() section.  In order to
be free to skip the whole subtest on unmet requirements that need to be
verified after that list has been already populated, clean it up from a
follow up igt_fixture section.

Since we may now finish processing of all test cases / dynamic sub-
subtests before KTAP parsing completes, don't fail if we exit the loop of
dynamic sub-subtests with -EINPROGRESS error code returned by the parser.

v2: Split out changes in handling of modprobe errors and kernel taints to
separate patches (Kamil),
  - fix some string duplicates referenced from filtered out test cases not
freed,
  - don't check if next result is needed before fetching one, obviously
true in first dynamic sub-subtest, and we always free last result
before looping to next sub-subtest,
  - still break the loop of test cases on unexpected return codes from
kunit_kmsg_get_result(),
  - use kunit_results_free() helper,
  - fix typos (Kamil),
  - update commit description.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_kmod.c | 169 ++---
 1 file changed, 132 insertions(+), 37 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index ed41aa1235..150fe49803 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -899,17 +899,15 @@ static void kunit_results_free(struct igt_list_head 
*results,
free(*suite_name);
 }
 
-static void
-__igt_kunit(struct igt_ktest *tst, const char *name, const char *opts)
+static void kunit_get_tests(struct igt_list_head *tests,
+   struct igt_ktest *tst,
+   const char *filter,
+   const char *opts)
 {
-   struct modprobe_data modprobe = { pthread_self(), tst->kmod, opts, 0, };
char *suite_name = NULL, *case_name = NULL;
+   struct igt_ktap_result *r, *rn;
struct igt_ktap_results *ktap;
-   struct igt_ktap_result *r;
-   pthread_mutexattr_t attr;
-   IGT_LIST_HEAD(results);
-   unsigned long taints;
-   int flags, ret;
+   int flags, err;
 
igt_skip_on_f(tst->kmsg < 0, "Could not open /dev/kmsg\n");
 
@@ -919,6 +917,70 @@ __igt_kunit(struct igt_ktest *tst, const char *name, const 
char *opts)
 
igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
 
+   /*
+* To get a list of test cases provided by a kunit test module, ask the
+* generic kunit module to respond with SKIP result for each test found.
+* We could also use action=list kunit parameter to get the listing,
+* however, parsing a KTAP report -- something that we already can do
+* perfectly -- seems to be more safe than extracting a test case list
+* of unknown length from /dev/kmsg.
+*/
+   igt_skip_on(igt_kmod_load("kunit", "filter=module=none 
filter_action=skip"));
+   igt_skip_on(modprobe(tst->kmod, opts));
+
+   ktap = igt_ktap_alloc(tests);
+   igt_require(ktap);
+
+   do
+   err = kunit_kmsg_

[Intel-gfx] [PATCH i-g-t v2 11/11] lib/kunit: Execute kunit test cases only when needed

[Janusz Krzysztofik]

IGT user interface allows to request execution of only those dynamic sub-
subtests that match a user provided name pattern.  If the user pattern
doesn't match any names of test cases provided by a kunit test module used
with the subtest to be run then no results from any dynamic sub-subtests
will be reported.  Since we already know the list of test cases provided
by the kunit test module, there is no need to load that module to execute
them unless the user pattern matches at least one of those test cases.

Don't load the kunit test module in execute mode before entering the loop
of dynamic sub-subtests, and do that only from the first actually executed
dynamic sub-subtest.

v2: Always pass last result to next dynamic sub-subtest, fetch first
result right after loading the kunit test module for execution.

Signed-off-by: Janusz Krzysztofik 
---
 lib/igt_kmod.c | 66 ++
 1 file changed, 35 insertions(+), 31 deletions(-)

diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
index 150fe49803..69915adc40 100644
--- a/lib/igt_kmod.c
+++ b/lib/igt_kmod.c
@@ -981,33 +981,37 @@ static void __igt_kunit(struct igt_ktest *tst,
 
igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
 
-   igt_skip_on(pthread_mutexattr_init(&attr));
-   igt_skip_on(pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST));
-   igt_skip_on(pthread_mutex_init(&modprobe.lock, &attr));
-
ktap = igt_ktap_alloc(&results);
igt_require(ktap);
 
-   if (igt_debug_on(pthread_create(&modprobe.thread, NULL,
-   modprobe_task, &modprobe))) {
-   igt_ktap_free(ktap);
-   igt_skip("Failed to create a modprobe thread\n");
-   }
-
igt_list_for_each_entry(t, tests, link) {
igt_dynamic_f("%s%s%s",
  strcmp(t->suite_name, name) ?  t->suite_name : "",
  strcmp(t->suite_name, name) ? "-" : "",
  t->case_name) {
 
-   if (igt_list_empty(&results)) {
+   if (!modprobe.thread) {
+   igt_assert_eq(pthread_mutexattr_init(&attr), 0);
+   igt_assert_eq(pthread_mutexattr_setrobust(&attr,
+ PTHREAD_MUTEX_ROBUST),
+ 0);
+   igt_assert_eq(pthread_mutex_init(&modprobe.lock,
+&attr), 0);
+
+   modprobe.err = pthread_create(&modprobe.thread,
+ NULL,
+ modprobe_task,
+ &modprobe);
+   igt_assert_eq(modprobe.err, 0);
+
+   igt_assert(igt_list_empty(&results));
igt_assert_eq(ret, -EINPROGRESS);
ret = kunit_kmsg_result_get(&results, &modprobe,
tst->kmsg, ktap);
igt_fail_on(igt_list_empty(&results));
-   }
 
-   r = igt_list_first_entry(&results, r, link);
+   r = igt_list_first_entry(&results, r, link);
+   }
 
while (igt_debug_on_f(strcmp(r->suite_name, 
t->suite_name),
  "suite_name expected: %s, got: 
%s\n",
@@ -1079,30 +1083,30 @@ static void __igt_kunit(struct igt_ktest *tst,
igt_assert_eq(igt_kernel_tainted(&taints), 0);
}
 
-   kunit_result_free(&r, &suite_name, &case_name);
-
if (igt_debug_on(ret != -EINPROGRESS))
break;
}
 
kunit_results_free(&results, &suite_name, &case_name);
 
-   switch (pthread_mutex_lock(&modprobe.lock)) {
-   case 0:
-   igt_debug_on(pthread_cancel(modprobe.thread));
-   igt_debug_on(pthread_mutex_unlock(&modprobe.lock));
-   igt_debug_on(pthread_join(modprobe.thread, NULL));
-   break;
-   case EOWNERDEAD:
-   /* leave the mutex unrecoverable */
-   igt_debug_on(pthread_mutex_unlock(&modprobe.lock));
-   break;
-   case ENOTRECOVERABLE:
-   break;
-   default:
-   igt_debug("pthread_mutex_lock() failed\n");
-   igt_debug_on(pthread_join(modprobe.thread, NULL));
-   break;
+   if (modprobe.thread) {
+   switch (pthread_mutex_lock(&modprobe.lock)) {
+   case 0:
+   igt_debug_on(pthread_cancel(modprobe.thread));
+   igt_debug_on(pth

Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

[Jani Nikula]

On Mon, 09 Oct 2023, "Kandpal, Suraj"  wrote:
>> -Original Message-
>> From: Jani Nikula 
>> Sent: Monday, October 9, 2023 4:07 PM
>> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in
>> verify_crtc_state
>> 
>> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
>> > Free hw_crtc_state in verify_crtc_state after we are done using this
>> > or else it's just a resource leak.
>> 
>> Fixes: ?
>
> Cant really trace when this was introduced as this function was split from
> Intel_display.c to intel_modeset_verify.c and then this is the last commit 
> that introduces it
> df17ff62b626 drm/i915/display: split out modeset verification code
>
> Should I use this commit in the fixes tag?

Look into git annotate.

BR,
Jani.

>
> Regards,
> Suraj Kandpal
>> 
>> >
>> > Signed-off-by: Suraj Kandpal 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
>> >  1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
>> > b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
>> > index 303eb68fec11..5e1c2c780412 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
>> > @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
>> >}
>> >
>> >if (!sw_crtc_state->hw.active)
>> > -  return;
>> > +  goto destroy_state;
>> >
>> >intel_pipe_config_sanity_check(hw_crtc_state);
>> >
>> > @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
>> >intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
>> >intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
>> >}
>> > +
>> > +destroy_state:
>> > +  intel_crtc_destroy_state(&crtc->base, &hw_crtc_state->uapi);
>> >  }
>> >
>> >  void intel_modeset_verify_crtc(struct intel_atomic_state *state,
>> 
>> --
>> Jani Nikula, Intel

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Tvrtko Ursulin]

On 09/10/2023 12:40, Andi Shyti wrote:

Hi,

...


@@ -131,11 +132,23 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
return;
with_intel_gt_pm_if_awake(gt, wakeref) {
+   struct intel_guc *guc = >->uc.guc;
+
mutex_lock(>->tlb.invalidate_lock);
if (tlb_seqno_passed(gt, seqno))
goto unlock;
-   mmio_invalidate_full(gt);
+   if (HAS_GUC_TLB_INVALIDATION(gt->i915)) {
+   /*
+* Only perform GuC TLB invalidation if GuC is ready.
+* If GuC is not ready, then there are no TLBs to
+* invalidate.  Ergo, skip invalidation.
+*/
+   if (intel_guc_is_ready(guc))
+   intel_guc_invalidate_tlb_engines(guc);


What was the answer to John's question on why it is okay to just skip and
not maybe fall back to mmio?


this maybe can be written as:

if (HAS_GUC_TLB_INVALIDATION(gt->i915) &&
intel_guc_is_ready(guc))
intel_guc_invalidate_tlb_engines(guc);
else
mmio_invalidate_full(gt);


+   } else {
+   mmio_invalidate_full(gt);
+   }
write_seqcount_invalidate(>->tlb.seqno);
   unlock:


...


+   /*
+* The full GT reset will have cleared the TLB caches and flushed the
+* G2H message queue; we can release all the blocked waiters.
+*
+* This is safe to do unlocked because the xarray is not dependent
+* on the GT reset, and there's a separate execution path for TLB
+* invalidations on GT reset, and there's a large window of time
+* between the GT reset and GuC becoming available.
+*/
+   xa_for_each(&guc->tlb_lookup, i, wait)
+   wake_up(&wait->wq);


If you are confident there can be no failures to wake up someone, who maybe
just added themselves to the xarray (via put pages for instance), while
reset in ongoing. Or even removed themselves after say timing out the wait
and so freed their entry...


I guess yuo are suggesting here to spinlock around this. The
reset is protected by the uncore->spinlock, but I don't really
see it colliding with reset, to be honest.


I am not suggesting since I don't know the flows well enough, just asking. If 
you are confident what I wrote is impossible then okay.


   }
   static void guc_cancel_context_requests(struct intel_context *ce)
@@ -1948,6 +1962,50 @@ void intel_guc_submission_reset_finish(struct intel_guc 
*guc)
   static void destroyed_worker_func(struct work_struct *w);
   static void reset_fail_worker_func(struct work_struct *w);
+static int init_tlb_lookup(struct intel_guc *guc)
+{
+   struct intel_guc_tlb_wait *wait;
+   int err;
+
+   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
+   return 0;
+
+   xa_init_flags(&guc->tlb_lookup, XA_FLAGS_ALLOC);
+
+   wait = kzalloc(sizeof(*wait), GFP_KERNEL);
+   if (!wait)
+   return -ENOMEM;
+
+   init_waitqueue_head(&wait->wq);
+
+   /* Preallocate a shared id for use under memory pressure. */
+   err = xa_alloc_cyclic_irq(&guc->tlb_lookup, &guc->serial_slot, wait,
+ xa_limit_32b, &guc->next_seqno, GFP_KERNEL);
+   /* Only error if out of memory, not when busy (list full)*/
+   if (err == -ENOMEM) {
+   kfree(wait);
+   return err;
+   }


I agreed with John here that only looking at ENOMEM reads odd and I did not
see that answered. Did I miss it?


xa_alloc_cyclic_irq() can also fail with -EBUSY... so that I
think this is a matter...


Otherwise, I _know_ it is not likely to get any other error having *just*
created a new xarray, but still, why not simply catch all? It is not like
the slot fallback code at runtime would handle guc->serial_slot being
empty?! It appears it would just explode in guc_send_invalidate_tlb if it
would hit it..


... of what we want to do for such errors. E.g. Jonathan decided
here not to fail, but ignore the error. Should we fail for every
error?


Why not fail on *any* error? This is a fresh and empty xarray. If there is any 
error at this point how can the driver continue operating?

As I wrote, AFAICT it would explode in guc_send_invalidate_tlb() where it 
assumes xa_load on the guc_serial slot always returns a valid pointer.




+
+   return 0;
+}
+
+static void fini_tlb_lookup(struct intel_guc *guc)
+{
+   struct intel_guc_tlb_wait *wait;
+
+   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
+   return;
+
+   wait = xa_load(&guc->tlb_lookup, guc->serial_slot);
+   if (wait) {
+   guc_dbg(guc, "fini_tlb_lookup: Unexpected item in 
tlb_lookup\n");


Hm wait, why is this unexpected when init_tlb_lookup() pre-allocated that
entry? Who 

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Tvrtko Ursulin]

On 09/10/2023 13:12, Nirmoy Das wrote:


On 10/6/2023 8:20 PM, Jonathan Cavitt wrote:

From: Prathap Kumar Valsan

The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation.  We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table.  The invalidation is submitted as
a wait request and is performed in the CT event handler.  This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.

With this new invalidation routine, we can perform GuC-based GGTT
invalidations.  GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.

Purpose of xarray:
The tlb_lookup table is allocated as an xarray because the set of
pending TLB invalidations may have no upper bound.  The consequence of
this is that all actions interfacing with this table need to use the
xarray functions, such as xa_alloc_cyclic_irq for array insertion.

Purpose of must_wait_woken:
Our wait for the G2H ack for the completion of a TLB invalidation is
mandatory; we must wait for the HW to confirm that the physical
addresses are no longer accessible before we return those to the system.

On switching to using the wait_woken() convenience routine, we
introduced ourselves to an issue where wait_woken() may complete early
under a kthread that is stopped. Since we send a TLB invalidation when
we try to release pages from the shrinker, we can be called from any
process; including kthreads.

Using wait_woken() from any process context causes another issue. The
use of is_kthread_should_stop() assumes that any task with PF_KTHREAD
set was made by kthread_create() and has called set_kthread_struct().
This is not true for the raw kernel_thread():

BUG: kernel NULL pointer dereference, address: 
[ 3089.759660] Call Trace:
[ 3089.762110]  wait_woken+0x4f/0x80
[ 3089.765496]  guc_send_invalidate_tlb+0x1fe/0x310 [i915]
[ 3089.770725]  ? syscall_return_via_sysret+0xf/0x7f
[ 3089.775426]  ? do_wait_intr_irq+0xb0/0xb0
[ 3089.779430]  ? __switch_to_asm+0x40/0x70
[ 3089.783349]  ? __switch_to_asm+0x34/0x70
[ 3089.787273]  ? __switch_to+0x7a/0x3e0
[ 3089.790930]  ? __switch_to_asm+0x34/0x70
[ 3089.794883]  intel_guc_invalidate_tlb_full+0x92/0xa0 [i915]
[ 3089.800487]  intel_invalidate_tlb_full+0x94/0x190 [i915]
[ 3089.805824]  intel_invalidate_tlb_full_sync+0x1b/0x30 [i915]
[ 3089.811508]  __i915_gem_object_unset_pages+0x138/0x150 [i915]
[ 3089.817279]  __i915_gem_object_put_pages+0x25/0x90 [i915]
[ 3089.822706]  i915_gem_shrink+0x532/0x7e0 [i915]
[ 3089.827264]  i915_gem_shrinker_scan+0x3d/0xd0 [i915]
[ 3089.832230]  do_shrink_slab+0x12c/0x2a0
[ 3089.836065]  shrink_slab+0xad/0x2b0
[ 3089.839550]  shrink_node+0xcc/0x410
[ 3089.843035]  do_try_to_free_pages+0xc6/0x380
[ 3089.847306]  try_to_free_pages+0xec/0x1c0
[ 3089.851312]  __alloc_pages_slowpath+0x3ad/0xd10
[ 3089.855845]  ? update_sd_lb_stats+0x636/0x710
[ 3089.860204]  __alloc_pages_nodemask+0x2d5/0x310
[ 3089.864737]  new_slab+0x265/0xa80
[ 3089.868053]  ___slab_alloc+0y_to_free_pages+0xec/0x1c0
[ 3089.871798]  ? copy_process+0x1e5/0x1a00
[ 3089.875717]  ? load_balance+0x165/0xb20
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.898977]  ? __switch_to_asm+0x34/0x70
[ 3089.902903]  ? __switch_to_asm+0x40/0x70
[ 3089.906828]  ? __switch_to_asm+0x34/0x70
[ 3089.910745]  _do_fork+0x83/0x350
[ 3089.913969]  ? __switch_to+0x7a/0x3e0
[ 3089.917626]  ? __switch_to_asm+0x34/0x70
[ 3089.921545]  kernel_thread+0x58/0x80
[ 3089.925124]  ? kthread_park+0x80/0x80
[ 3089.928788]  kthreadd+0x162/0x1b0
[ 3089.932098]  ? kthread_create_on_cpu+0xa0/0xa0
[ 3089.936538]  ret_from_fork+0x1f/0x40

Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c  |  34 ++-
  drivers/gpu/drm/i915/gt/intel_tlb.c   |  15 +-
  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  33 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  22 +

Re: [Intel-gfx] [PATCH] drm/i915/display: Reset message bus after each read/write operation

[Gustavo Sousa]

Quoting Rodrigo Vivi (2023-10-05 12:13:34-03:00)
>On Thu, Oct 05, 2023 at 03:05:31AM -0400, Kahola, Mika wrote:
>> > -Original Message-
>> > From: Vivi, Rodrigo 
>> > Sent: Wednesday, October 4, 2023 3:56 PM
>> > To: Kahola, Mika 
>> > Cc: intel-gfx@lists.freedesktop.org
>> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Reset message bus after 
>> > each read/write operation
>> > 
>> > On Wed, Oct 04, 2023 at 01:25:04PM +0300, Mika Kahola wrote:
>> > > Every know and then we receive the following error when running for
>> > > example IGT test kms_flip.
>> > >
>> > > [drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
>> > > [drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
>> > >
>> > > Since the error is sporadic in nature, the patch proposes to reset the
>> > > message bus after every successful or unsuccessful read or write
>> > > operation. However, testing revealed that this alone is not sufficient
>> > > method an additiona delay is also introduces anything from 200us to
>> > > 300us. This delay is experimental value and has no specification to
>> > > back it up.
>> > 
>> > have you tried the delays without the bus_reset?
>> Yes, we have bumped up the delay, first from 0x100 to 0x200 and then as per 
>> BSpec change 0xa000 and I have tried 0xf000. Increasing the timeout reduces
>> the frequency of this error but doesn't solve this issue.
>
>what is exactly this BSPec's 0xa000? where can I see it? So maybe you can
>update the message above removing the 'no specification to back it up'.

I think we are confusing "delay" with the "timeout parameter" of the msgbus.

The PHY has a register to control the timeout parameter of msgbus transactions
(BSpec 65156). It's default value is 0x100. With commit e028d7a4235d
("drm/i915/cx0: Check and increase msgbus timeout threshold"), we had integrated
a workaround that bumped the timeout value to 0x200 in case timeouts were
observed. Later on, there was a BSpec update with the formal timeout value to be
programmed to 0xa000, which was incorporated with commit e35628968032
("drm/i915/cx0: Add step for programming msgbus timer").

I *believe* what Rodrigo has asked was about the usleep_range() calls added with
this patch, if we tried to only keep the usleed_range() without the bus reset.

--
Gustavo Sousa

>
>Oh, and my english is bad, but it looks to me that 'empirical' might
>sound better than 'experimental' for this case, since you really did
>a lot of experiments before coming to this final conclusion.
>
>> 
>> > have you talked to hw architects about this?
>> Yes, HW guys requested traces which I provided but based on these the 
>> sequence we use in i915
>> is correct.
>> 
>> > 
>> > I wonder if we should add the delay inside the bus_reset itself?
>> > although the bit 15 clear check should be enough by itself and it doesn't 
>> > look like it is a hw/fw reset involved to justify the extra
>> > delay.
>> That should be enough. To me, it looks like when reading/writing to the bus 
>> maybe too fast, the hw cannot handle that and we need
>> to reset and let things settle down before trying again.
>> 
>> > 
>> > well, at least some /* FIXME: */ or /* XXX: */ comments is desired along 
>> > with the messages if we are going with this hack without
>> > understanding why...
>> True, I will add these the the patch.
>> 
>> Thanks for review!
>> 
>> -Mika-
>> > 
>> > >
>> > > Signed-off-by: Mika Kahola 
>> > > ---
>> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 6 ++
>> > >  1 file changed, 6 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > index abd607b564f1..a71b8a29d6b0 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > @@ -220,9 +220,12 @@ static u8 __intel_cx0_read(struct drm_i915_private 
>> > > *i915, enum port port,
>> > >  /* 3 tries is assumed to be enough to read successfully */
>> > >  for (i = 0; i < 3; i++) {
>> > >  status = __intel_cx0_read_once(i915, port, lane, addr);
>> > > +intel_cx0_bus_reset(i915, port, lane);
>> > >
>> > >  if (status >= 0)
>> > >  return status;
>> > > +
>> > > +usleep_range(200, 300);
>> > >  }
>> > >
>> > >  drm_err_once(&i915->drm, "PHY %c Read %04x failed after %d
>> > > retries.\n", @@ -299,9 +302,12 @@ static void __intel_cx0_write(struct 
>> > > drm_i915_private *i915, enum port port,
>> > >  /* 3 tries is assumed to be enough to write successfully */
>> > >  for (i = 0; i < 3; i++) {
>> > >  status = __intel_cx0_write_once(i915, port, lane, addr, 
>> > > data,
>> > > committed);
>> > > +intel_cx0_bus_reset(i915, port, lane);
>> > >
>> > >  if (status == 0)
>> > >  return;
>> > > +
>> > > +usleep_ra

[Intel-gfx] [PATCH 1/4] drm/i915/dsb: Allocate command buffer from local memory

[Ville Syrjala]

From: Ville Syrjälä 

Using system memory for the DSB command buffer doesn't appear to work.
On DG2 it seems like the hardware internally replaces the actual memory
reads with zeroes, and so we end up executing a bunch of NOOPs instead
of whatever commands we put in the buffer. To determine that I measured
the time it takes to execute the instructions, and the results are
always more or less consistent with executing a buffer full of NOOPs
from local memory.

Another theory I considered was some kind of cache coherency issue.
Looks like i915_gem_object_pin_map_unlocked() will in fact give you a
WB mapping for system memory on DGFX regardless of what mapping mode
was requested (WC in case of the DSB code). But clflush did not
change the behaviour at all, so that theory seems moot.

On DG1 it looks like the hardware might actually be fetching data from
system memory as the logs indicate that we just get underruns. But that
is equally bad, so doens't look like we can really use system memory on
DG1 either.

Thus always allocate the DSB command buffer from local memory on
discrete GPUs.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 3e32aa49b8eb..7410ba3126f9 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -5,6 +5,7 @@
  */
 
 #include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_lmem.h"
 
 #include "i915_drv.h"
 #include "i915_irq.h"
@@ -461,7 +462,11 @@ struct intel_dsb *intel_dsb_prepare(const struct 
intel_crtc_state *crtc_state,
/* ~1 qword per instruction, full cachelines */
size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
 
-   obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
+   if (HAS_LMEM(i915))
+   obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
+ I915_BO_ALLOC_CONTIGUOUS);
+   else
+   obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
if (IS_ERR(obj))
goto out_put_rpm;
 
-- 
2.41.0

[Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer cache coherency settings

[Ville Syrjala]

From: Ville Syrjälä 

The display engine does not snoop the caches so shoukd to mark
the DSB command buffer as I915_CACHE_NONE.
i915_gem_object_create_internal() always gives us I915_CACHE_LLC
on LLC platforms. And to make things 100% correct we should also
clflush at the end, if necessary.

Note that currently this is a non-issue as we always write the
command buffer through a WC mapping, so a cache flush is not actually
needed. But we might actually want to consider a WB mapping since
we also end up reading from the command buffer (in the indexed
reg write handling). Either that or we should do something else
to avoid those reads (might actually be even more sensible on DGFX
since we end up reading over PCIe). But we should measure the overhead
first...

Anyways, no real harm in adding the belts and suspenders here so
that the code will work correctly regardless of how we map the
buffer. If we do get a WC mapping (as we request)
i915_gem_object_flush_map() will be a nop. Well, apart form
a wmb() which may just flush the WC buffer a bit earlier
than would otherwise happen (at the latest the mmio accesses
would trigger the WC flush).

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 7410ba3126f9..78b6fe24dcd8 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -316,6 +316,8 @@ void intel_dsb_finish(struct intel_dsb *dsb)
   DSB_FORCE_DEWAKE, 0);
 
intel_dsb_align_tail(dsb);
+
+   i915_gem_object_flush_map(dsb->vma->obj);
 }
 
 static int intel_dsb_dewake_scanline(const struct intel_crtc_state *crtc_state)
@@ -462,13 +464,18 @@ struct intel_dsb *intel_dsb_prepare(const struct 
intel_crtc_state *crtc_state,
/* ~1 qword per instruction, full cachelines */
size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
 
-   if (HAS_LMEM(i915))
+   if (HAS_LMEM(i915)) {
obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
  I915_BO_ALLOC_CONTIGUOUS);
-   else
+   if (IS_ERR(obj))
+   goto out_put_rpm;
+   } else {
obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
-   if (IS_ERR(obj))
-   goto out_put_rpm;
+   if (IS_ERR(obj))
+   goto out_put_rpm;
+
+   i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+   }
 
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
-- 
2.41.0

[Intel-gfx] [PATCH 3/4] drm/i915/dsb: Re-instate DSB for LUT updates

[Ville Syrjala]

From: Ville Syrjälä 

With all the known issues sorted out we can start to use
DSB to load the LUTs.

Reviewed-by: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 4f92fc31059f..40b04aa7d98c 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1895,9 +1895,6 @@ void intel_color_prepare_commit(struct intel_crtc_state 
*crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
 
-   /* FIXME DSB has issues loading LUTs, disable it for now */
-   return;
-
if (!crtc_state->hw.active ||
intel_crtc_needs_modeset(crtc_state))
return;
-- 
2.41.0

[Intel-gfx] [PATCH 4/4] drm/i915: Do state check for color management changes

[Ville Syrjala]

From: Ville Syrjälä 

In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.

Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?

v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up

Reviewed-by: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 303eb68fec11..9b99de3f6640 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -233,6 +233,8 @@ void intel_modeset_verify_crtc(struct intel_atomic_state 
*state,
intel_atomic_get_new_crtc_state(state, crtc);
 
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+   (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
 
-- 
2.41.0

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Nirmoy Das]

Hi Tvrtko,

On 10/9/2023 2:54 PM, Tvrtko Ursulin wrote:



+static long must_wait_woken(struct wait_queue_entry *wq_entry, long 
timeout)

+{
+    /*
+ * This is equivalent to wait_woken() with the exception that
+ * we do not wake up early if the kthread task has been completed.
+ * As we are called from page reclaim in any task context,
+ * we may be invoked from stopped kthreads, but we *must*
+ * complete the wait from the HW .
+ *
+ * A second problem is that since we are called under reclaim
+ * and wait_woken() inspected the thread state, it makes an 
invalid

+ * assumption that all PF_KTHREAD tasks have set_kthread_struct()
+ * called upon them, and will trigger a GPF


As discussed internally, the GPF issue is resolved with 
https://lore.kernel.org/all/20230602212350.535358-1-jstu...@google.com/ 
 



If it means no open coding a slighlt different wait_token() that would 
be a lot better ineed.


Although the question of why a single wait queue is not good enough 
still remains. As I wrote before - give each invalidation a seqno, 
upon receiving the done h2g store the latest seqno in the driver and 
wake up all sleepers. They check the seqno and if their has passed 
exit, otherwise go back to sleep. No xarray needed. Put_pages() 
invalidations are already serialized so no ill-effect and GGTT 
invalidations are, or are not, performance sensitive for some reason?



I think your proposed solution should work as per my understanding 
because we are doing TLB invalidation of all engines and it is 
serialized with gt->tlb.invalidate_lock.


We might need this when we want to make it more fine grain and do vma 
based ranged invalidation for better performance. So I think we should 
try with a single wait queue now.



I don't have an concrete answer yet, may be someone else?


Regards,

Nirmoy



Regards,

Tvrtko





  in is_kthread_should_stop().
+ */
+    do {
+    set_current_state(TASK_UNINTERRUPTIBLE);
+    if (wq_entry->flags & WQ_FLAG_WOKEN)
+    break;
+
+    timeout = schedule_timeout(timeout);
+    } while (timeout);
+    __set_current_state(TASK_RUNNING);
+
+    /* See wait_woken() and woken_wake_function() */
+    smp_store_mb(wq_entry->flags, wq_entry->flags & ~WQ_FLAG_WOKEN);
+
+    return timeout;
+}
+
+static int guc_send_invalidate_tlb(struct intel_guc *guc, enum 
intel_guc_tlb_inval_mode type)



2nd param should be intel_guc_tlb_invalidation_type not 
intel_guc_tlb_inval_mod.


Not sure why didn't CI complained.


Regards,

Nirmoy


+{
+    struct intel_guc_tlb_wait _wq, *wq = &_wq;
+    DEFINE_WAIT_FUNC(wait, woken_wake_function);
+    int err;
+    u32 seqno;
+    u32 action[] = {
+    INTEL_GUC_ACTION_TLB_INVALIDATION,
+    0,
+    REG_FIELD_PREP(INTEL_GUC_TLB_INVAL_TYPE_MASK, type) |
+    REG_FIELD_PREP(INTEL_GUC_TLB_INVAL_MODE_MASK,
+   INTEL_GUC_TLB_INVAL_MODE_HEAVY) |
+    INTEL_GUC_TLB_INVAL_FLUSH_CACHE,
+    };
+    u32 size = ARRAY_SIZE(action);
+
+    init_waitqueue_head(&_wq.wq);
+
+    if (xa_alloc_cyclic_irq(&guc->tlb_lookup, &seqno, wq,
+    xa_limit_32b, &guc->next_seqno,
+    GFP_ATOMIC | __GFP_NOWARN) < 0) {
+    /* Under severe memory pressure? Serialise TLB allocations */
+    xa_lock_irq(&guc->tlb_lookup);
+    wq = xa_load(&guc->tlb_lookup, guc->serial_slot);
+    wait_event_lock_irq(wq->wq,
+    !READ_ONCE(wq->busy),
+    guc->tlb_lookup.xa_lock);
+    /*
+ * Update wq->busy under lock to ensure only one waiter can
+ * issue the TLB invalidation command using the serial slot 
at a
+ * time. The condition is set to true before releasing the 
lock

+ * so that other caller continue to wait until woken up again.
+ */
+    wq->busy = true;
+    xa_unlock_irq(&guc->tlb_lookup);
+
+    seqno = guc->serial_slot;
+    }
+
+    action[1] = seqno;
+
+    add_wait_queue(&wq->wq, &wait);
+
+    /*
+ * This is a critical reclaim path and thus we must loop here:
+ * We cannot block for anything that is on the GPU.
+ */
+    err = intel_guc_send_busy_loop(guc, action, size, 
G2H_LEN_DW_INVALIDATE_TLB, true);

+    if (err)
+    goto out;
+
+    if (!must_wait_woken(&wait, 
intel_guc_ct_expected_delay(&guc->ct))) {

+    guc_err(guc,
+    "TLB invalidation response timed out for seqno %u\n", 
seqno);

+    err = -ETIME;
+    }
+out:
+    remove_wait_queue(&wq->wq, &wait);
+    if (seqno != guc->serial_slot)
+    xa_erase_irq(&guc->tlb_lookup, seqno);
+
+    return err;
+}
+
+/* Full TLB invalidation */
+int intel_guc_invalidate_tlb_engines(struct intel_guc *guc)
+{
+    return guc_send_invalidate_tlb(guc, INTEL_GUC_TLB_INVAL_ENGINES);
+}
+
+/* GuC TLB Invalidation: Invalidate the TLB's of GuC itself. */
+int intel_guc_invalidate_tlb

[Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs

[Stanislav Lisovskiy]

For validation purposes, it might be useful to be able to
force Bigjoiner mode, even if current dotclock/resolution
do not require that.
Lets add such to option to debugfs.

v2: - Apparently intel_dp_need_bigjoiner can't be used, when
  debugfs entry is created so lets just check manually
  the DISPLAY_VER.

Signed-off-by: Stanislav Lisovskiy 
---
 .../drm/i915/display/intel_display_debugfs.c  | 71 +++
 .../drm/i915/display/intel_display_types.h|  2 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +-
 3 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f6d7c4d45fae..c806957cb902 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1399,6 +1399,35 @@ out: 
drm_modeset_unlock(&dev->mode_config.connection_mutex);
return ret;
 }
 
+static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int ret;
+
+   if (!encoder)
+   return -ENODEV;
+
+   ret = 
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   crtc = connector->state->crtc;
+   if (connector->status != connector_status_connected || !crtc) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   seq_printf(m, "Bigjoiner enable: %d\n", intel_dp->force_bigjoiner_en);
+
+out:   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   return ret;
+}
+
 static ssize_t i915_dsc_output_format_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
@@ -1420,12 +1449,39 @@ static ssize_t i915_dsc_output_format_write(struct file 
*file,
return len;
 }
 
+static ssize_t i915_bigjoiner_enable_fops_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   struct drm_connector *connector =
+   ((struct seq_file *)file->private_data)->private;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   int bigjoiner_en = 0;
+   int ret;
+
+   ret = kstrtoint_from_user(ubuf, len, 0, &bigjoiner_en);
+   if (ret < 0)
+   return ret;
+
+   intel_dp->force_bigjoiner_en = bigjoiner_en;
+   *offp += len;
+
+   return len;
+}
+
 static int i915_dsc_output_format_open(struct inode *inode,
   struct file *file)
 {
return single_open(file, i915_dsc_output_format_show, inode->i_private);
 }
 
+static int i915_bigjoiner_enable_open(struct inode *inode,
+ struct file *file)
+{
+   return single_open(file, i915_bigjoiner_enable_show, inode->i_private);
+}
+
 static const struct file_operations i915_dsc_output_format_fops = {
.owner = THIS_MODULE,
.open = i915_dsc_output_format_open,
@@ -1435,6 +1491,15 @@ static const struct file_operations 
i915_dsc_output_format_fops = {
.write = i915_dsc_output_format_write
 };
 
+static const struct file_operations i915_bigjoiner_enable_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_bigjoiner_enable_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_bigjoiner_enable_fops_write
+};
+
 /*
  * Returns the Current CRTC's bpc.
  * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
@@ -1514,6 +1579,12 @@ void intel_connector_debugfs_add(struct intel_connector 
*intel_connector)
connector, &i915_dsc_output_format_fops);
}
 
+   if (DISPLAY_VER(dev_priv) >= 11 &&
+   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+   debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
+   connector, &i915_bigjoiner_enable_fops);
+   }
+
if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8d8b2f8d37a9..ecec8a25838e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm

Re: [Intel-gfx] [PATCH 03/19] drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:11PM +0300, Imre Deak wrote:
> Similarly to eDP and SST-DP connectors read out the DSC capabilities for
> MST connectors as well. Atm these will match the root port's DSC caps
> and only used after a follow-up change enables the decompression for
> each stream separately (vs. the current way of enabling it only globally
> in the first branch device downstream of the root port).
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c |  4 ++--
>  drivers/gpu/drm/i915/display/intel_dp.h |  3 +++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 23 +
>  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c7dd65a27a1b0..6e6b3fe593453 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3467,8 +3467,8 @@ bool intel_dp_get_colorimetry_status(struct intel_dp 
> *intel_dp)
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> -static void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp,
> -   struct intel_connector *connector)
> +void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp,
> +struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 2cf3681bac64a..bd9cb9680b4cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -162,4 +162,7 @@ intel_dp_compute_config_link_bpp_limits(struct intel_dp 
> *intel_dp,
>   bool dsc,
>   struct link_config_limits *limits);
>  
> +void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp,
> +struct intel_connector *connector);
> +
>  #endif /* __INTEL_DP_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 73e3977364632..e01f669d2c8a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1126,6 +1126,21 @@ static int intel_dp_mst_add_properties(struct intel_dp 
> *intel_dp,
>   return drm_connector_set_path_property(connector, pathprop);
>  }
>  
> +static void
> +intel_dp_mst_read_decompression_port_dsc_caps(struct intel_dp *intel_dp,
> +   struct intel_connector *connector)
> +{
> + u8 dpcd_caps[DP_RECEIVER_CAP_SIZE];
> +
> + if (!connector->dp.dsc_decompression_aux)
> + return;
> +
> + if (drm_dp_read_dpcd_caps(connector->dp.dsc_decompression_aux, 
> dpcd_caps) < 0)
> + return;
> +
> + intel_dp_get_dsc_sink_cap(dpcd_caps[DP_DPCD_REV], intel_dp, connector);
> +}
> +
>  static struct drm_connector *intel_dp_add_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_mst_port 
> *port,
>   const char *pathprop)
> @@ -1159,6 +1174,14 @@ static struct drm_connector 
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>  
>   drm_connector_helper_add(connector, 
> &intel_dp_mst_connector_helper_funcs);
>  
> + /*
> +  * TODO: set the AUX for the actual MST port decompressing the stream.
> +  * At the moment the driver only supports enabling this globally in the
> +  * first downstream MST branch, via intel_dp's (root port) AUX.
> +  */
> + intel_connector->dp.dsc_decompression_aux = &intel_dp->aux;
> + intel_dp_mst_read_decompression_port_dsc_caps(intel_dp, 
> intel_connector);
> +
>   for_each_pipe(dev_priv, pipe) {
>   struct drm_encoder *enc =
>   &intel_dp->mst_encoders[pipe]->base.base;
> -- 
> 2.39.2
> 

Re: [Intel-gfx] [PATCH 04/19] drm/i915/dp: Use i915/intel connector local variables in i915_dsc_fec_support_show()

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:12PM +0300, Imre Deak wrote:
> Cahce the i915 specific device and connector pointers in
> i915_dsc_fec_support_show().

Typo cahce/cache. Would say more like "store", but doesn't matter.


Reviewed-by: Stanislav Lisovskiy 

> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index fbe75d47a1654..834a8e50ea4fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1191,8 +1191,8 @@ DEFINE_SHOW_ATTRIBUTE(i915_lpsp_capability);
>  
>  static int i915_dsc_fec_support_show(struct seq_file *m, void *data)
>  {
> - struct drm_connector *connector = m->private;
> - struct drm_device *dev = connector->dev;
> + struct intel_connector *connector = to_intel_connector(m->private);
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   struct drm_crtc *crtc;
>   struct intel_dp *intel_dp;
>   struct drm_modeset_acquire_ctx ctx;
> @@ -1204,7 +1204,7 @@ static int i915_dsc_fec_support_show(struct seq_file 
> *m, void *data)
>  
>   do {
>   try_again = false;
> - ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
> + ret = drm_modeset_lock(&i915->drm.mode_config.connection_mutex,
>  &ctx);
>   if (ret) {
>   if (ret == -EDEADLK && !drm_modeset_backoff(&ctx)) {
> @@ -1213,8 +1213,8 @@ static int i915_dsc_fec_support_show(struct seq_file 
> *m, void *data)
>   }
>   break;
>   }
> - crtc = connector->state->crtc;
> - if (connector->status != connector_status_connected || !crtc) {
> + crtc = connector->base.state->crtc;
> + if (connector->base.status != connector_status_connected || 
> !crtc) {
>   ret = -ENODEV;
>   break;
>   }
> @@ -1229,7 +1229,7 @@ static int i915_dsc_fec_support_show(struct seq_file 
> *m, void *data)
>   } else if (ret) {
>   break;
>   }
> - intel_dp = intel_attached_dp(to_intel_connector(connector));
> + intel_dp = intel_attached_dp(connector);
>   crtc_state = to_intel_crtc_state(crtc->state);
>   seq_printf(m, "DSC_Enabled: %s\n",
>  str_yes_no(crtc_state->dsc.compression_enable));
> -- 
> 2.39.2
> 

Re: [Intel-gfx] [PATCH 19/19] drm/i915/dp: Remove unused DSC caps from intel_dp

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:27PM +0300, Imre Deak wrote:
> The previous patches converted all users of the DSC DPCD caps to look
> these up from the connector, so remove the version stored in intel_dp.
> 
> A follow-up patchset will read out the MST connector specific
> capabilities in intel_dp_add_mst_connector() ->
> intel_dp_mst_read_decompression_port_dsc_caps().
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h |  2 --
>  drivers/gpu/drm/i915/display/intel_dp.c| 14 --
>  2 files changed, 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index d6600079bcf74..65ea37fe8cff3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1725,10 +1725,8 @@ struct intel_dp {
>   u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
>   u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
>   u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> - u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
>   u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
>   u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
> - u8 fec_capable;
>   u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
>   /* source rates */
>   int num_source_rates;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f58940c1baf9c..9d504ce2b54a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3514,15 +3514,6 @@ void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct 
> intel_dp *intel_dp,
>   drm_dbg_kms(&i915->drm, "FEC CAPABILITY: %x\n",
>   connector->dp.fec_capability);
>   }
> -
> - /*
> -  * TODO: remove the following intel_dp copies once all users
> -  * are converted to look up DSC DPCD/FEC capability via the
> -  * connector.
> -  */
> - memcpy(intel_dp->dsc_dpcd, connector->dp.dsc_dpcd,
> -sizeof(intel_dp->dsc_dpcd));
> - intel_dp->fec_capable = connector->dp.fec_capability;
>  }
>  
>  static void intel_edp_mso_mode_fixup(struct intel_connector *connector,
> @@ -5390,11 +5381,6 @@ intel_dp_detect(struct drm_connector *connector,
>  
>   if (status == connector_status_disconnected) {
>   memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
> - /*
> -  * TODO: Remove clearing the DPCD in intel_dp, once all
> -  * user are converted to using the DPCD in connector.
> -  */
> - memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
>   memset(intel_connector->dp.dsc_dpcd, 0, 
> sizeof(intel_connector->dp.dsc_dpcd));
>  
>   if (intel_dp->is_mst) {
> -- 
> 2.39.2
> 

Re: [Intel-gfx] [PATCH 05/19] drm/i915/dp: Use connector DSC DPCD in i915_dsc_fec_support_show()

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:13PM +0300, Imre Deak wrote:
> Use the connector's DSC DPCD capabilities in i915_dsc_fec_support_show()
> instead of the version stored in the encoder. Atm the two are identical,
> but a follow-up patch will store the (MST) connector specific version
> in the connector.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 834a8e50ea4fb..2836826f8c05f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1234,19 +1234,19 @@ static int i915_dsc_fec_support_show(struct seq_file 
> *m, void *data)
>   seq_printf(m, "DSC_Enabled: %s\n",
>  str_yes_no(crtc_state->dsc.compression_enable));
>   seq_printf(m, "DSC_Sink_Support: %s\n",
> -
> str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> +
> str_yes_no(drm_dp_sink_supports_dsc(connector->dp.dsc_dpcd)));
>   seq_printf(m, "DSC_Output_Format_Sink_Support: RGB: %s 
> YCBCR420: %s YCBCR444: %s\n",
> -
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(connector->dp.dsc_dpcd,
> 
> DP_DSC_RGB)),
> -
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(connector->dp.dsc_dpcd,
> 
> DP_DSC_YCbCr420_Native)),
> -
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(connector->dp.dsc_dpcd,
> 
> DP_DSC_YCbCr444)));
>   seq_printf(m, "Force_DSC_Enable: %s\n",
>  str_yes_no(intel_dp->force_dsc_en));
>   if (!intel_dp_is_edp(intel_dp))
>   seq_printf(m, "FEC_Sink_Support: %s\n",
> -
> str_yes_no(drm_dp_sink_supports_fec(intel_dp->fec_capable)));
> +
> str_yes_no(drm_dp_sink_supports_fec(connector->dp.fec_capability)));
>   } while (try_again);
>  
>   drm_modeset_drop_locks(&ctx);
> -- 
> 2.39.2
> 

[Intel-gfx] [PATCH v2] drm/i915/lnl: Remove watchdog timers for PSR

[Mika Kahola]

Currently we are not using watchdog timers for PSR/PSR2
with Lunarlake. The patch removes the use of these timers
from the driver code.

BSpec: 69895

v2: Reword commit message (Ville)
Drop HPD mask from LNL (Ville)
Revise masking logic (Jouni)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 850b11f20285..abdafd04d8e3 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -676,7 +676,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
 
val |= EDP_PSR_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
 
-   val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
+   if (DISPLAY_VER(dev_priv) < 20)
+   val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
+
if (IS_HASWELL(dev_priv))
val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
 
@@ -1399,9 +1401,11 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 * can rely on frontbuffer tracking.
 */
mask = EDP_PSR_DEBUG_MASK_MEMUP |
-  EDP_PSR_DEBUG_MASK_HPD |
-  EDP_PSR_DEBUG_MASK_LPSP |
-  EDP_PSR_DEBUG_MASK_MAX_SLEEP;
+  EDP_PSR_DEBUG_MASK_LPSP;
+
+   if (DISPLAY_VER(dev_priv) < 20)
+   mask |= EDP_PSR_DEBUG_MASK_HPD |
+   EDP_PSR_DEBUG_MASK_MAX_SLEEP;
 
/*
 * No separate pipe reg write mask on hsw/bdw, so have to unmask all
-- 
2.34.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Define and use GuC and CTB TLB invalidation routines (rev3)
URL   : https://patchwork.freedesktop.org/series/124744/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13728_full -> Patchwork_124744v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_124744v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_124744v3_full, please notify your bug team 
(lgci.bug.fil...@intel.com) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_124744v3_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_capture@pi@ccs0:
- shard-mtlp: [PASS][1] -> [DMESG-WARN][2] +5 other tests dmesg-warn
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/shard-mtlp-5/igt@gem_exec_capture@p...@ccs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-mtlp-1/igt@gem_exec_capture@p...@ccs0.html

  * igt@kms_flip@dpms-vs-vblank-race@c-hdmi-a2:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/shard-glk3/igt@kms_flip@dpms-vs-vblank-r...@c-hdmi-a2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-glk5/igt@kms_flip@dpms-vs-vblank-r...@c-hdmi-a2.html

  * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
- shard-mtlp: [PASS][5] -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/shard-mtlp-3/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-mtlp-2/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html

  
Known issues


  Here are the changes found in Patchwork_124744v3_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@drm_fdinfo@busy-idle@bcs0:
- shard-dg1:  NOTRUN -> [SKIP][7] ([i915#8414]) +4 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg1-19/igt@drm_fdinfo@busy-i...@bcs0.html

  * igt@drm_fdinfo@most-busy-check-all@rcs0:
- shard-rkl:  [PASS][8] -> [FAIL][9] ([i915#7742])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html

  * igt@drm_fdinfo@most-busy-idle-check-all@vecs1:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#8414]) +21 other tests 
skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg2-3/igt@drm_fdinfo@most-busy-idle-check-...@vecs1.html

  * igt@drm_fdinfo@virtual-busy-idle-all:
- shard-mtlp: NOTRUN -> [SKIP][11] ([i915#8414])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-mtlp-5/igt@drm_fdi...@virtual-busy-idle-all.html

  * igt@gem_ccs@suspend-resume@linear-compressed-compfmt0-smem-lmem0:
- shard-dg2:  NOTRUN -> [INCOMPLETE][12] ([i915#7297])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg2-10/igt@gem_ccs@suspend-res...@linear-compressed-compfmt0-smem-lmem0.html

  * igt@gem_close_race@multigpu-basic-threads:
- shard-dg2:  NOTRUN -> [SKIP][13] ([i915#7697]) +1 other test skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg2-1/igt@gem_close_r...@multigpu-basic-threads.html

  * igt@gem_create@create-ext-set-pat:
- shard-dg1:  NOTRUN -> [SKIP][14] ([i915#8562])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg1-19/igt@gem_cre...@create-ext-set-pat.html

  * igt@gem_ctx_isolation@preservation-s3@vecs1:
- shard-dg2:  [PASS][15] -> [FAIL][16] ([fdo#103375]) +1 other test 
fail
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13728/shard-dg2-11/igt@gem_ctx_isolation@preservation...@vecs1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg2-11/igt@gem_ctx_isolation@preservation...@vecs1.html

  * igt@gem_ctx_persistence@engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1099])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-snb2/igt@gem_ctx_persiste...@engines-persistence.html

  * igt@gem_ctx_persistence@heartbeat-hang:
- shard-dg2:  NOTRUN -> [SKIP][18] ([i915#8555]) +1 other test skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124744v3/shard-dg2-1/igt@gem_ctx_persiste...@heartbeat-

Re: [Intel-gfx] [PATCH 01/19] drm/i915/dp: Sanitize DPCD revision check in intel_dp_get_dsc_sink_cap()

[Ville Syrjälä]

On Fri, Oct 06, 2023 at 04:37:09PM +0300, Imre Deak wrote:
> Check only the eDP or the DP specific DPCD revision depending on the
> sink type. Pass the corresponding revision to the function, which allows
> getting the DSC caps of a branch device (in an MST topology, which has
> its own DPCD and so DPCD revision).
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0ef7cb8134b66..1bd11f9e308c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3467,7 +3467,7 @@ bool intel_dp_get_colorimetry_status(struct intel_dp 
> *intel_dp)
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> -static void intel_dp_get_dsc_sink_cap(struct intel_dp *intel_dp)
> +static void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>  
> @@ -3481,8 +3481,8 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
> *intel_dp)
>   intel_dp->fec_capable = 0;
>  
>   /* Cache the DSC DPCD if eDP or DP rev >= 1.4 */
> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x14 ||
> - intel_dp->edp_dpcd[0] >= DP_EDP_14) {
> + if ((intel_dp_is_edp(intel_dp) && dpcd_rev >= DP_EDP_14) ||
> + (!intel_dp_is_edp(intel_dp) && dpcd_rev >= 0x14)) {

This is horribly confusing. DPCD_REV and EDP_DPCD_REV are not the same
thing.

>   if (drm_dp_dpcd_read(&intel_dp->aux, DP_DSC_SUPPORT,
>intel_dp->dsc_dpcd,
>sizeof(intel_dp->dsc_dpcd)) < 0)
> @@ -3674,7 +3674,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  
>   /* Read the eDP DSC DPCD registers */
>   if (HAS_DSC(dev_priv))
> - intel_dp_get_dsc_sink_cap(intel_dp);
> + intel_dp_get_dsc_sink_cap(intel_dp->edp_dpcd[0],
> +   intel_dp);
>  
>   /*
>* If needed, program our source OUI so we can make various 
> Intel-specific AUX services
> @@ -5384,7 +5385,8 @@ intel_dp_detect(struct drm_connector *connector,
>  
>   /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
>   if (HAS_DSC(dev_priv))
> - intel_dp_get_dsc_sink_cap(intel_dp);
> + intel_dp_get_dsc_sink_cap(intel_dp->dpcd[DP_DPCD_REV],
> +   intel_dp);
>  
>   intel_dp_configure_mst(intel_dp);
>  
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v2] drm/i915/lnl: Remove watchdog timers for PSR

[Ville Syrjälä]

On Mon, Oct 09, 2023 at 05:13:03PM +0300, Mika Kahola wrote:
> Currently we are not using watchdog timers for PSR/PSR2
> with Lunarlake. The patch removes the use of these timers
> from the driver code.

That still doesn't seem to say that the timers were removed
from the hardware. Or at least I can't parse it that way.

> 
> BSpec: 69895
> 
> v2: Reword commit message (Ville)
> Drop HPD mask from LNL (Ville)

That should probably be a separate patch since it has nothing to do
with what the commit message is saying.

> Revise masking logic (Jouni)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 850b11f20285..abdafd04d8e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -676,7 +676,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
>  
>   val |= EDP_PSR_IDLE_FRAMES(psr_compute_idle_frames(intel_dp));
>  
> - val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
> + if (DISPLAY_VER(dev_priv) < 20)
> + val |= EDP_PSR_MAX_SLEEP_TIME(max_sleep_time);
> +
>   if (IS_HASWELL(dev_priv))
>   val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>  
> @@ -1399,9 +1401,11 @@ static void intel_psr_enable_source(struct intel_dp 
> *intel_dp,
>* can rely on frontbuffer tracking.
>*/
>   mask = EDP_PSR_DEBUG_MASK_MEMUP |
> -EDP_PSR_DEBUG_MASK_HPD |
> -EDP_PSR_DEBUG_MASK_LPSP |
> -EDP_PSR_DEBUG_MASK_MAX_SLEEP;
> +EDP_PSR_DEBUG_MASK_LPSP;
> +
> + if (DISPLAY_VER(dev_priv) < 20)
> + mask |= EDP_PSR_DEBUG_MASK_HPD |
> + EDP_PSR_DEBUG_MASK_MAX_SLEEP;
>  
>   /*
>* No separate pipe reg write mask on hsw/bdw, so have to unmask all
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH] drm/i915: Fix VLV color state readout

[Ville Syrjala]

From: Ville Syrjälä 

VLV was missed when the color.get_config() hook was added.
Remedy that.

Not really sure what the final plan here was since a bunch of
color related readout was left in intel_display.c anyway,
but that's for anothr day to figure out...

Cc: Jani Nikula 
Fixes: 9af09dfcdfa1 ("drm/i915/color: move pre-SKL gamma and CSC enable read to 
intel_color")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 4f92fc31059f..2a2a163ea652 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -3702,6 +3702,7 @@ static const struct intel_color_funcs vlv_color_funcs = {
.read_luts = i965_read_luts,
.lut_equal = i965_lut_equal,
.read_csc = vlv_read_csc,
+   .get_config = i9xx_get_config,
 };
 
 static const struct intel_color_funcs i965_color_funcs = {
-- 
2.41.0

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Cavitt, Jonathan]

-Original Message-
From: Tvrtko Ursulin  
Sent: Monday, October 9, 2023 1:57 AM
To: Cavitt, Jonathan ; 
intel-gfx@lists.freedesktop.org
Cc: Dutt, Sudeep ; Chang, Yu bruce 
; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind 
; Yang, Fei ; Shyti, Andi 
; Harrison, John C ; Das, 
Nirmoy ; Krzysztofik, Janusz 
; Roper, Matthew D ; 
jani.nik...@linux.intel.com
Subject: Re: [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB 
invalidation routines
> 
> 
> On 06/10/2023 19:20, Jonathan Cavitt wrote:
> > From: Prathap Kumar Valsan 
> > 
> > The GuC firmware had defined the interface for Translation Look-Aside
> > Buffer (TLB) invalidation.  We should use this interface when
> > invalidating the engine and GuC TLBs.
> > Add additional functionality to intel_gt_invalidate_tlb, invalidating
> > the GuC TLBs and falling back to GT invalidation when the GuC is
> > disabled.
> > The invalidation is done by sending a request directly to the GuC
> > tlb_lookup that invalidates the table.  The invalidation is submitted as
> > a wait request and is performed in the CT event handler.  This means we
> > cannot perform this TLB invalidation path if the CT is not enabled.
> > If the request isn't fulfilled in two seconds, this would constitute
> > an error in the invalidation as that would constitute either a lost
> > request or a severe GuC overload.
> > 
> > With this new invalidation routine, we can perform GuC-based GGTT
> > invalidations.  GuC-based GGTT invalidation is incompatible with
> > MMIO invalidation so we should not perform MMIO invalidation when
> > GuC-based GGTT invalidation is expected.
> > 
> > Purpose of xarray:
> > The tlb_lookup table is allocated as an xarray because the set of
> > pending TLB invalidations may have no upper bound.  The consequence of
> > this is that all actions interfacing with this table need to use the
> > xarray functions, such as xa_alloc_cyclic_irq for array insertion.
> > 
> > Purpose of must_wait_woken:
> > Our wait for the G2H ack for the completion of a TLB invalidation is
> > mandatory; we must wait for the HW to confirm that the physical
> > addresses are no longer accessible before we return those to the system.
> > 
> > On switching to using the wait_woken() convenience routine, we
> > introduced ourselves to an issue where wait_woken() may complete early
> > under a kthread that is stopped. Since we send a TLB invalidation when
> > we try to release pages from the shrinker, we can be called from any
> > process; including kthreads.
> > 
> > Using wait_woken() from any process context causes another issue. The
> > use of is_kthread_should_stop() assumes that any task with PF_KTHREAD
> > set was made by kthread_create() and has called set_kthread_struct().
> > This is not true for the raw kernel_thread():
> 
> This explanation misses the main point of my ask - which is to explain 
> why a simpler scheme isn't sufficient. Simpler scheme aka not needed the 
> xarray or any flavour of wait_token().
> 
> In other words it is obvious we have to wait for the invalidation ack, 
> but not obvious why we need a complicated scheme.


Okay.  I'll remove these chunks and explain that the complexity is required
for range-based TLB invalidaitons, which will land upstream eventually.


> 
> > BUG: kernel NULL pointer dereference, address: 
> > [ 3089.759660] Call Trace:
> > [ 3089.762110]  wait_woken+0x4f/0x80
> > [ 3089.765496]  guc_send_invalidate_tlb+0x1fe/0x310 [i915]
> > [ 3089.770725]  ? syscall_return_via_sysret+0xf/0x7f
> > [ 3089.775426]  ? do_wait_intr_irq+0xb0/0xb0
> > [ 3089.779430]  ? __switch_to_asm+0x40/0x70
> > [ 3089.783349]  ? __switch_to_asm+0x34/0x70
> > [ 3089.787273]  ? __switch_to+0x7a/0x3e0
> > [ 3089.790930]  ? __switch_to_asm+0x34/0x70
> > [ 3089.794883]  intel_guc_invalidate_tlb_full+0x92/0xa0 [i915]
> > [ 3089.800487]  intel_invalidate_tlb_full+0x94/0x190 [i915]
> > [ 3089.805824]  intel_invalidate_tlb_full_sync+0x1b/0x30 [i915]
> > [ 3089.811508]  __i915_gem_object_unset_pages+0x138/0x150 [i915]
> > [ 3089.817279]  __i915_gem_object_put_pages+0x25/0x90 [i915]
> > [ 3089.822706]  i915_gem_shrink+0x532/0x7e0 [i915]
> > [ 3089.827264]  i915_gem_shrinker_scan+0x3d/0xd0 [i915]
> > [ 3089.832230]  do_shrink_slab+0x12c/0x2a0
> > [ 3089.836065]  shrink_slab+0xad/0x2b0
> > [ 3089.839550]  shrink_node+0xcc/0x410
> > [ 3089.843035]  do_try_to_free_pages+0xc6/0x380
> > [ 3089.847306]  try_to_free_pages+0xec/0x1c0
> > [ 3089.851312]  __alloc_pages_slowpath+0x3ad/0xd10
> > [ 3089.855845]  ? update_sd_lb_stats+0x636/0x710
> > [ 3089.860204]  __alloc_pages_nodemask+0x2d5/0x310
> > [ 3089.864737]  new_slab+0x265/0xa80
> > [ 3089.868053]  ___slab_alloc+0y_to_free_pages+0xec/0x1c0
> > [ 3089.871798]  ? copy_process+0x1e5/0x1a00
> > [ 3089.875717]  ? load_balance+0x165/0xb20
> > [ 3089.879555]  __slab_alloc+0x1c/0x30
> > [ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
> > [ 3089.887397]  ? copy_process+0x1e5/0x1a00
> > [ 3089.891314]  copy_process+

Re: [Intel-gfx] [PATCH] drm/i915: Fix VLV color state readout

[Jani Nikula]

On Mon, 09 Oct 2023, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> VLV was missed when the color.get_config() hook was added.
> Remedy that.

Oops, how did I manage that?! Thanks for the fix,

Reviewed-by: Jani Nikula 

> Not really sure what the final plan here was since a bunch of
> color related readout was left in intel_display.c anyway,
> but that's for anothr day to figure out...

I guess I just wanted to start somewhere, and the cutoff was mostly by
the registers where the data is read from, e.g. ->gamma_mode and
->wgc_enable coming from TRANSCONF I left in place.

BR,
Jani.

>
> Cc: Jani Nikula 
> Fixes: 9af09dfcdfa1 ("drm/i915/color: move pre-SKL gamma and CSC enable read 
> to intel_color")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 4f92fc31059f..2a2a163ea652 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -3702,6 +3702,7 @@ static const struct intel_color_funcs vlv_color_funcs = 
> {
>   .read_luts = i965_read_luts,
>   .lut_equal = i965_lut_equal,
>   .read_csc = vlv_read_csc,
> + .get_config = i9xx_get_config,
>  };
>  
>  static const struct intel_color_funcs i965_color_funcs = {

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH v2] drm/i915/uapi: fix doc typos

[Rodrigo Vivi]

On Sun, Oct 08, 2023 at 02:49:40PM -0700, Randy Dunlap wrote:
> Correct typo of "its".
> Add commas for clarity.
> Capitalize L3.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Ville Syrjälä 
> Cc: dri-de...@lists.freedesktop.org

Reviewed-by: Rodrigo Vivi 

and pushed, thanks for the patch

> ---
> v2: capitalize L3, add another comma for clarity (Ville)
> 
>  include/uapi/drm/i915_drm.h |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff -- a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -38,13 +38,13 @@ extern "C" {
>   */
>  
>  /**
> - * DOC: uevents generated by i915 on it's device node
> + * DOC: uevents generated by i915 on its device node
>   *
>   * I915_L3_PARITY_UEVENT - Generated when the driver receives a parity 
> mismatch
> - *   event from the gpu l3 cache. Additional information supplied is ROW,
> + *   event from the GPU L3 cache. Additional information supplied is ROW,
>   *   BANK, SUBBANK, SLICE of the affected cacheline. Userspace should keep
> - *   track of these events and if a specific cache-line seems to have a
> - *   persistent error remap it with the l3 remapping tool supplied in
> + *   track of these events, and if a specific cache-line seems to have a
> + *   persistent error, remap it with the L3 remapping tool supplied in
>   *   intel-gpu-tools.  The value supplied with the event is always 1.
>   *
>   * I915_ERROR_UEVENT - Generated upon error detection, currently only via

Re: [Intel-gfx] [PATCH 1/2] drm/i915: drop -Wall and related disables from cflags as redundant

[Nathan Chancellor]

On Sun, Oct 08, 2023 at 12:28:46AM +0900, Masahiro Yamada wrote:
> On Fri, Oct 6, 2023 at 9:35 PM Jani Nikula  wrote:
> >
> > The kernel top level Makefile, and recently scripts/Makefile.extrawarn,
> > have included -Wall, and the disables -Wno-format-security and
> > $(call cc-disable-warning,frame-address,) for a very long time. They're
> > redundant in our local subdir-ccflags-y and can be dropped.
> >
> > Cc: Arnd Bergmann 
> > Cc: Nick Desaulniers 
> > Cc: Nathan Chancellor 
> > Cc: Masahiro Yamada 
> > Signed-off-by: Jani Nikula 
> 
> 
> I made a similar suggestion in the past
> https://lore.kernel.org/dri-devel/20190515043753.9853-1-yamada.masah...@socionext.com/
> 
> So, I am glad that Intel has decided to de-duplicate the flags.
> 
> 
> 
> I think you can drop more flags.
> 
> For example,
> 
>  subdir-ccflags-y += -Wno-sign-compare
> 
> 
> It is set by scripts/Makefile.extrawarn
> unless W=3 is passed.
> 
> 
> If W=3 is set by a user, -Wsign-compare should be warned
> as it is the user's request.
> 
> 
> drivers/gpu/drm/i915/Makefile negates W=3.
> There is no good reason to do so.
> 
> 
> Same applied to
> 
> 
> subdir-ccflags-y += -Wno-shift-negative-value

As I point out in my review of the second patch [1], I am not sure these
should be dropped because -Wextra turns these warnings back on, at least
for clang according to this build report [2] and my own testing, so they
need to be disabled again.

[1]: https://lore.kernel.org/20231006174550.GC3359308@dev-arch.thelio-3990X/
[2]: https://lore.kernel.org/202310070011.fji48ibk-...@intel.com/

Cheers,
Nathan.

Re: [Intel-gfx] [PATCH] drm/print: Add drm_dbg_ratelimited

[Andi Shyti]

Hi,

> From: Nirmoy Das 
> 
> Add a function for ratelimitted debug print.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Reviewed-by: Matthew Auld 
> Reviewed-by: Andi Shyti 
> Signed-off-by: Nirmoy Das 
> Signed-off-by: Andi Shyti 

Just a kind reminder!

This is the second time this patch has been sent and we have seen
some potential use of the drm_dbg_ratelimited().

Any feedback?

Thanks,
Andi

Re: [Intel-gfx] [PATCH i-g-t v2 07/11] lib/ktap: Drop workaround for missing top level KTAP headers

[Kamil Konieczny]

Hi Janusz,
On 2023-10-09 at 14:27:58 +0200, Janusz Krzysztofik wrote:
> A workaround was implemented in IGT KTAP parser so it could accepted KTAP
> reports with missing top level KTAP version and test suite plan headers.
> Since kernel side commit c95e7c05c139 ("kunit: Report the count of test
> suites in a module"), included in the mainline kernel since v6.6-rc1, has
> fixed that issue, that workaround is no longer needed.  Drop it.
> 
> Signed-off-by: Janusz Krzysztofik 

Reviewed-by: Kamil Konieczny 

> ---
>  lib/igt_ktap.c  | 12 
>  lib/tests/igt_ktap_parser.c |  3 +--
>  2 files changed, 1 insertion(+), 14 deletions(-)
> 
> diff --git a/lib/igt_ktap.c b/lib/igt_ktap.c
> index 53a6c63288..7c52ba11ed 100644
> --- a/lib/igt_ktap.c
> +++ b/lib/igt_ktap.c
> @@ -84,18 +84,6 @@ int igt_ktap_parse(const char *buf, struct 
> igt_ktap_results *ktap)
>  igt_debug_on(sscanf(buf,
>  "%*1[ ]%*1[ ]%*1[ ]%*1[ ]KTAP%*[ 
> ]version%*[ ]%u %n",
>  &n, &len) == 1 && len == strlen(buf))) {
> - /*
> -  * TODO: drop the following workaround as soon as
> -  * kernel side issue of missing lines with top level
> -  * KTAP version and test suite plan is fixed.
> -  */
> - if (ktap->expect == KTAP_START) {
> - ktap->suite_count = 1;
> - ktap->suite_last = 0;
> - ktap->suite_name = NULL;
> - ktap->expect = SUITE_START;
> - }
> -
>   if (igt_debug_on(ktap->expect != SUITE_START))
>   return -EPROTO;
>  
> diff --git a/lib/tests/igt_ktap_parser.c b/lib/tests/igt_ktap_parser.c
> index 6357bdf6a5..476e14092f 100644
> --- a/lib/tests/igt_ktap_parser.c
> +++ b/lib/tests/igt_ktap_parser.c
> @@ -190,8 +190,7 @@ static void ktap_top_version(void)
>  
>   ktap = igt_ktap_alloc(&results);
>   igt_require(ktap);
> - /* TODO: change to -EPROTO as soon as related workaround is dropped */
> - igt_assert_eq(igt_ktap_parse("KTAP version 1\n", ktap), 
> -EINPROGRESS);
> + igt_assert_eq(igt_ktap_parse("KTAP version 1\n", ktap), -EPROTO);
>   igt_ktap_free(ktap);
>  
>   ktap = igt_ktap_alloc(&results);
> -- 
> 2.42.0
> 

Re: [Intel-gfx] [PATCH i-g-t v2 11/11] lib/kunit: Execute kunit test cases only when needed

[Kamil Konieczny]

Hi Janusz,
On 2023-10-09 at 14:28:02 +0200, Janusz Krzysztofik wrote:
> IGT user interface allows to request execution of only those dynamic sub-
> subtests that match a user provided name pattern.  If the user pattern
> doesn't match any names of test cases provided by a kunit test module used
> with the subtest to be run then no results from any dynamic sub-subtests
> will be reported.  Since we already know the list of test cases provided
> by the kunit test module, there is no need to load that module to execute
> them unless the user pattern matches at least one of those test cases.
> 
> Don't load the kunit test module in execute mode before entering the loop
> of dynamic sub-subtests, and do that only from the first actually executed
> dynamic sub-subtest.
> 
> v2: Always pass last result to next dynamic sub-subtest, fetch first
> result right after loading the kunit test module for execution.
> 
> Signed-off-by: Janusz Krzysztofik 

Reviewed-by: Kamil Konieczny 

> ---
>  lib/igt_kmod.c | 66 ++
>  1 file changed, 35 insertions(+), 31 deletions(-)
> 
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index 150fe49803..69915adc40 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -981,33 +981,37 @@ static void __igt_kunit(struct igt_ktest *tst,
>  
>   igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
>  
> - igt_skip_on(pthread_mutexattr_init(&attr));
> - igt_skip_on(pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST));
> - igt_skip_on(pthread_mutex_init(&modprobe.lock, &attr));
> -
>   ktap = igt_ktap_alloc(&results);
>   igt_require(ktap);
>  
> - if (igt_debug_on(pthread_create(&modprobe.thread, NULL,
> - modprobe_task, &modprobe))) {
> - igt_ktap_free(ktap);
> - igt_skip("Failed to create a modprobe thread\n");
> - }
> -
>   igt_list_for_each_entry(t, tests, link) {
>   igt_dynamic_f("%s%s%s",
> strcmp(t->suite_name, name) ?  t->suite_name : "",
> strcmp(t->suite_name, name) ? "-" : "",
> t->case_name) {
>  
> - if (igt_list_empty(&results)) {
> + if (!modprobe.thread) {
> + igt_assert_eq(pthread_mutexattr_init(&attr), 0);
> + igt_assert_eq(pthread_mutexattr_setrobust(&attr,
> +   PTHREAD_MUTEX_ROBUST),
> +   0);
> + igt_assert_eq(pthread_mutex_init(&modprobe.lock,
> +  &attr), 0);
> +
> + modprobe.err = pthread_create(&modprobe.thread,
> +   NULL,
> +   modprobe_task,
> +   &modprobe);
> + igt_assert_eq(modprobe.err, 0);
> +
> + igt_assert(igt_list_empty(&results));
>   igt_assert_eq(ret, -EINPROGRESS);
>   ret = kunit_kmsg_result_get(&results, &modprobe,
>   tst->kmsg, ktap);
>   igt_fail_on(igt_list_empty(&results));
> - }
>  
> - r = igt_list_first_entry(&results, r, link);
> + r = igt_list_first_entry(&results, r, link);
> + }
>  
>   while (igt_debug_on_f(strcmp(r->suite_name, 
> t->suite_name),
> "suite_name expected: %s, got: 
> %s\n",
> @@ -1079,30 +1083,30 @@ static void __igt_kunit(struct igt_ktest *tst,
>   igt_assert_eq(igt_kernel_tainted(&taints), 0);
>   }
>  
> - kunit_result_free(&r, &suite_name, &case_name);
> -
>   if (igt_debug_on(ret != -EINPROGRESS))
>   break;
>   }
>  
>   kunit_results_free(&results, &suite_name, &case_name);
>  
> - switch (pthread_mutex_lock(&modprobe.lock)) {
> - case 0:
> - igt_debug_on(pthread_cancel(modprobe.thread));
> - igt_debug_on(pthread_mutex_unlock(&modprobe.lock));
> - igt_debug_on(pthread_join(modprobe.thread, NULL));
> - break;
> - case EOWNERDEAD:
> - /* leave the mutex unrecoverable */
> - igt_debug_on(pthread_mutex_unlock(&modprobe.lock));
> - break;
> - case ENOTRECOVERABLE:
> - break;
> - default:
> - igt_debug("pthread_mutex_lock() failed\n");
> - igt_debug_on(pthread_join(modprobe.thread, NULL));
> - break;
> + if (modprobe.thread) {
> +

Re: [Intel-gfx] [PATCH i-g-t v2 08/11] lib/kunit: Provide all results cleanup helper

[Kamil Konieczny]

Hi Janusz,
On 2023-10-09 at 14:27:59 +0200, Janusz Krzysztofik wrote:
> Planned changes require a couple of loops around kunit_result_free().
> Since we already have such loop, move it into a helper in preparation for
> future uses.
> 
> Signed-off-by: Janusz Krzysztofik 

Reviewed-by: Kamil Konieczny 

> ---
>  lib/igt_kmod.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index 387efbb59f..fed0855c84 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -885,13 +885,25 @@ static void kunit_result_free(struct igt_ktap_result 
> **r,
>   *r = NULL;
>  }
>  
> +static void kunit_results_free(struct igt_list_head *results,
> +char **suite_name, char **case_name)
> +{
> + struct igt_ktap_result *r, *rn;
> +
> + igt_list_for_each_entry_safe(r, rn, results, link)
> + kunit_result_free(&r, suite_name, case_name);
> +
> + free(*case_name);
> + free(*suite_name);
> +}
> +
>  static void
>  __igt_kunit(struct igt_ktest *tst, const char *name, const char *opts)
>  {
>   struct modprobe_data modprobe = { pthread_self(), tst->kmod, opts, 0, };
>   char *suite_name = NULL, *case_name = NULL;
> - struct igt_ktap_result *r, *rn;
>   struct igt_ktap_results *ktap;
> + struct igt_ktap_result *r;
>   pthread_mutexattr_t attr;
>   IGT_LIST_HEAD(results);
>   unsigned long taints;
> @@ -997,11 +1009,7 @@ __igt_kunit(struct igt_ktest *tst, const char *name, 
> const char *opts)
>  
>   } while (ret == -EINPROGRESS);
>  
> - igt_list_for_each_entry_safe(r, rn, &results, link)
> - kunit_result_free(&r, &suite_name, &case_name);
> -
> - free(case_name);
> - free(suite_name);
> + kunit_results_free(&results, &suite_name, &case_name);
>  
>   switch (pthread_mutex_lock(&modprobe.lock)) {
>   case 0:
> -- 
> 2.42.0
> 

Re: [Intel-gfx] [PATCH i-g-t v2 09/11] lib/kunit: Prepare for KTAP parsing after modprobe completed

[Kamil Konieczny]

Hi Janusz,
On 2023-10-09 at 14:28:00 +0200, Janusz Krzysztofik wrote:
> We are going to add support for reading a list of kunit test cases
> provided by a kunit test module prior to executing those test cases.  That
- ^^
Two spaces, use only one.

> will be done by first loading kunit modules in list only mode, then
> reading the list from /dev/kmsg with our KTAP parser.  Since that parsing
---^^
Same here.

> will be performed after the kunit test module is successfully loaded and
> there will be no concurrently running modprobe thread, we need to make
> synchronization of reads from /dev/kmsg with potential errors modprobe
> thread optional.
> 
> Signed-off-by: Janusz Krzysztofik 

Reviewed-by: Kamil Konieczny 

> ---
>  lib/igt_kmod.c | 50 ++
>  1 file changed, 26 insertions(+), 24 deletions(-)
> 
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index fed0855c84..ed41aa1235 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -802,34 +802,36 @@ static int kunit_kmsg_result_get(struct igt_list_head 
> *results,
>   if (igt_debug_on(igt_kernel_tainted(&taints)))
>   return -ENOTRECOVERABLE;
>  
> - err = igt_debug_on(sigaction(SIGCHLD, &sigchld, saved));
> - if (err == -1)
> - return -errno;
> - else if (unlikely(err))
> - return err;
> -
> - err = pthread_mutex_lock(&modprobe->lock);
> - switch (err) {
> - case EOWNERDEAD:
> - /* leave the mutex unrecoverable */
> - igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
> - __attribute__ ((fallthrough));
> - case ENOTRECOVERABLE:
> - igt_debug_on(sigaction(SIGCHLD, saved, NULL));
> - if (igt_debug_on(modprobe->err))
> - return modprobe->err;
> - break;
> - case 0:
> - break;
> - default:
> - igt_debug("pthread_mutex_lock() error: %d\n", err);
> - igt_debug_on(sigaction(SIGCHLD, saved, NULL));
> - return -err;
> + if (modprobe) {
> + err = igt_debug_on(sigaction(SIGCHLD, &sigchld, saved));
> + if (err == -1)
> + return -errno;
> + else if (unlikely(err))
> + return err;
> +
> + err = pthread_mutex_lock(&modprobe->lock);
> + switch (err) {
> + case EOWNERDEAD:
> + /* leave the mutex unrecoverable */
> + 
> igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
> + __attribute__ ((fallthrough));
> + case ENOTRECOVERABLE:
> + igt_debug_on(sigaction(SIGCHLD, saved, NULL));
> + if (igt_debug_on(modprobe->err))
> + return modprobe->err;
> + break;
> + case 0:
> + break;
> + default:
> + igt_debug("pthread_mutex_lock() error: %d\n", 
> err);
> + igt_debug_on(sigaction(SIGCHLD, saved, NULL));
> + return -err;
> + }
>   }
>  
>   ret = read(fd, record, BUF_LEN);
>  
> - if (!err) {
> + if (modprobe && !err) {
>   igt_debug_on(pthread_mutex_unlock(&modprobe->lock));
>   igt_debug_on(sigaction(SIGCHLD, saved, NULL));
>   }
> -- 
> 2.42.0
> 

[Intel-gfx] [PATCH v9 2/7] drm/i915/guc: Add CT size delay helper

[Jonathan Cavitt]

Add a helper function to the GuC CT buffer that reports the expected
time to process all outstanding requests.  As of now, there is no
functionality to check number of requests in the buffer, so the helper
function just reports 2 seconds, or 1ms per request up to the maximum
number of requests the CT buffer can store.

Suggested-by: John Harrison 
Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 58e42901ff498..36afc1ce9fabd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -120,6 +120,19 @@ static inline bool intel_guc_ct_enabled(struct 
intel_guc_ct *ct)
return ct->enabled;
 }
 
+/*
+ * GuC has a timeout of 1ms for a TLB invalidation response from GAM.  On a
+ * timeout GuC drops the request and has no mechanism to notify the host about
+ * the timeout.  There is also no mechanism for determining the number of
+ * outstanding requests in the CT buffer.  Ergo, keep a larger timeout that 
accounts
+ * for this individual timeout and the max number of outstanding requests that
+ * can be queued in CT buffer.
+ */
+static inline long intel_guc_ct_expected_delay(struct intel_guc_ct *ct)
+{
+   return HZ * 2;
+}
+
 #define INTEL_GUC_CT_SEND_NB   BIT(31)
 #define INTEL_GUC_CT_SEND_G2H_DW_SHIFT 0
 #define INTEL_GUC_CT_SEND_G2H_DW_MASK  (0xff << INTEL_GUC_CT_SEND_G2H_DW_SHIFT)
-- 
2.25.1

[Intel-gfx] [PATCH v9 1/7] drm/i915: Add GuC TLB Invalidation device info flags

[Jonathan Cavitt]

Add device info flags for if GuC TLB Invalidation is enabled.

Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/i915_drv.h  | 3 ++-
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb60fc9cf8737..b7933e1120aa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -794,11 +794,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_GUC_DEPRIVILEGE(i915) \
(INTEL_INFO(i915)->has_guc_deprivilege)
 
+#define HAS_GUC_TLB_INVALIDATION(i915) 
(INTEL_INFO(i915)->has_guc_tlb_invalidation)
+
 #define HAS_3D_PIPELINE(i915)  (INTEL_INFO(i915)->has_3d_pipeline)
 
 #define HAS_ONE_EU_PER_FUSE_BIT(i915)  
(INTEL_INFO(i915)->has_one_eu_per_fuse_bit)
 
 #define HAS_LMEMBAR_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
   GRAPHICS_VER_FULL(i915) >= IP_VER(12, 
70))
-
 #endif
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 39817490b13fd..eba2f0b919c87 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_heci_pxp); \
func(has_heci_gscfi); \
func(has_guc_deprivilege); \
+   func(has_guc_tlb_invalidation); \
func(has_l3_ccs_read); \
func(has_l3_dpf); \
func(has_llc); \
-- 
2.25.1

[Intel-gfx] [PATCH v9 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Jonathan Cavitt]

Implement GuC-based TLB invalidations and use them on MTL.

v2:
- Add missing supporting patches.

v3:
- Split suspend/resume changes and multi-gt support into separate
  patches.
- Only perform GuC TLB invalidation functions when supported.
- Move intel_guc_is_enabled check function to usage location.
- Address comments.

v4:
- Change conditions for GuC-based tlb invalidation support
  to a pci tag that's only active for MTL.
- Address some FIXMEs and formatting issues.
- Move suspend/resume changes to helper functions in intel_gt.h
- Improve comment for ct_handle_event change.
- Use cleaner if-else conditions.
- Address comments.

v5:
- Reintroduce missing change to selftest msleep duration
- Move suspend/resume loops from intel_gt.h to intel_tlb.c,
  making them no longer static inlines.
- Remove superfluous blocking and error checks.
- Move ct_handle_event exception to general case in
  ct_process_request.
- Explain usage of xa_alloc_cyclic_irq.
- Modify explanation of purpose of
  OUTSTANDING_GUC_TIMEOUT_PERIOD macro.
- Explain purpose of performing tlb invalidation twice in
  intel_gt_tlb_resume_all.

v6:
- Add this cover letter.
- Fix explanation of purpose of
  OUTSTANDING_GUC_TIMEOUT_PERIOD macro again.
- s/pci tags/pci flags
- Enable GuC TLB Invalidations separately from adding the
  flags to do so.

v7:
- Eliminate pci terminology from patches.
- Order new device info flag correctly.
- Run gen8_ggtt_invalidate in more cases, specifically when
  GuC-based TLB invalidation is not supported.
- Use intel_uncore_write_fw instead of intel_uncore_write
  during guc_ggtt_invalidate.
- Remove duplicate request message clear in ct_process_request.
- Remove faulty tag from series.

v8:
- Simplify cover letter contents.
- Fix miscellaneous formatting and typos.
- Reorder device info flags and defines.
- Reword commit message.
- Rename TLB invalidation enums and functions.
- Add comments explaining confusing points.
- Add helper function getting expected delay of CT buffer.
- Simplify intel_guc_tlb_invalidation_done by passing computed
  values.
- Remove helper functions for tlb suspend and resume.
- Move tlb suspend and resume paths to uc.
- Split suspend/resume and wedged into two patches.
- Clarify purpose of sleep change in tlb selftest.

v9:
- Explain complexity of GuC TLB invalidations as required for
  range-based TLB invalidations, which will be platformed later.
- Fix CHECKPATCH issues.
- Explain intel_guc_is_ready tlb invalidation skip in
  intel_gt_invalidate_tlb_full.
- Reword comment for unlocked xa_for_each loop in
  intel_guc_submission_reset.
- Report all errors in init_tlb_lookup.
- Remove debug message from fini_tlb_lookup.
- Use standardized interface for
  intel_guc_tlb_invalidation_done
- Remove spurious changes.
- Move wake_up_all_tlb_invalidate on wedge to correct patch.

Jonathan Cavitt (6):
  drm/i915: Add GuC TLB Invalidation device info flags
  drm/i915/guc: Add CT size delay helper
  drm/i915: No TLB invalidation on suspended GT
  drm/i915: No TLB invalidation on wedged GT
  drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck
  drm/i915: Enable GuC TLB invalidations for MTL

Prathap Kumar Valsan (1):
  drm/i915: Define and use GuC and CTB TLB invalidation routines

 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  34 ++-
 drivers/gpu/drm/i915/gt/intel_tlb.c   |  16 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|  11 +-
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  33 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  23 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  13 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   1 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 212 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |   7 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 +-
 drivers/gpu/drm/i915/i915_pci.c   |   1 +
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 13 files changed, 344 insertions(+), 15 deletions(-)

-- 
2.25.1

[Intel-gfx] [PATCH v9 7/7] drm/i915: Enable GuC TLB invalidations for MTL

[Jonathan Cavitt]

Enable GuC TLB invalidations for MTL.  Though more platforms than just
MTL support GuC TLB invalidations, MTL is presently the only platform
that requires it for any purpose, so only enable it there for now to
minimize cross-platform impact.

Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/i915_pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f79..d4b51ececbb12 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -829,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
+   .has_guc_tlb_invalidation = 1,
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
-- 
2.25.1

[Intel-gfx] [PATCH v9 4/7] drm/i915: No TLB invalidation on suspended GT

[Jonathan Cavitt]

In case of GT is suspended, don't allow submission of new TLB invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.

Signed-off-by: Fei Yang 
Signed-off-by: Jonathan Cavitt 
CC: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h   |  1 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  7 +++
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 06c44f5c28776..ff7e7b90fd49b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -536,4 +536,5 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct 
drm_printer *p);
 
 int intel_guc_sched_disable_gucid_threshold_max(struct intel_guc *guc);
 
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);
 #endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 65dd4ad9a41a4..7ae250f78a59f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,13 +1796,22 @@ static void __guc_reset_context(struct intel_context 
*ce, intel_engine_mask_t st
intel_context_put(parent);
 }
 
-void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t 
stalled)
+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
 {
struct intel_guc_tlb_wait *wait;
+   unsigned long i;
+
+   if (!HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915))
+   return;
+   xa_for_each(&guc->tlb_lookup, i, wait)
+   wake_up(&wait->wq);
+}
+
+void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t 
stalled)
+{
struct intel_context *ce;
unsigned long index;
unsigned long flags;
-   unsigned long i;
 
if (unlikely(!guc_submission_initialized(guc))) {
/* Reset called during driver load? GuC not yet initialised! */
@@ -1836,8 +1845,7 @@ void intel_guc_submission_reset(struct intel_guc *guc, 
intel_engine_mask_t stall
 * No race condition can occur here between xarray insert and wake_up,
 * so this is safe to do unlocked.
 */
-   xa_for_each(&guc->tlb_lookup, i, wait)
-   wake_up(&wait->wq);
+   wake_up_all_tlb_invalidate(guc);
 }
 
 static void guc_cancel_context_requests(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 98b103375b7ab..750cb63503dd7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -688,6 +688,8 @@ void intel_uc_suspend(struct intel_uc *uc)
/* flush the GSC worker */
intel_gsc_uc_flush_work(&uc->gsc);
 
+   wake_up_all_tlb_invalidate(guc);
+
if (!intel_guc_is_ready(guc)) {
guc->interrupts.enabled = false;
return;
@@ -736,6 +738,11 @@ static int __uc_resume(struct intel_uc *uc, bool 
enable_communication)
 
intel_gsc_uc_resume(&uc->gsc);
 
+   if (HAS_GUC_TLB_INVALIDATION(gt->i915)) {
+   intel_guc_invalidate_tlb_engines(guc);
+   intel_guc_invalidate_tlb_guc(guc);
+   }
+
return 0;
 }
 
-- 
2.25.1

[Intel-gfx] [PATCH v9 5/7] drm/i915: No TLB invalidation on wedged GT

[Jonathan Cavitt]

It is not an error for GuC TLB invalidations to fail when the GT is
wedged or disabled, so do not process a wait failure as one in
guc_send_invalidate_tlb.

Signed-off-by: Fei Yang 
Signed-off-by: Jonathan Cavitt 
CC: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c  | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7ae250f78a59f..bd6bddf53169c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -32,6 +32,7 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "i915_irq.h"
 #include "i915_trace.h"
 
 /**
@@ -1941,6 +1942,12 @@ void intel_guc_submission_cancel_requests(struct 
intel_guc *guc)
 
/* GuC is blown away, drop all references to contexts */
xa_destroy(&guc->context_lookup);
+
+   /*
+* Wedged GT won't respond to any TLB invalidation request. Simply
+* release all the blocked waiters.
+*/
+   wake_up_all_tlb_invalidate(guc);
 }
 
 void intel_guc_submission_reset_finish(struct intel_guc *guc)
@@ -4739,6 +4746,14 @@ static long must_wait_woken(struct wait_queue_entry 
*wq_entry, long timeout)
return timeout;
 }
 
+static bool intel_gt_is_enabled(const struct intel_gt *gt)
+{
+   /* Check if GT is wedged or suspended */
+   if (intel_gt_is_wedged(gt) || !intel_irqs_enabled(gt->i915))
+   return false;
+   return true;
+}
+
 static int guc_send_invalidate_tlb(struct intel_guc *guc,
   enum intel_guc_tlb_invalidation_type type)
 {
@@ -4791,7 +4806,8 @@ static int guc_send_invalidate_tlb(struct intel_guc *guc,
if (err)
goto out;
 
-   if (!must_wait_woken(&wait, intel_guc_ct_expected_delay(&guc->ct))) {
+   if (intel_gt_is_enabled(guc_to_gt(guc)) &&
+   !must_wait_woken(&wait, intel_guc_ct_expected_delay(&guc->ct))) {
guc_err(guc,
"TLB invalidation response timed out for seqno %u\n", 
seqno);
err = -ETIME;
-- 
2.25.1

[Intel-gfx] [PATCH v9 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[Jonathan Cavitt]

From: Prathap Kumar Valsan 

The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation.  We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table.  The invalidation is submitted as
a wait request and is performed in the CT event handler.  This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.

With this new invalidation routine, we can perform GuC-based GGTT
invalidations.  GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.

The additional complexity incurred in this patch will be necessary for
range-based tlb invalidations, which will be platformed in the future.

Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Bruce Chang 
Signed-off-by: Chris Wilson 
Signed-off-by: Umesh Nerlige Ramappa 
Signed-off-by: Jonathan Cavitt 
Signed-off-by: Aravind Iddamsetty 
Signed-off-by: Fei Yang 
CC: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  34 +++-
 drivers/gpu/drm/i915/gt/intel_tlb.c   |  16 +-
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  33 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  22 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |   4 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   1 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 188 +-
 7 files changed, 286 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632b..a1f7bdc602996 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -206,22 +206,38 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
 }
 
+static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
+{
+   struct intel_uncore *uncore = gt->uncore;
+   intel_wakeref_t wakeref;
+
+   with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
+   struct intel_guc *guc = >->uc.guc;
+
+   intel_guc_invalidate_tlb_guc(guc);
+   }
+}
+
 static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
 {
struct drm_i915_private *i915 = ggtt->vm.i915;
+   struct intel_gt *gt;
 
-   gen8_ggtt_invalidate(ggtt);
-
-   if (GRAPHICS_VER(i915) >= 12) {
-   struct intel_gt *gt;
+   if (!HAS_GUC_TLB_INVALIDATION(i915))
+   gen8_ggtt_invalidate(ggtt);
 
-   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link) {
+   if (HAS_GUC_TLB_INVALIDATION(i915) &&
+   intel_guc_is_ready(>->uc.guc)) {
+   guc_ggtt_ct_invalidate(gt);
+   } else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
  GEN12_GUC_TLB_INV_CR,
  GEN12_GUC_TLB_INV_CR_INVALIDATE);
-   } else {
-   intel_uncore_write_fw(ggtt->vm.gt->uncore,
- GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   } else {
+   intel_uncore_write_fw(gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   }
}
 }
 
@@ -1243,7 +1259,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.raw_insert_page = gen8_ggtt_insert_page;
}
 
-   if (intel_uc_wants_guc(&ggtt->vm.gt->uc))
+   if (intel_uc_wants_guc_submission(&ggtt->vm.gt->uc))
ggtt->invalidate = guc_ggtt_invalidate;
else
ggtt->invalidate = gen8_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index 139608c30d978..4bb13d1890e37 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -12,6 +12,7 @@
 #include "intel_gt_print.h"
 #include "intel_gt_regs.h"
 #include "intel_tlb.h"
+#include "uc/intel_guc.h"
 
 /*
  * HW architecture suggest typical invalidation time at 40us,
@@ -131,11 +132,24 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
return;
 
with_intel_gt_pm_if_awake(gt, wakeref) {
+   struct intel_guc *guc = >->uc.guc;
+
mutex_lock(>->tlb.invalidate_lock);
if (tlb_seqno_passed(gt, seqno))
goto unlock;
 
- 

[Intel-gfx] [PATCH v9 6/7] drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck

[Jonathan Cavitt]

For the gt_tlb live selftest, when operating on the GSC engine,
increase the timeout from 10 ms to 200 ms because the GSC
engine is a bit slower than the rest.

Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/gt/selftest_tlb.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_tlb.c 
b/drivers/gpu/drm/i915/gt/selftest_tlb.c
index 7e41f69fc818f..24beb94aa7a37 100644
--- a/drivers/gpu/drm/i915/gt/selftest_tlb.c
+++ b/drivers/gpu/drm/i915/gt/selftest_tlb.c
@@ -136,8 +136,15 @@ pte_tlbinv(struct intel_context *ce,
i915_request_get(rq);
i915_request_add(rq);
 
-   /* Short sleep to sanitycheck the batch is spinning before we begin */
-   msleep(10);
+   /*
+* Short sleep to sanitycheck the batch is spinning before we begin.
+* FIXME: Why is GSC so slow?
+*/
+   if (ce->engine->class == OTHER_CLASS)
+   msleep(200);
+   else
+   msleep(20);
+
if (va == vb) {
if (!i915_request_completed(rq)) {
pr_err("%s(%s): Semaphore sanitycheck failed %llx, with 
alignment %llx, using PTE size %x (phys %x, sg %x)\n",
-- 
2.25.1

[Intel-gfx] [PATCH v7 0/3 RESEND] drm/bridge_connector: implement OOB HPD handling

[Dmitry Baryshkov]

This is a resend, since the previous submission got no responses. The
patches have been reviewed/acked by several maintainers. Can we please
gain some attention and either get it merged or understand what should
be changed / improved. This series is required to delivere HPD events
from altmode driver to the MSM DP driver in the sane way.


Note, numbering for this series starts from v5, since there were several
revisions for this patchset under a different series title ([1]).

USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector, there is no way to receive these event directly.
Implement a bridge between oob_hotplug_event and drm_bridge's
hpd_notify.

Merge strategy: since this series touches i915 code, it might make sense
to merge all three patches through drm-intel.

[1] https://patchwork.freedesktop.org/series/103449/

Changes since v6:
- Rebased on top of linux-next. Fixed the freshly added
  new drm_connector_oob_hotplug_event() call.

Changes since v5:
- Fixed checkpatch warning in the first patch (noted by intel-gfx CI).

Changes since v4:
- Picked up the patchset
- Dropped msm-specific patches
- Changed drm_bridge_connector_oob_hotplug_event to call connector's HPD
  callback directly, rather than going through the last bridge's
  hpd_notify
- Added proper fwnode for the drm_bridge_connector

Bjorn Andersson (1):
  drm: Add HPD state to drm_connector_oob_hotplug_event()

Dmitry Baryshkov (2):
  drm/bridge_connector: stop filtering events in
drm_bridge_connector_hpd_cb()
  drm/bridge_connector: implement oob_hotplug_event

 drivers/gpu/drm/drm_bridge_connector.c| 36 ++-
 drivers/gpu/drm/drm_connector.c   |  6 ++--
 .../gpu/drm/i915/display/intel_display_core.h |  3 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 17 +++--
 drivers/usb/typec/altmodes/displayport.c  | 17 -
 include/drm/drm_connector.h   |  6 ++--
 6 files changed, 62 insertions(+), 23 deletions(-)

-- 
2.39.2

[Intel-gfx] [PATCH v7 1/3 RESEND] drm: Add HPD state to drm_connector_oob_hotplug_event()

[Dmitry Baryshkov]

From: Bjorn Andersson 

In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.

Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.

Also push the test for unchanged state in the displayport altmode driver
into the i915 driver, to allow other drivers to act upon each update.

Signed-off-by: Bjorn Andersson 
Reviewed-by: Hans de Goede 
Acked-by: Heikki Krogerus 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_connector.c |  6 --
 .../gpu/drm/i915/display/intel_display_core.h   |  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c | 17 ++---
 drivers/usb/typec/altmodes/displayport.c| 17 +
 include/drm/drm_connector.h |  6 --
 5 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9d4c7b0c5c05..c3725086f413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3060,6 +3060,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
 /**
  * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
connector
  * @connector_fwnode: fwnode_handle to report the event on
+ * @status: hot plug detect logical state
  *
  * On some hardware a hotplug event notification may come from outside the 
display
  * driver / device. An example of this is some USB Type-C setups where the 
hardware
@@ -3069,7 +3070,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
  * This function can be used to report these out-of-band events after obtaining
  * a drm_connector reference through calling drm_connector_find_by_fwnode().
  */
-void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
+enum drm_connector_status status)
 {
struct drm_connector *connector;
 
@@ -3078,7 +3080,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle 
*connector_fwnode)
return;
 
if (connector->funcs->oob_hotplug_event)
-   connector->funcs->oob_hotplug_event(connector);
+   connector->funcs->oob_hotplug_event(connector, status);
 
drm_connector_put(connector);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 53e5c33e08c3..ccfe27630fb6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -175,6 +175,9 @@ struct intel_hotplug {
/* Whether or not to count short HPD IRQs in HPD storms */
u8 hpd_short_storm_enabled;
 
+   /* Last state reported by oob_hotplug_event for each encoder */
+   unsigned long oob_hotplug_last_state;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0ef7cb8134b6..4f6835a7578e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5723,15 +5723,26 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
 }
 
-static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
+  enum drm_connector_status hpd_state)
 {
struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
+   bool hpd_high = hpd_state == connector_status_connected;
+   unsigned int hpd_pin = encoder->hpd_pin;
+   bool need_work = false;
 
spin_lock_irq(&i915->irq_lock);
-   i915->display.hotplug.event_bits |= BIT(encoder->hpd_pin);
+   if (hpd_high != test_bit(hpd_pin, 
&i915->display.hotplug.oob_hotplug_last_state)) {
+   i915->display.hotplug.event_bits |= BIT(hpd_pin);
+
+   __assign_bit(hpd_pin, 
&i915->display.hotplug.oob_hotplug_last_state, hpd_high);
+   need_work = true;
+   }
spin_unlock_irq(&i915->irq_lock);
-   queue_delayed_work(i915->unordered_wq, 
&i915->display.hotplug.hotplug_work, 0);
+
+   if (need_work)
+   queue_delayed_work(i915->unordered_wq, 
&i915->display.hotplug.hotplug_work, 0);
 }
 
 static const struct drm_connector_funcs intel_dp_connector_funcs = {
diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index f503cb4cd721..c6dd35cec799 100644
--- a/drivers

[Intel-gfx] [PATCH v7 2/3 RESEND] drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb()

[Dmitry Baryshkov]

In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
drivers decide whether they would like to receive the event or not.

Reviewed-by: Janne Grunau 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_bridge_connector.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 31baf1f5ff81..70582491d955 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -113,16 +113,11 @@ static void drm_bridge_connector_hpd_cb(void *cb_data,
struct drm_bridge_connector *drm_bridge_connector = cb_data;
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
-   enum drm_connector_status old_status;
 
mutex_lock(&dev->mode_config.mutex);
-   old_status = connector->status;
connector->status = status;
mutex_unlock(&dev->mode_config.mutex);
 
-   if (old_status == status)
-   return;
-
drm_bridge_connector_hpd_notify(connector, status);
 
drm_kms_helper_connector_hotplug_event(connector);
-- 
2.39.2

[Intel-gfx] [PATCH v7 3/3 RESEND] drm/bridge_connector: implement oob_hotplug_event

[Dmitry Baryshkov]

Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.

Reviewed-by: Janne Grunau 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_bridge_connector.c | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 70582491d955..8239ad43aed5 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -5,6 +5,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -107,10 +109,9 @@ static void drm_bridge_connector_hpd_notify(struct 
drm_connector *connector,
}
 }
 
-static void drm_bridge_connector_hpd_cb(void *cb_data,
-   enum drm_connector_status status)
+static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector 
*drm_bridge_connector,
+   enum drm_connector_status status)
 {
-   struct drm_bridge_connector *drm_bridge_connector = cb_data;
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
 
@@ -123,6 +124,21 @@ static void drm_bridge_connector_hpd_cb(void *cb_data,
drm_kms_helper_connector_hotplug_event(connector);
 }
 
+static void drm_bridge_connector_hpd_cb(void *cb_data,
+   enum drm_connector_status status)
+{
+   drm_bridge_connector_handle_hpd(cb_data, status);
+}
+
+static void drm_bridge_connector_oob_hotplug_event(struct drm_connector 
*connector,
+  enum drm_connector_status 
status)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+
+   drm_bridge_connector_handle_hpd(bridge_connector, status);
+}
+
 static void drm_bridge_connector_enable_hpd(struct drm_connector *connector)
 {
struct drm_bridge_connector *bridge_connector =
@@ -191,6 +207,8 @@ static void drm_bridge_connector_destroy(struct 
drm_connector *connector)
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
 
+   fwnode_handle_put(connector->fwnode);
+
kfree(bridge_connector);
 }
 
@@ -216,6 +234,7 @@ static const struct drm_connector_funcs 
drm_bridge_connector_funcs = {
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
+   .oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
 };
 
 /* 
-
@@ -352,6 +371,12 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
if (!drm_bridge_get_next_bridge(bridge))
connector_type = bridge->type;
 
+#ifdef CONFIG_OF
+   if (!drm_bridge_get_next_bridge(bridge) &&
+   bridge->of_node)
+   connector->fwnode = 
fwnode_handle_get(of_fwnode_handle(bridge->of_node));
+#endif
+
if (bridge->ddc)
ddc = bridge->ddc;
 
-- 
2.39.2

Re: [Intel-gfx] [PATCH i-g-t v2 10/11] lib/kunit: Fetch a list of test cases in advance

[Kamil Konieczny]

Hi Janusz,
On 2023-10-09 at 14:28:01 +0200, Janusz Krzysztofik wrote:
> Recent improvements to the kernel kunit framework allow us to obtain a
> list of test cases provided by a kunit test module without actually
> running them.  Use that feature to get a list of expected test cases
> before we enter a loop around igt_dynamic().  Once done, enter the
--^^
Two spaces, use one.

> igt_dynamic() section for each consecutive test case immediately, even
> before first line of a related KTAP report appears, then look for a result
> from that test case.  That should make our IGT results output still better
- ^^
Same here.

> synchronized with related kernel messages.
> 
> The list of test cases provided by a kunit test module can be obtained by
> loading the kunit base module with specific options, then loading the test
> module.  For that to be possible, take care of unloading the kunit base
- ^^
Same here.

> module before each kunit subtest (I was wrong when in one of my previous
> commit messages I suggested that on final unload of a kunit test module
> the kunit base module is unloaded automatically as its dependency,
> however, that didn't matter before, then no separate fix was required).
> Since that module can then be left loaded with non-default options if an
> error occurs, unload it explicitly before returning from igt_kunit().
> 
> There are two possible ways of getting a list of test cases: by loading
> the base kunit module with action=list module option, or by filtering
> out all test cases from being executed while asking for SKIP results from
> those filtered out.  Since the latter provides regular KTAP report that we
 ^^
Same here.

> can already parse perfectly, use it instead of trying to identify an
> unstructured list of test cases of unknown length submitted by the former.
> 
> If an IGT test that calls igt_kunit() provides a subtest name then use
> that name to filter out potential test cases that don't belong to the
> named test suite from the list.
> 
> To avoid loading any modules if no subtest is going to be executed (e.g.,
> if a nonexistent subtest has been requested), load the kunit modules in
> list mode from inside the igt_subtest_with_dynamic() section.  In order to
-- ^^
Same here.

> be free to skip the whole subtest on unmet requirements that need to be
> verified after that list has been already populated, clean it up from a
> follow up igt_fixture section.
> 
> Since we may now finish processing of all test cases / dynamic sub-
> subtests before KTAP parsing completes, don't fail if we exit the loop of
> dynamic sub-subtests with -EINPROGRESS error code returned by the parser.
> 
> v2: Split out changes in handling of modprobe errors and kernel taints to
> separate patches (Kamil),
>   - fix some string duplicates referenced from filtered out test cases not
> freed,
>   - don't check if next result is needed before fetching one, obviously
> true in first dynamic sub-subtest, and we always free last result
> before looping to next sub-subtest,
>   - still break the loop of test cases on unexpected return codes from
> kunit_kmsg_get_result(),
>   - use kunit_results_free() helper,
>   - fix typos (Kamil),
>   - update commit description.
> 
> Signed-off-by: Janusz Krzysztofik 
> ---
>  lib/igt_kmod.c | 169 ++---
>  1 file changed, 132 insertions(+), 37 deletions(-)
> 
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index ed41aa1235..150fe49803 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -899,17 +899,15 @@ static void kunit_results_free(struct igt_list_head 
> *results,
>   free(*suite_name);
>  }
>  
> -static void
> -__igt_kunit(struct igt_ktest *tst, const char *name, const char *opts)
> +static void kunit_get_tests(struct igt_list_head *tests,
> + struct igt_ktest *tst,
> + const char *filter,
> + const char *opts)
>  {
> - struct modprobe_data modprobe = { pthread_self(), tst->kmod, opts, 0, };
>   char *suite_name = NULL, *case_name = NULL;
> + struct igt_ktap_result *r, *rn;
>   struct igt_ktap_results *ktap;
> - struct igt_ktap_result *r;
> - pthread_mutexattr_t attr;
> - IGT_LIST_HEAD(results);
> - unsigned long taints;
> - int flags, ret;
> + int flags, err;
>  
>   igt_skip_on_f(tst->kmsg < 0, "Could not open /dev/kmsg\n");
>  
> @@ -919,6 +917,70 @@ __igt_kunit(struct igt_ktest *tst, const char *name, 
> const char *opts)
>  
>   igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
>  
> + /*
> +  * To get a list of test cases provided by a kunit test module, ask the
> +  * generic kunit module to respond with SKIP result for each test found.
> +  * We could also use action=list kunit parameter

[Intel-gfx] [PATCH 0/2] More print message helper updates

[John . C . Harrison]

From: John Harrison 

There was an update a while back to use sub-system specific print
helpers that implicitly add sub-system specific information to the
print. It seems a bunch of GT related messages got missed in that
update. So update them now.

Signed-off-by: John Harrison 


John Harrison (2):
  drm/i915/gt: More use of GT specific print helpers
  drm/i915: More use of GT specific print helpers

 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 29 +
 drivers/gpu/drm/i915/gt/intel_gsc.c | 11 
 drivers/gpu/drm/i915/gt/intel_gt_print.h|  3 +++
 drivers/gpu/drm/i915/gt/intel_reset.c   | 26 --
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 -
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c   |  8 +++---
 drivers/gpu/drm/i915/i915_driver.c  |  3 ++-
 drivers/gpu/drm/i915/i915_perf.c|  8 +++---
 8 files changed, 48 insertions(+), 53 deletions(-)

-- 
2.41.0

[Intel-gfx] [PATCH 1/2] drm/i915/gt: More use of GT specific print helpers

[John . C . Harrison]

From: John Harrison 

A bunch of print messages got missed in the update to using sub-system
specific helpers. So update those.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 29 +
 drivers/gpu/drm/i915/gt/intel_gsc.c | 11 
 drivers/gpu/drm/i915/gt/intel_gt_print.h|  3 +++
 drivers/gpu/drm/i915/gt/intel_reset.c   | 26 --
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 -
 5 files changed, 39 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b1a1d07e2e217..179d9546865b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -316,10 +316,9 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 
class)
 * out in the wash.
 */
cxt_size = intel_uncore_read(uncore, CXT_SIZE) + 1;
-   drm_dbg(>->i915->drm,
-   "graphics_ver = %d CXT_SIZE = %d bytes 
[0x%08x]\n",
-   GRAPHICS_VER(gt->i915), cxt_size * 64,
-   cxt_size - 1);
+   gt_dbg(gt, "graphics_ver = %d CXT_SIZE = %d bytes 
[0x%08x]\n",
+  GRAPHICS_VER(gt->i915), cxt_size * 64,
+  cxt_size - 1);
return round_up(cxt_size * 64, PAGE_SIZE);
case 3:
case 2:
@@ -788,7 +787,7 @@ static void engine_mask_apply_media_fuses(struct intel_gt 
*gt)
 
if (!(BIT(i) & vdbox_mask)) {
gt->info.engine_mask &= ~BIT(_VCS(i));
-   drm_dbg(&i915->drm, "vcs%u fused off\n", i);
+   gt_dbg(gt, "vcs%u fused off\n", i);
continue;
}
 
@@ -796,8 +795,7 @@ static void engine_mask_apply_media_fuses(struct intel_gt 
*gt)
gt->info.vdbox_sfc_access |= BIT(i);
logical_vdbox++;
}
-   drm_dbg(&i915->drm, "vdbox enable: %04x, instances: %04lx\n",
-   vdbox_mask, VDBOX_MASK(gt));
+   gt_dbg(gt, "vdbox enable: %04x, instances: %04lx\n", vdbox_mask, 
VDBOX_MASK(gt));
GEM_BUG_ON(vdbox_mask != VDBOX_MASK(gt));
 
for (i = 0; i < I915_MAX_VECS; i++) {
@@ -808,11 +806,10 @@ static void engine_mask_apply_media_fuses(struct intel_gt 
*gt)
 
if (!(BIT(i) & vebox_mask)) {
gt->info.engine_mask &= ~BIT(_VECS(i));
-   drm_dbg(&i915->drm, "vecs%u fused off\n", i);
+   gt_dbg(gt, "vecs%u fused off\n", i);
}
}
-   drm_dbg(&i915->drm, "vebox enable: %04x, instances: %04lx\n",
-   vebox_mask, VEBOX_MASK(gt));
+   gt_dbg(gt, "vebox enable: %04x, instances: %04lx\n", vebox_mask, 
VEBOX_MASK(gt));
GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
 }
 
@@ -838,7 +835,7 @@ static void engine_mask_apply_compute_fuses(struct intel_gt 
*gt)
 */
for_each_clear_bit(i, &ccs_mask, I915_MAX_CCS) {
info->engine_mask &= ~BIT(_CCS(i));
-   drm_dbg(&i915->drm, "ccs%u fused off\n", i);
+   gt_dbg(gt, "ccs%u fused off\n", i);
}
 }
 
@@ -866,8 +863,8 @@ static void engine_mask_apply_copy_fuses(struct intel_gt 
*gt)
   _BCS(instance));
 
if (mask & info->engine_mask) {
-   drm_dbg(&i915->drm, "bcs%u fused off\n", instance);
-   drm_dbg(&i915->drm, "bcs%u fused off\n", instance + 1);
+   gt_dbg(gt, "bcs%u fused off\n", instance);
+   gt_dbg(gt, "bcs%u fused off\n", instance + 1);
 
info->engine_mask &= ~mask;
}
@@ -907,8 +904,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt 
*gt)
 *submission, which will wake up the GSC power well.
 */
if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>->uc)) {
-   drm_notice(>->i915->drm,
-  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   gt_notice(gt, "No GSC FW selected, disabling GSC CS and media 
C6\n");
info->engine_mask &= ~BIT(GSC0);
}
 
@@ -1097,8 +1093,7 @@ static int init_status_page(struct intel_engine_cs 
*engine)
 */
obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
if (IS_ERR(obj)) {
-   drm_err(&engine->i915->drm,
-   "Failed to allocate status page\n");
+   gt_err(engine->gt, "Failed to allocate status page\n");
return PTR_ERR(obj);
}
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index bcc36

[Intel-gfx] [PATCH 2/2] drm/i915: More use of GT specific print helpers

[John . C . Harrison]

From: John Harrison 

Update a bunch of GT related print messages in non-GT files to use the
GT specific helpers.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 8 +++-
 drivers/gpu/drm/i915/i915_driver.c| 3 ++-
 drivers/gpu/drm/i915/i915_perf.c  | 8 
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 0d3b22a743659..453d855dd1de7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -68,8 +68,7 @@ static void gsc_work(struct work_struct *work)
 * A proxy failure right after firmware load 
means the proxy-init
 * step has failed so mark GSC as not usable 
after this
 */
-   drm_err(>->i915->drm,
-   "GSC proxy handler failed to init\n");
+   gt_err(gt, "GSC proxy handler failed to 
init\n");
intel_uc_fw_change_status(&gsc->fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
}
goto out_put;
@@ -83,11 +82,10 @@ static void gsc_work(struct work_struct *work)
 * status register to check if the proxy init was 
actually successful
 */
if (intel_gsc_uc_fw_proxy_init_done(gsc, false)) {
-   drm_dbg(>->i915->drm, "GSC Proxy 
initialized\n");
+   gt_dbg(gt, "GSC Proxy initialized\n");
intel_uc_fw_change_status(&gsc->fw, 
INTEL_UC_FIRMWARE_RUNNING);
} else {
-   drm_err(>->i915->drm,
-   "GSC status reports proxy init not 
complete\n");
+   gt_err(gt, "GSC status reports proxy init not 
complete\n");
intel_uc_fw_change_status(&gsc->fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
}
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index e5a94b08d5efe..944ab895da72e 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -71,6 +71,7 @@
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_print.h"
 #include "gt/intel_rc6.h"
 
 #include "pxp/intel_pxp.h"
@@ -429,7 +430,7 @@ static int i915_pcode_init(struct drm_i915_private *i915)
for_each_gt(gt, i915, id) {
ret = intel_pcode_init(gt->uncore);
if (ret) {
-   drm_err(>->i915->drm, "gt%d: intel_pcode_init failed 
%d\n", id, ret);
+   gt_err(gt, "intel_pcode_init failed %d\n", ret);
return ret;
}
}
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1347e4ec9dd5a..8f7ab64feec0d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -206,6 +206,7 @@
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_clock_utils.h"
 #include "gt/intel_gt_mcr.h"
+#include "gt/intel_gt_print.h"
 #include "gt/intel_gt_regs.h"
 #include "gt/intel_lrc.h"
 #include "gt/intel_lrc_reg.h"
@@ -1659,9 +1660,8 @@ static void i915_oa_stream_destroy(struct 
i915_perf_stream *stream)
free_noa_wait(stream);
 
if (perf->spurious_report_rs.missed) {
-   drm_notice(>->i915->drm,
-  "%d spurious OA report notices suppressed due to 
ratelimiting\n",
-  perf->spurious_report_rs.missed);
+   gt_notice(gt, "%d spurious OA report notices suppressed due to 
ratelimiting\n",
+ perf->spurious_report_rs.missed);
}
 }
 
@@ -1852,7 +1852,7 @@ static int alloc_oa_buffer(struct i915_perf_stream 
*stream)
 */
ret = i915_vma_pin(vma, 0, SZ_16M, PIN_GLOBAL | PIN_HIGH);
if (ret) {
-   drm_err(>->i915->drm, "Failed to pin OA buffer %d\n", ret);
+   gt_err(gt, "Failed to pin OA buffer %d\n", ret);
goto err_unref;
}
 
-- 
2.41.0

Re: [Intel-gfx] [PATCH] drm/print: Add drm_dbg_ratelimited

[John Harrison]

On 10/9/2023 09:52, Andi Shyti wrote:

Hi,


From: Nirmoy Das 

Add a function for ratelimitted debug print.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Reviewed-by: Matthew Auld 
Reviewed-by: Andi Shyti 
Signed-off-by: Nirmoy Das 
Signed-off-by: Andi Shyti 

Just a kind reminder!

This is the second time this patch has been sent and we have seen
some potential use of the drm_dbg_ratelimited().
But this patch does not actually add a user. So it is dead code at this 
point, which is not allowed.


If you have code that wants to use such a helper then the helper should 
be part of the patch that adds that code.


John.



Any feedback?

Thanks,
Andi

Re: [Intel-gfx] [PATCH v8 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

[John Harrison]

On 10/9/2023 01:56, Tvrtko Ursulin wrote:

On 06/10/2023 19:20, Jonathan Cavitt wrote:

From: Prathap Kumar Valsan 

The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation.  We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table.  The invalidation is submitted as
a wait request and is performed in the CT event handler.  This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.

With this new invalidation routine, we can perform GuC-based GGTT
invalidations.  GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.

Purpose of xarray:
The tlb_lookup table is allocated as an xarray because the set of
pending TLB invalidations may have no upper bound.  The consequence of
this is that all actions interfacing with this table need to use the
xarray functions, such as xa_alloc_cyclic_irq for array insertion.

Purpose of must_wait_woken:
Our wait for the G2H ack for the completion of a TLB invalidation is
mandatory; we must wait for the HW to confirm that the physical
addresses are no longer accessible before we return those to the system.

On switching to using the wait_woken() convenience routine, we
introduced ourselves to an issue where wait_woken() may complete early
under a kthread that is stopped. Since we send a TLB invalidation when
we try to release pages from the shrinker, we can be called from any
process; including kthreads.

Using wait_woken() from any process context causes another issue. The
use of is_kthread_should_stop() assumes that any task with PF_KTHREAD
set was made by kthread_create() and has called set_kthread_struct().
This is not true for the raw kernel_thread():


This explanation misses the main point of my ask - which is to explain 
why a simpler scheme isn't sufficient. Simpler scheme aka not needed 
the xarray or any flavour of wait_token().


In other words it is obvious we have to wait for the invalidation ack, 
but not obvious why we need a complicated scheme.
The alternative being to simply serialise all TLB invalidation requests? 
Thus, no complex tracking required as there is only one in flight at a 
time? That seems inefficient and a potential performance impact if a 
bunch of invalidations are required back to back. But given that the 
current scheme is global invalidation only (no support for ranges / per 
page invalidation yet), is it possible to get multiple back-to-back 
requests?





BUG: kernel NULL pointer dereference, address: 
[ 3089.759660] Call Trace:
[ 3089.762110]  wait_woken+0x4f/0x80
[ 3089.765496]  guc_send_invalidate_tlb+0x1fe/0x310 [i915]
[ 3089.770725]  ? syscall_return_via_sysret+0xf/0x7f
[ 3089.775426]  ? do_wait_intr_irq+0xb0/0xb0
[ 3089.779430]  ? __switch_to_asm+0x40/0x70
[ 3089.783349]  ? __switch_to_asm+0x34/0x70
[ 3089.787273]  ? __switch_to+0x7a/0x3e0
[ 3089.790930]  ? __switch_to_asm+0x34/0x70
[ 3089.794883]  intel_guc_invalidate_tlb_full+0x92/0xa0 [i915]
[ 3089.800487]  intel_invalidate_tlb_full+0x94/0x190 [i915]
[ 3089.805824]  intel_invalidate_tlb_full_sync+0x1b/0x30 [i915]
[ 3089.811508]  __i915_gem_object_unset_pages+0x138/0x150 [i915]
[ 3089.817279]  __i915_gem_object_put_pages+0x25/0x90 [i915]
[ 3089.822706]  i915_gem_shrink+0x532/0x7e0 [i915]
[ 3089.827264]  i915_gem_shrinker_scan+0x3d/0xd0 [i915]
[ 3089.832230]  do_shrink_slab+0x12c/0x2a0
[ 3089.836065]  shrink_slab+0xad/0x2b0
[ 3089.839550]  shrink_node+0xcc/0x410
[ 3089.843035]  do_try_to_free_pages+0xc6/0x380
[ 3089.847306]  try_to_free_pages+0xec/0x1c0
[ 3089.851312]  __alloc_pages_slowpath+0x3ad/0xd10
[ 3089.855845]  ? update_sd_lb_stats+0x636/0x710
[ 3089.860204]  __alloc_pages_nodemask+0x2d5/0x310
[ 3089.864737]  new_slab+0x265/0xa80
[ 3089.868053]  ___slab_alloc+0y_to_free_pages+0xec/0x1c0
[ 3089.871798]  ? copy_process+0x1e5/0x1a00
[ 3089.875717]  ? load_balance+0x165/0xb20
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.879555]  __slab_alloc+0x1c/0x30
[ 3089.883047]  kmem_cache_alloc_node+0x9f/0x240
[ 3089.887397]  ? copy_process+0x1e5/0x1a00
[ 3089.891314]  copy_process+0x1e5/0x1a00
[ 3089.895058]  ? __switch_to_asm+0x40/0x70
[ 3089.898977]  ? __switch_to_asm+0x34/0x70
[ 3089.902903]  ? __switch_to_asm+0x40/0x70
[ 3089.906828]  ? __switch_to_asm+0x34/0x70
[ 3089.910745]  _do_fork+0x83/0x350
[ 308

Re: [Intel-gfx] [PATCH] drm/i915: Fix VLV color state readout

[Ville Syrjälä]

On Mon, Oct 09, 2023 at 06:36:30PM +0300, Jani Nikula wrote:
> On Mon, 09 Oct 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > VLV was missed when the color.get_config() hook was added.
> > Remedy that.
> 
> Oops, how did I manage that?! Thanks for the fix,

vlv_color_funcs is a fairly recent thing. I suspect it didn't
exist when you originally wrote the patch, but presumably the
patch still applied cleanly.

> 
> Reviewed-by: Jani Nikula 
> 
> > Not really sure what the final plan here was since a bunch of
> > color related readout was left in intel_display.c anyway,
> > but that's for anothr day to figure out...
> 
> I guess I just wanted to start somewhere, and the cutoff was mostly by
> the registers where the data is read from, e.g. ->gamma_mode and
> ->wgc_enable coming from TRANSCONF I left in place.
> 
> BR,
> Jani.
> 
> >
> > Cc: Jani Nikula 
> > Fixes: 9af09dfcdfa1 ("drm/i915/color: move pre-SKL gamma and CSC enable 
> > read to intel_color")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 4f92fc31059f..2a2a163ea652 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -3702,6 +3702,7 @@ static const struct intel_color_funcs vlv_color_funcs 
> > = {
> > .read_luts = i965_read_luts,
> > .lut_equal = i965_lut_equal,
> > .read_csc = vlv_read_csc,
> > +   .get_config = i9xx_get_config,
> >  };
> >  
> >  static const struct intel_color_funcs i965_color_funcs = {
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] Regression in linux-next

[Wysocki, Rafael J]

Hi,

On 10/9/2023 7:10 AM, Borah, Chaitanya Kumar wrote:

Hello Rafael


Thanks for the report, I think that this is a lockdep assertion failing.
If that is correct, it should be straightforward to fix.
I'll take care of this early next week.
Thanks!

Thank you for your response.  Please let us know when a fix is available.


It should be fixed in linux-next from today, by this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=b4027ce7714f309e96b804b7fb088a40d708

Thanks!



From: Wysocki, Rafael J 
Sent: Saturday, October 7, 2023 2:01 AM
To: Borah, Chaitanya Kumar 
Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar 
; Saarinen, Jani 
Subject: Re: Regression in linux-next

Hi,
On 10/5/2023 5:58 PM, Borah, Chaitanya Kumar wrote:
Hello Rafael,
  
Hope you are doing well. I am Chaitanya from the linux graphics team in Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on 
linux-next repository.
  
Thanks for the report, I think that this is a lockdep assertion failing.

If that is correct, it should be straightforward to fix.
I'll take care of this early next week.
Thanks!

On next-20231003 [2], we are seeing the following error
  
```

<4>[   14.093075] [ cut here ]
<4>[   14.097664] WARNING: CPU: 0 PID: 1 at drivers/thermal/thermal_trip.c:18 
for_each_thermal_trip+0x83/0x90
<4>[   14.106977] Modules linked in:
<4>[   14.110017] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G    W      
6.6.0-rc4-next-20231003-next-20231003-gc9f2baaa18b5+ #1
<4>[   14.121305] Hardware name: Intel Corporation Meteor Lake Client 
Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3323.D89.2309110529 09/11/2023
<4>[   14.134478] RIP: 0010:for_each_thermal_trip+0x83/0x90
<4>[   14.139496] Code: 5c 41 5d c3 cc cc cc cc 5b 31 c0 5d 41 5c 41 5d c3 cc cc cc 
cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 21 a2 2d 00 85 c0 75 9a <0f> 0b eb 96 66 0f 
1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90
  
Details log can be found in [3].
  
After bisecting the tree, the following patch [4] seems to be causing the regression.
  
commit d5ea889246b112e228433a5f27f57af90ca0c1fb

Author: Rafael J. Wysocki mailto:rafael.j.wyso...@intel.com
Date:   Thu Sep 21 20:02:59 2023 +0200
  
     ACPI: thermal: Do not use trip indices for cooling device binding
  
     Rearrange the ACPI thermal driver's callback functions used for cooling

     device binding and unbinding, acpi_thermal_bind_cooling_device() and
     acpi_thermal_unbind_cooling_device(), respectively, so that they use trip
     pointers instead of trip indices which is more straightforward and allows
     the driver to become independent of the ordering of trips in the thermal
     zone structure.
  
     The general functionality is not expected to be changed.
  
     Signed-off-by: Rafael J. Wysocki mailto:rafael.j.wyso...@intel.com

     Reviewed-by: Daniel Lezcano mailto:daniel.lezc...@linaro.org
  
We also verified by moving the head of the tree to the previous commit.
  
Could you please check why this patch causes the regression and if we can find a solution for it soon?
  
[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003
[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20231003/bat-mtlp-6/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20231003&id=d5ea889246b112e228433a5f27f57af90ca0c1fb

Re: [Intel-gfx] [PATCH] drm/print: Add drm_dbg_ratelimited

[Andi Shyti]

Hi John,

> > > From: Nirmoy Das 
> > > 
> > > Add a function for ratelimitted debug print.
> > > 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Thomas Zimmermann 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Reviewed-by: Matthew Auld 
> > > Reviewed-by: Andi Shyti 
> > > Signed-off-by: Nirmoy Das 
> > > Signed-off-by: Andi Shyti 
> > Just a kind reminder!
> > 
> > This is the second time this patch has been sent and we have seen
> > some potential use of the drm_dbg_ratelimited().
> But this patch does not actually add a user. So it is dead code at this
> point, which is not allowed.
> 
> If you have code that wants to use such a helper then the helper should be
> part of the patch that adds that code.

this is the kind of "Argh! If I had it!" patch. At the 3/4th
"Argh! If I had it!" then you decide to send it but don't
remember for which case you needed it.

I'm sure that once this goes in won't be long until poeple will
start using it. In any case, if it doesn't go in I will keep it
ready until the case comes.

Andi

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: More use of GT specific print helpers

[Andi Shyti]

Hi John,

...

>   if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
> - drm_warn_once(>->i915->drm, "GSC irq: intf_id %d is out of 
> range", intf_id);
> + gt_warn_once(gt, "GSC irq: intf_id %d is out of range", 
> intf_id);
>   return;
>   }
>  
>   if (!HAS_HECI_GSC(gt->i915)) {
> - drm_warn_once(>->i915->drm, "GSC irq: not supported");
> + gt_warn_once(gt, "GSC irq: not supported");
>   return;
>   }
>  
> @@ -300,7 +301,7 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned 
> int intf_id)
>  
>   ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
>   if (ret)
> - drm_err_ratelimited(>->i915->drm, "error handling GSC irq: 
> %d\n", ret);
> + gt_err_ratelimited(gt, "error handling GSC irq: %d\n", ret);
>  }
>  
>  void intel_gsc_irq_handler(struct intel_gt *gt, u32 iir)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_print.h
> index 55a336a9ff061..7fdc78c79273e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
> @@ -16,6 +16,9 @@
>  #define gt_warn(_gt, _fmt, ...) \
>   drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
> ##__VA_ARGS__)
>  
> +#define gt_warn_once(_gt, _fmt, ...) \
> + drm_warn_once(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
> ##__VA_ARGS__)
> +

I would add the gt_warn_once() part in a different patch.

Andi

Re: [Intel-gfx] [PATCH] drm/print: Add drm_dbg_ratelimited

[John Harrison]

On 10/9/2023 12:43, Andi Shyti wrote:

Hi John,


From: Nirmoy Das 

Add a function for ratelimitted debug print.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Reviewed-by: Matthew Auld 
Reviewed-by: Andi Shyti 
Signed-off-by: Nirmoy Das 
Signed-off-by: Andi Shyti 

Just a kind reminder!

This is the second time this patch has been sent and we have seen
some potential use of the drm_dbg_ratelimited().

But this patch does not actually add a user. So it is dead code at this
point, which is not allowed.

If you have code that wants to use such a helper then the helper should be
part of the patch that adds that code.

this is the kind of "Argh! If I had it!" patch. At the 3/4th
"Argh! If I had it!" then you decide to send it but don't
remember for which case you needed it.

But you should have sent it on the 1st patch set that wanted it.

And if you have code already merged that would benefit from it, then 
update that code to use it and post that as a patch together with this 
implementation.


And note that if your code is GT related, then it should use 
gt_dbg_ratelimited not drm_dbg_ratelimited.


John.




I'm sure that once this goes in won't be long until poeple will
start using it. In any case, if it doesn't go in I will keep it
ready until the case comes.

Andi

Re: [Intel-gfx] [PATCH 2/2] drm/i915: More use of GT specific print helpers

[Andi Shyti]

Hi John,

...

> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -71,6 +71,7 @@
>  #include "gem/i915_gem_pm.h"
>  #include "gt/intel_gt.h"
>  #include "gt/intel_gt_pm.h"
> +#include "gt/intel_gt_print.h"
>  #include "gt/intel_rc6.h"
>  
>  #include "pxp/intel_pxp.h"
> @@ -429,7 +430,7 @@ static int i915_pcode_init(struct drm_i915_private *i915)
>   for_each_gt(gt, i915, id) {
>   ret = intel_pcode_init(gt->uncore);
>   if (ret) {
> - drm_err(>->i915->drm, "gt%d: intel_pcode_init failed 
> %d\n", id, ret);
> + gt_err(gt, "intel_pcode_init failed %d\n", ret);

using gt_*() print functions in the upper layers looks a bit
wrong to me. If we need GT printing, the prints need to be done
inside the function called, in this case would be
intel_pcode_init().

Andi

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: More use of GT specific print helpers

[John Harrison]

On 10/9/2023 12:50, Andi Shyti wrote:

Hi John,

...


if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
-   drm_warn_once(>->i915->drm, "GSC irq: intf_id %d is out of 
range", intf_id);
+   gt_warn_once(gt, "GSC irq: intf_id %d is out of range", 
intf_id);
return;
}
  
  	if (!HAS_HECI_GSC(gt->i915)) {

-   drm_warn_once(>->i915->drm, "GSC irq: not supported");
+   gt_warn_once(gt, "GSC irq: not supported");
return;
}
  
@@ -300,7 +301,7 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned int intf_id)
  
  	ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);

if (ret)
-   drm_err_ratelimited(>->i915->drm, "error handling GSC irq: 
%d\n", ret);
+   gt_err_ratelimited(gt, "error handling GSC irq: %d\n", ret);
  }
  
  void intel_gsc_irq_handler(struct intel_gt *gt, u32 iir)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h 
b/drivers/gpu/drm/i915/gt/intel_gt_print.h
index 55a336a9ff061..7fdc78c79273e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
@@ -16,6 +16,9 @@
  #define gt_warn(_gt, _fmt, ...) \
drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
##__VA_ARGS__)
  
+#define gt_warn_once(_gt, _fmt, ...) \

+   drm_warn_once(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
##__VA_ARGS__)
+

I would add the gt_warn_once() part in a different patch.
But this is the patch that uses it. You should not add dead code. The 
only exception being if it is something large and complex that needs to 
be added in stages for ease of code review. But this really doesn't 
count as large or complex!


John.



Andi

Re: [Intel-gfx] [PATCH 2/2] drm/i915: More use of GT specific print helpers

[John Harrison]

On 10/9/2023 12:54, Andi Shyti wrote:

Hi John,

...


--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -71,6 +71,7 @@
  #include "gem/i915_gem_pm.h"
  #include "gt/intel_gt.h"
  #include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_print.h"
  #include "gt/intel_rc6.h"
  
  #include "pxp/intel_pxp.h"

@@ -429,7 +430,7 @@ static int i915_pcode_init(struct drm_i915_private *i915)
for_each_gt(gt, i915, id) {
ret = intel_pcode_init(gt->uncore);
if (ret) {
-   drm_err(>->i915->drm, "gt%d: intel_pcode_init failed 
%d\n", id, ret);
+   gt_err(gt, "intel_pcode_init failed %d\n", ret);

using gt_*() print functions in the upper layers looks a bit
wrong to me. If we need GT printing, the prints need to be done
inside the function called, in this case would be
intel_pcode_init().
It is less wrong that using gt->i915->drm as a parameter and 'gt%d' in 
the format string. That is the whole point of the helper. The code has 
access to a gt object so it should use the gt helper to make use of that 
object rather than unrolling it and diving in to the gt internals.


As for moving the error message inside the init function itself. That is 
maybe a valid change but that potentially counts as a functional change 
and should be done by someone who actually knows the code. All I'm doing 
is improving the code layering by using the correct helper to hide the 
internal details of an object this layer should not know about.


John.



Andi

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: More use of GT specific print helpers

[Andi Shyti]

Hi John,

...

> > >   if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
> > > - drm_warn_once(>->i915->drm, "GSC irq: intf_id %d is out of 
> > > range", intf_id);
> > > + gt_warn_once(gt, "GSC irq: intf_id %d is out of range", 
> > > intf_id);
> > >   return;
> > >   }
> > >   if (!HAS_HECI_GSC(gt->i915)) {
> > > - drm_warn_once(>->i915->drm, "GSC irq: not supported");
> > > + gt_warn_once(gt, "GSC irq: not supported");
> > >   return;
> > >   }
> > > @@ -300,7 +301,7 @@ static void gsc_irq_handler(struct intel_gt *gt, 
> > > unsigned int intf_id)
> > >   ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
> > >   if (ret)
> > > - drm_err_ratelimited(>->i915->drm, "error handling GSC irq: 
> > > %d\n", ret);
> > > + gt_err_ratelimited(gt, "error handling GSC irq: %d\n", ret);
> > >   }
> > >   void intel_gsc_irq_handler(struct intel_gt *gt, u32 iir)
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_print.h
> > > index 55a336a9ff061..7fdc78c79273e 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
> > > @@ -16,6 +16,9 @@
> > >   #define gt_warn(_gt, _fmt, ...) \
> > >   drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
> > > ##__VA_ARGS__)
> > > +#define gt_warn_once(_gt, _fmt, ...) \
> > > + drm_warn_once(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
> > > ##__VA_ARGS__)
> > > +
> > I would add the gt_warn_once() part in a different patch.
> But this is the patch that uses it. You should not add dead code. The only
> exception being if it is something large and complex that needs to be added
> in stages for ease of code review. But this really doesn't count as large or
> complex!

I wouldn't call it dead code if it's used right after... you
could also put all the *_warn_* changes in different patch.

Anyway, I don't have a strong opinion for such a straight forward
patch, so that I'm fine with it as it is:

Reviewed-by: Andi Shyti  

Andi

Re: [Intel-gfx] [PATCH 06/19] drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_max_bpp()

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:14PM +0300, Imre Deak wrote:
> Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_max_bpp()
> instead of the version stored in the encoder.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 13 -
>  drivers/gpu/drm/i915/display/intel_dp.h |  3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 +-
>  3 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6e6b3fe593453..00f5fecdbf386 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1215,7 +1215,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>* TBD pass the connector BPC,
>* for now U8_MAX so that max BPC on that platform would be 
> picked
>*/
> - pipe_bpp = intel_dp_dsc_compute_max_bpp(intel_dp, U8_MAX);
> + pipe_bpp = intel_dp_dsc_compute_max_bpp(connector, U8_MAX);
>  
>   /*
>* Output bpp is stored in 6.4 format so right shift by 4 to 
> get the
> @@ -1577,9 +1577,10 @@ u8 intel_dp_dsc_max_src_input_bpc(struct 
> drm_i915_private *i915)
>   return 0;
>  }
>  
> -int intel_dp_dsc_compute_max_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> +int intel_dp_dsc_compute_max_bpp(const struct intel_connector *connector,
> +  u8 max_req_bpc)
>  {
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   int i, num_bpc;
>   u8 dsc_bpc[3] = {0};
>   u8 dsc_max_bpc;
> @@ -1591,7 +1592,7 @@ int intel_dp_dsc_compute_max_bpp(struct intel_dp 
> *intel_dp, u8 max_req_bpc)
>  
>   dsc_max_bpc = min_t(u8, dsc_max_bpc, max_req_bpc);
>  
> - num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd,
> + num_bpc = drm_dp_dsc_sink_supported_input_bpcs(connector->dp.dsc_dpcd,
>  dsc_bpc);
>   for (i = 0; i < num_bpc; i++) {
>   if (dsc_max_bpc >= dsc_bpc[i])
> @@ -2056,6 +2057,8 @@ static int intel_edp_dsc_compute_pipe_bpp(struct 
> intel_dp *intel_dp,
> struct link_config_limits *limits)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
>   int pipe_bpp, forced_bpp;
>   int dsc_src_min_bpp, dsc_sink_min_bpp, dsc_min_bpp;
>   int dsc_src_max_bpp, dsc_sink_max_bpp, dsc_max_bpp;
> @@ -2068,7 +2071,7 @@ static int intel_edp_dsc_compute_pipe_bpp(struct 
> intel_dp *intel_dp,
>   int max_bpc = min(limits->pipe.max_bpp / 3, 
> (int)conn_state->max_requested_bpc);
>  
>   /* For eDP use max bpp that can be supported with DSC. */
> - pipe_bpp = intel_dp_dsc_compute_max_bpp(intel_dp, max_bpc);
> + pipe_bpp = intel_dp_dsc_compute_max_bpp(connector, max_bpc);
>   if (!is_dsc_pipe_bpp_sufficient(i915, conn_state, limits, 
> pipe_bpp)) {
>   drm_dbg_kms(&i915->drm,
>   "Computed BPC is not in DSC BPC limits\n");
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index bd9cb9680b4cd..af87aa2a5ed67 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -116,7 +116,8 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
>  struct intel_crtc_state *crtc_state,
>  unsigned int type);
>  bool intel_digital_port_connected(struct intel_encoder *encoder);
> -int intel_dp_dsc_compute_max_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc);
> +int intel_dp_dsc_compute_max_bpp(const struct intel_connector *connector,
> +  u8 dsc_max_bpc);
>  u16 intel_dp_dsc_get_max_compressed_bpp(struct drm_i915_private *i915,
>   u32 link_clock, u32 lane_count,
>   u32 mode_clock, u32 mode_hdisplay,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index e01f669d2c8a1..3ff429c30f300 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1003,7 +1003,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector 
> *connector,
>* TBD pass the connector BPC,
>* for now U8_MAX so that max BPC on that platform would be 
> picked
>*/
> - int pipe_bpp = intel_dp_dsc_compute_max_bpp(intel_dp, U8_MAX);
> + int pipe_bpp = intel_dp_dsc_compute_max_bpp(intel_connector, 
> U8_MAX);
>  
>   if (drm_dp_sink_s

Re: [Intel-gfx] [PATCH 07/19] drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_fec()

[Lisovskiy, Stanislav]

On Fri, Oct 06, 2023 at 04:37:15PM +0300, Imre Deak wrote:
> Use the connector's DSC DPCD capabilities in intel_dp_supports_fec().
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Stanislav Lisovskiy 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 00f5fecdbf386..8450856e5618d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1370,10 +1370,11 @@ static bool intel_dp_source_supports_fec(struct 
> intel_dp *intel_dp,
>  }
>  
>  static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> +   const struct intel_connector *connector,
> const struct intel_crtc_state *pipe_config)
>  {
>   return intel_dp_source_supports_fec(intel_dp, pipe_config) &&
> - drm_dp_sink_supports_fec(intel_dp->fec_capable);
> + drm_dp_sink_supports_fec(connector->dp.fec_capability);
>  }
>  
>  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> @@ -2110,12 +2111,14 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + const struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
>   const struct drm_display_mode *adjusted_mode =
>   &pipe_config->hw.adjusted_mode;
>   int ret;
>  
>   pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> - intel_dp_supports_fec(intel_dp, pipe_config);
> + intel_dp_supports_fec(intel_dp, connector, pipe_config);
>  
>   if (!intel_dp_supports_dsc(intel_dp, pipe_config))
>   return -EINVAL;
> -- 
> 2.39.2
> 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: More use of GT specific print helpers

[John Harrison]

On 10/9/2023 13:02, Andi Shyti wrote:

Hi John,

...


if (intf_id >= INTEL_GSC_NUM_INTERFACES) {
-   drm_warn_once(>->i915->drm, "GSC irq: intf_id %d is out of 
range", intf_id);
+   gt_warn_once(gt, "GSC irq: intf_id %d is out of range", 
intf_id);
return;
}
if (!HAS_HECI_GSC(gt->i915)) {
-   drm_warn_once(>->i915->drm, "GSC irq: not supported");
+   gt_warn_once(gt, "GSC irq: not supported");
return;
}
@@ -300,7 +301,7 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned 
int intf_id)
ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
if (ret)
-   drm_err_ratelimited(>->i915->drm, "error handling GSC irq: 
%d\n", ret);
+   gt_err_ratelimited(gt, "error handling GSC irq: %d\n", ret);
   }
   void intel_gsc_irq_handler(struct intel_gt *gt, u32 iir)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h 
b/drivers/gpu/drm/i915/gt/intel_gt_print.h
index 55a336a9ff061..7fdc78c79273e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
@@ -16,6 +16,9 @@
   #define gt_warn(_gt, _fmt, ...) \
drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
##__VA_ARGS__)
+#define gt_warn_once(_gt, _fmt, ...) \
+   drm_warn_once(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, 
##__VA_ARGS__)
+

I would add the gt_warn_once() part in a different patch.

But this is the patch that uses it. You should not add dead code. The only
exception being if it is something large and complex that needs to be added
in stages for ease of code review. But this really doesn't count as large or
complex!

I wouldn't call it dead code if it's used right after... you
could also put all the *_warn_* changes in different patch.
I did start splitting it into errors vs debugs but then decided it 
wasn't worth the effort ;)




Anyway, I don't have a strong opinion for such a straight forward
patch, so that I'm fine with it as it is:

Reviewed-by: Andi Shyti 

Thanks :).



Andi