Re: [Intel-gfx] [PATCH 04/19] drm/i915: Remove gen6_ppgtt_unpin_all

[Matthew Auld]

On Mon, 30 Aug 2021 at 13:09, Maarten Lankhorst
 wrote:
>
> gen6_ppgtt_unpin_all is unused, kill it.
>
> Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matthew Auld 

> ---
>  drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ---
>  drivers/gpu/drm/i915/gt/gen6_ppgtt.h |  1 -
>  2 files changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> index 1aee5e6b1b23..efc243f40d0f 100644
> --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> @@ -405,17 +405,6 @@ void gen6_ppgtt_unpin(struct i915_ppgtt *base)
> i915_vma_unpin(ppgtt->vma);
>  }
>
> -void gen6_ppgtt_unpin_all(struct i915_ppgtt *base)
> -{
> -   struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(base);
> -
> -   if (!atomic_read(&ppgtt->pin_count))
> -   return;
> -
> -   i915_vma_unpin(ppgtt->vma);
> -   atomic_set(&ppgtt->pin_count, 0);
> -}
> -
>  struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
>  {
> struct i915_ggtt * const ggtt = gt->ggtt;
> diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.h 
> b/drivers/gpu/drm/i915/gt/gen6_ppgtt.h
> index 6a61a5c3a85a..ab0eecb086dd 100644
> --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.h
> +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.h
> @@ -71,7 +71,6 @@ static inline struct gen6_ppgtt *to_gen6_ppgtt(struct 
> i915_ppgtt *base)
>
>  int gen6_ppgtt_pin(struct i915_ppgtt *base, struct i915_gem_ww_ctx *ww);
>  void gen6_ppgtt_unpin(struct i915_ppgtt *base);
> -void gen6_ppgtt_unpin_all(struct i915_ppgtt *base);
>  void gen6_ppgtt_enable(struct intel_gt *gt);
>  void gen7_ppgtt_enable(struct intel_gt *gt);
>  struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt);
> --
> 2.32.0
>

Re: [Intel-gfx] [PATCH 08/19] drm/i915: Fix runtime pm handling in i915_gem_shrink

[Matthew Auld]

On Mon, 30 Aug 2021 at 13:10, Maarten Lankhorst
 wrote:
>
> We forgot to call intel_runtime_pm_put on error, fix it!
>
> Signed-off-by: Maarten Lankhorst 
> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
> Cc: Thomas Hellström 
> Cc: Daniel Vetter 
> Cc:  # v5.13+

How does the err handling work? gem_shrink is meant to return the
number of pages reclaimed which is an unsigned long, and yet we are
also just returning the err here? Fortunately it looks like nothing is
calling gem_shrinker with an actual ww context, so nothing will hit
this yet? I think the interface needs to be reworked or something.

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index e382b7f2353b..5ab136ffdeb2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -118,7 +118,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
> intel_wakeref_t wakeref = 0;
> unsigned long count = 0;
> unsigned long scanned = 0;
> -   int err;
> +   int err = 0;
>
> /* CHV + VTD workaround use stop_machine(); need to trylock vm->mutex 
> */
> bool trylock_vm = !ww && intel_vm_no_concurrent_access_wa(i915);
> @@ -242,12 +242,15 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
> list_splice_tail(&still_in_list, phase->list);
> spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
> if (err)
> -   return err;
> +   break;
> }
>
> if (shrink & I915_SHRINK_BOUND)
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>
> +   if (err)
> +   return err;
> +
> if (nr_scanned)
> *nr_scanned += scanned;
> return count;
> --
> 2.32.0
>

Re: [Intel-gfx] [PATCH 08/19] drm/i915: Fix runtime pm handling in i915_gem_shrink

[Matthew Auld]

On Wed, 29 Sept 2021 at 09:37, Matthew Auld
 wrote:
>
> On Mon, 30 Aug 2021 at 13:10, Maarten Lankhorst
>  wrote:
> >
> > We forgot to call intel_runtime_pm_put on error, fix it!
> >
> > Signed-off-by: Maarten Lankhorst 
> > Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
> > Cc: Thomas Hellström 
> > Cc: Daniel Vetter 
> > Cc:  # v5.13+
>
> How does the err handling work? gem_shrink is meant to return the
> number of pages reclaimed which is an unsigned long, and yet we are
> also just returning the err here? Fortunately it looks like nothing is
> calling gem_shrinker with an actual ww context, so nothing will hit
> this yet? I think the interface needs to be reworked or something.

Can we just remove the ww context argument, or is that needed for
something in the future?

>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > index e382b7f2353b..5ab136ffdeb2 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> > @@ -118,7 +118,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
> > intel_wakeref_t wakeref = 0;
> > unsigned long count = 0;
> > unsigned long scanned = 0;
> > -   int err;
> > +   int err = 0;
> >
> > /* CHV + VTD workaround use stop_machine(); need to trylock 
> > vm->mutex */
> > bool trylock_vm = !ww && intel_vm_no_concurrent_access_wa(i915);
> > @@ -242,12 +242,15 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
> > list_splice_tail(&still_in_list, phase->list);
> > spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
> > if (err)
> > -   return err;
> > +   break;
> > }
> >
> > if (shrink & I915_SHRINK_BOUND)
> > intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >
> > +   if (err)
> > +   return err;
> > +
> > if (nr_scanned)
> > *nr_scanned += scanned;
> > return count;
> > --
> > 2.32.0
> >

Re: [Intel-gfx] [PATCH 08/19] drm/i915: Fix runtime pm handling in i915_gem_shrink

[Maarten Lankhorst]

Op 29-09-2021 om 10:37 schreef Matthew Auld:
> On Mon, 30 Aug 2021 at 13:10, Maarten Lankhorst
>  wrote:
>> We forgot to call intel_runtime_pm_put on error, fix it!
>>
>> Signed-off-by: Maarten Lankhorst 
>> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
>> Cc: Thomas Hellström 
>> Cc: Daniel Vetter 
>> Cc:  # v5.13+
> How does the err handling work? gem_shrink is meant to return the
> number of pages reclaimed which is an unsigned long, and yet we are
> also just returning the err here? Fortunately it looks like nothing is
> calling gem_shrinker with an actual ww context, so nothing will hit
> this yet? I think the interface needs to be reworked or something.

We should probably make it signed in the future when used.
It should never hit the LONG_MAX limit, since max value returned would be 
ULONG_MAX >> PAGE_SHIFT,
assuming the entire address space is filled with evictable buffers.

I've kept the ww lock, in case we want to evict in the future. Without ww 
context the buffers
are trylocked, with ww we can evict the entire address space as much as 
possible.
In most cases we only want to evict idle objects, in that case no ww is needed.

Pushed just this patch, thanks for feedback. :)

~Maarten

[Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin, v2.

[Maarten Lankhorst]

Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.

I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.

Changes since v1:
- Fix using the wrong pointer to retrieve error code (Julia)

Signed-off-by: Maarten Lankhorst 
Reported-by: kernel test robot 
Reported-by: Julia Lawall 
---
 drivers/gpu/drm/i915/display/intel_dpt.c | 40 +++-
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e..8f7b1f7534a4 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -121,32 +121,42 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
intel_wakeref_t wakeref;
struct i915_vma *vma;
void __iomem *iomem;
+   struct i915_gem_ww_ctx ww;
+   int err;
 
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
atomic_inc(&i915->gpu_error.pending_fb_pin);
 
-   vma = i915_gem_object_ggtt_pin(dpt->obj, NULL, 0, 4096,
-  HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
-   if (IS_ERR(vma))
-   goto err;
+   for_i915_gem_ww(&ww, err, true) {
+   err = i915_gem_object_lock(dpt->obj, &ww);
+   if (err)
+   continue;
 
-   iomem = i915_vma_pin_iomap(vma);
-   i915_vma_unpin(vma);
-   if (IS_ERR(iomem)) {
-   vma = ERR_CAST(iomem);
-   goto err;
-   }
+   vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
+ HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   continue;
+   }
+
+   iomem = i915_vma_pin_iomap(vma);
+   i915_vma_unpin(vma);
 
-   dpt->vma = vma;
-   dpt->iomem = iomem;
+   if (IS_ERR(iomem)) {
+   err = PTR_ERR(iomem);
+   continue;
+   }
 
-   i915_vma_get(vma);
+   dpt->vma = vma;
+   dpt->iomem = iomem;
+
+   i915_vma_get(vma);
+   }
 
-err:
atomic_dec(&i915->gpu_error.pending_fb_pin);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
 
-   return vma;
+   return err ? ERR_PTR(err) : vma;
 }
 
 void intel_dpt_unpin(struct i915_address_space *vm)
-- 
2.33.0

Re: [Intel-gfx] [PATCH v2] drm/i915: Update memory bandwidth formulae

[Jani Nikula]

On Tue, 28 Sep 2021, Radhakrishna Sripada  
wrote:
> The formulae has been updated to include more variables. Make
> sure the code carries the same.
>
> Bspec: 64631
>
> v2: Make GEN11 follow the default route and fix calculation of
> maxdebw(RK)
>
> Cc: Ville Syrjälä 
> Suggested-by: Matt Roper 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 71 +++--
>  1 file changed, 55 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 4b94256d7319..d24b2000bc3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -27,6 +27,9 @@ struct intel_qgv_info {
>   u8 num_points;
>   u8 num_psf_points;
>   u8 t_bl;
> + u8 max_numchannels;
> + u8 channel_width;
> + u8 deinterleave;
>  };
>  
>  static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
> @@ -137,6 +140,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>  {
>   const struct dram_info *dram_info = &dev_priv->dram_info;
>   int i, ret;
> + bool is_y_tile = true; /* assume y tile may be used */
>  
>   qi->num_points = dram_info->num_qgv_points;
>   qi->num_psf_points = dram_info->num_psf_gv_points;
> @@ -144,10 +148,31 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>   if (DISPLAY_VER(dev_priv) == 12)
>   switch (dram_info->type) {
>   case INTEL_DRAM_DDR4:
> - qi->t_bl = 4;
> + qi->t_bl = is_y_tile ? 8 : 4;
> + qi->max_numchannels = 2;
> + qi->channel_width = 64;
> + qi->deinterleave = is_y_tile ? 1 : 2;
>   break;
>   case INTEL_DRAM_DDR5:
> - qi->t_bl = 8;
> + qi->t_bl = is_y_tile ? 16 : 8;
> + qi->max_numchannels = 4;
> + qi->channel_width = 32;
> + qi->deinterleave = is_y_tile ? 1 : 2;
> + break;
> + case INTEL_DRAM_LPDDR4:
> + if (IS_ROCKETLAKE(dev_priv)) {
> + qi->t_bl = 8;
> + qi->max_numchannels = 4;
> + qi->channel_width = 32;
> + qi->deinterleave = 2;
> + break;
> + }
> + fallthrough;

Just a drive-by comment, the fallthrough; line needs more indent.

BR,
Jani.

> + case INTEL_DRAM_LPDDR5:
> + qi->t_bl = 16;
> + qi->max_numchannels = 8;
> + qi->channel_width = 16;
> + qi->deinterleave = is_y_tile ? 2 : 4;
>   break;
>   default:
>   qi->t_bl = 16;
> @@ -263,12 +288,13 @@ static const struct intel_sa_info adlp_sa_info = {
>  static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
> intel_sa_info *sa)
>  {
>   struct intel_qgv_info qi = {};
> - bool is_y_tile = true; /* assume y tile may be used */
> + const struct dram_info *dram_info = &dev_priv->dram_info;
>   int num_channels = max_t(u8, 1, dev_priv->dram_info.num_channels);
> - int deinterleave;
>   int ipqdepth, ipqdepthpch;
>   int dclk_max;
> - int maxdebw;
> + int maxdebw, peakbw;
> + int clperchgroup;
> + int num_groups = ARRAY_SIZE(dev_priv->max_bw);
>   int i, ret;
>  
>   ret = icl_get_qgv_points(dev_priv, &qi);
> @@ -278,22 +304,38 @@ static int icl_get_bw_info(struct drm_i915_private 
> *dev_priv, const struct intel
>   return ret;
>   }
>  
> - deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
> - dclk_max = icl_sagv_max_dclk(&qi);
> + if (dram_info->type == INTEL_DRAM_LPDDR4 || dram_info->type == 
> INTEL_DRAM_LPDDR5)
> + num_channels *= 2;
> +
> + if (num_channels < qi.max_numchannels && DISPLAY_VER(dev_priv) >= 12)
> + qi.deinterleave = DIV_ROUND_UP(qi.deinterleave, 2);
> +
> + num_channels = min_t(u8, num_channels, qi.max_numchannels);
> + dclk_max = icl_calc_bw(icl_sagv_max_dclk(&qi), 16, 1);
>  
>   ipqdepthpch = 16;
>  
> - maxdebw = min(sa->deprogbwlimit * 1000,
> -   icl_calc_bw(dclk_max, 16, 1) * 6 / 10); /* 60% */
> + peakbw = num_channels * DIV_ROUND_UP(qi.deinterleave, 8) * dclk_max;
> + maxdebw = min(sa->deprogbwlimit * 1000, peakbw * 6 / 10); /* 60% */
>   ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
> + /*
> +  * clperchgroup = 4kpagespermempage * clperchperblock,
> +  * clperchperblock = 8 /num_channels * interleave
> +  */
> + clperchgroup = 4 * DIV_ROUND_UP(8, num_channels) * qi.deinterleave;
>  
> - for (i = 0; i < ARRA

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/dp: Add Additional DP2 Headers (rev2)

[Jani Nikula]

On Tue, 28 Sep 2021, "Zuo, Jerry"  wrote:
> [AMD Official Use Only]
>
> Hi:
>
> I don’t think this failure is related to the patch. Please help to
> confirm.

It's not, sorry for the noise.

BR,
Jani.


>
> Regards,
> Jerry
>
> From: Patchwork 
> Sent: September 27, 2021 7:51 PM
> To: Zuo, Jerry 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.IGT: failure for drm/dp: Add Additional DP2 Headers (rev2)
>
> Patch Details
> Series:
> drm/dp: Add Additional DP2 Headers (rev2)
> URL:
> https://patchwork.freedesktop.org/series/95104/
> State:
> failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21169/index.html
> CI Bug Log - changes from CI_DRM_10648_full -> Patchwork_21169_full
> Summary
>
> FAILURE
>
> Serious unknown changes coming with Patchwork_21169_full absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21169_full, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in 
> Patchwork_21169_full:
>
> IGT changes
> Possible regressions
>
>   *   igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt:
>
>  *   shard-iclb: 
> PASS
>  -> 
> FAIL
>
>   *   igt@kms_sequence@get-idle:
>
>  *   shard-tglb: 
> PASS
>  -> 
> INCOMPLETE
>
> Known issues
>
> Here are the changes found in Patchwork_21169_full that come from known 
> issues:
>
> IGT changes
> Issues hit
>
>   *   igt@gem_ctx_persistence@legacy-engines-queued:
>
>  *   shard-snb: NOTRUN -> 
> SKIP
>  ([fdo#109271] / [i915#1099]) +3 similar iss

Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend

[Thomas Hellström]

On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> For cached objects we can allocate our pages directly in shmem. This
> should make it possible(in a later patch) to utilise the existing
> i915-gem shrinker code for such objects. For now this is still
> disabled.

Some minor comments below, with those either fixed or deemed
unnecessary, 
Reviewed-by: Thomas Hellström 




> 
> v2(Thomas):
>   - Add optional try_to_writeback hook for objects. Importantly we
> need
>     to check if the object is even still shrinkable; in between us
>     dropping the shrinker LRU lock and acquiring the object lock it
> could for
>     example have been moved. Also we need to differentiate between
>     "lazy" shrinking and the immediate writeback mode. Also later we
> need to
>     handle objects which don't even have mm.pages, so bundling this
> into
>     put_pages() would require somehow handling that edge case, hence
>     just letting the ttm backend handle everything in
> try_to_writeback
>     doesn't seem too bad.
> v3(Thomas):
>   - Likely a bad idea to touch the object from the unpopulate hook,
>     since it's not possible to hold a reference, without also
> creating
>     circular dependency, so likely this is too fragile. For now just
>     ensure we at least mark the pages as dirty/accessed when called
> from the
>     shrinker on WILLNEED objects.
>   - s/try_to_writeback/shrinker_release_pages, since this can do more
>     than just writeback.
>   - Get rid of do_backup boolean and just set the SWAPPED flag prior
> to
>     calling unpopulate.
>   - Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk,
> since
>     these just get skipped anyway. We can try to come up with
> something
>     better later.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Christian König 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.h    |   8 +
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 +
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  14 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  17 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 240
> --
>  5 files changed, 245 insertions(+), 36 deletions(-)
> 
> 

...

> +
> +   err = dma_map_sg_attrs(i915_tt->dev,
> +  st->sgl, st->nents,
> +  PCI_DMA_BIDIRECTIONAL,

nit: Since this is a dma api call, should we use DMA_BIDIRECTIONAL
instead of PCI_DMA_BIDIRECTIONAL? DMA_BIDIRECTIONAL is used elsewhere
in this file, but not throughout the driver IIRC.

> +  DMA_ATTR_SKIP_CPU_SYNC |
> +  DMA_ATTR_NO_KERNEL_MAPPING |
> +  DMA_ATTR_NO_WARN);
> +   if (err <= 0) {
> +   err = -EINVAL;
> +   goto err_free_st;
> +   }
> +
> +   i = 0;
> +   for_each_sgt_page(page, sgt_iter, st)
> +   ttm->pages[i++] = page;
> +
> +   if (ttm->page_flags & TTM_TT_FLAG_SWAPPED)
> +   ttm->page_flags &= ~TTM_TT_FLAG_SWAPPED;
> +
> +   i915_tt->cached_st = st;
> +   return 0;
> +
> +err_free_st:
> +   shmem_free_st(st, filp->f_mapping, false, false);
> +   return err;
> +}
> +
> +static void i915_ttm_tt_shmem_unpopulate(struct ttm_tt *ttm)
> +{
> +   struct i915_ttm_tt *i915_tt = container_of(ttm,
> typeof(*i915_tt), ttm);
> +   bool backup = ttm->page_flags & TTM_TT_FLAG_SWAPPED;
> +
> +   dma_unmap_sg(i915_tt->dev, i915_tt->cached_st->sgl,
> +    i915_tt->cached_st->nents,
> +    PCI_DMA_BIDIRECTIONAL);

Same here. 
> +
> +   shmem_free_st(fetch_and_zero(&i915_tt->cached_st),
> + file_inode(i915_tt->filp)->i_mapping,
> + backup, backup);
> +}
> +
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object
> *bo,
>  uint32_t page_flags)
>  {
> struct ttm_resource_manager *man =
> ttm_manager_type(bo->bdev, bo->resource->mem_type);
> struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> +   enum ttm_caching caching = i915_ttm_select_tt_caching(obj);
> struct i915_ttm_tt *i915_tt;
> int ret;
>  
> @@ -196,36 +279,62 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> ttm_buffer_object *bo,
>     man->use_tt)
> page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
>  
> -   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
> - i915_ttm_select_tt_caching(obj));
> -   if (ret) {
> -   kfree(i915_tt);
> -   return NULL;
> +   if (i915_gem_object_is_shrinkable(obj) && caching ==
> ttm_cached) {
> +   page_flags |= TTM_TT_FLAG_EXTERNAL |
> + TTM_TT_FLAG_EXTERNAL_MAPPABLE;
> +   i915_tt->is_shmem = true;
> }
>  
> +   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching);
> +   if (ret)
>

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

[Ville Syrjälä]

On Thu, Apr 01, 2021 at 02:49:13PM -0700, Navare, Manasi wrote:
> On Fri, Mar 26, 2021 at 06:15:22PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> > > > > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > > > > > On Fri, Mar 19, 2021 at 01:54:13PM -0700, Navare, Manasi wrote:
> > > > > > > On Fri, Mar 19, 2021 at 04:56:24PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Thu, Mar 18, 2021 at 04:01:26PM -0700, Navare, Manasi wrote:
> > > > > > > > > So basically we see this warning only in case of bigjoiner 
> > > > > > > > > when
> > > > > > > > > drm_atomic_check gets called without setting the 
> > > > > > > > > state->allow_modeset flag.
> > > > > > > > 
> > > > > > > > Considering the code is 'WARN(!state->allow_modeset, ...' that
> > > > > > > > fact should be rather obvious.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So do you think that in i915, in 
> > > > > > > > > intel_atomic_check_bigjoiner() we should only
> > > > > > > > > steal the crtc when allow_modeset flag is set in state?
> > > > > > > > 
> > > > > > > > No. If you fully read drm_atomic_check_only() you will observe
> > > > > > > > that it will reject any commit w/ allow_modeset==false which 
> > > > > > > > needs a modeset. And it does that before the WARN.
> > > > > > > > 
> > > > > > > > So you're barking up the wrong tree here. The problem I think
> > > > > > > > is that you're just computing requested_crtcs wrong.
> > > > > > > 
> > > > > > > So here in this case, requested CRTC = 0x1 since it requests 
> > > > > > > modeset on CRTC 0
> > > > > > > Now in teh atomic check, it steals the slave CRTC 1 and hence 
> > > > > > > affected CRTC comes out
> > > > > > > as 0x3 and hence the mismatch.
> > > > > > 
> > > > > > Hmm. How can it be 0x3 if we filtered out the uapi.enable==false 
> > > > > > case?
> > > > > > 
> > > > > 
> > > > > Yes if I add that condition like in this patch then it correctly 
> > > > > calculates
> > > > > the affected crtc bitmask as only 0x1 since it doesnt include the 
> > > > > slave crtc.
> > > > > So with this patch, requested crtc = 0x 1, affected crtc = 0x1
> > > > > 
> > > > > If this looks good then this fixes our bigjoiner warnings.
> > > > > Does this patch look good to you as is then?
> > > > 
> > > > I think you still need to fix the requested_crtcs calculation.
> > > 
> > > We calculate requested crtc at the beginning :
> > > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > requested_crtc |= drm_crtc_mask(crtc);
> > > 
> > > Are you suggesting adding this to after:
> > >  if (config->funcs->atomic_check) {
> > > ret = config->funcs->atomic_check(state->dev, state);
> > > 
> > > if (ret) {
> > > DRM_DEBUG_ATOMIC("atomic driver check for %p 
> > > failed: %d\n",
> > >  state, ret);
> > > return ret;
> > > }
> > >   requested_crtc |= drm_crtc_mask(crtc);// Here it will have 
> > > requested crtc = 0x11
> > > }
> > > 
> > > in this case here the state should already have master crtc 0 and slave 
> > > crtc 1
> > > and that requested crtc should already be 0x11
> > > 
> > > Then in that case we dont need any special check for calculating affected 
> > > crtc, that also will be 0x11
> > 
> > All I'm saying is that you're currently calculating requested_crtcs and
> > affected_crtcs differently. So I'm not at all surprised that they might
> > not match.
> >
> 
> I dont get your point yet.
> requested crtc is calculated before the atomic check call and we dont check 
> for crtc uapi.enable to be true.
> And hence requested crtc  = CRTC 0 = 0x2
> After I added the check in this patch where affected crtc will include only 
> the crtcs that have uapi.enable = true
> then  it perfectly matches the requested crtc and return 0x2 but without this 
> check when the calculation of
> requested and affected crtc is the same is where we see the affected crtc = 
> CRTC 0 and 1 = 0x3
> 
> So when the calculation is different infcat we dont see the mismatch
> 
> What is your point here?

Try doing an atomic commit wiht both crtcs already added in by 
userspace. I think that will still WARN.

-- 
Ville Syrjälä
Intel

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Disable cursor clock gating in HDR mode (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev6)
URL   : https://patchwork.freedesktop.org/series/91674/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10659 -> Patchwork_21185


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-pnv-d510/igt@amdgpu/amd_pr...@amd-to-i915.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#1155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#4103]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#3301])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][13] ([i915#4140]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/fi-pnv-d510/igt@i915_selftest@l...@requests.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3918]: https://gitlab.freedesktop.org/drm/intel/issues/3918
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4140]: https://gitlab.freedesktop.org/drm/intel/issues/4140


Participating hosts (33 -> 29)
--

  Additional (1): fi-tgl-1115g4 
  Missing(5)

Re: [Intel-gfx] [PATCH v5 11/13] drm/i915/ttm: make evicted shmem pages visible to the shrinker

[Thomas Hellström]

On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> We currently just evict lmem objects to system memory when under
> memory
> pressure, and in the next patch we want to use the shmem backend even
> for this case. For this case we lack the usual object mm.pages, which
> effectively hides the pages from the i915-gem shrinker, until we
> actually "attach" the TT to the object, or in the case of lmem-only
> objects it just gets migrated back to lmem when touched again.
> 
> For all cases we can just adjust the i915 shrinker LRU each time we
> also
> adjust the TTM LRU. The two cases we care about are:
> 
>   1) When something is moved by TTM, including when initially
> populating
>  an object. Importantly this covers the case where TTM moves
> something from
>  lmem <-> smem, outside of the normal get_pages() interface,
> which
>  should still ensure the shmem pages underneath are reclaimable.
> 
>   2) When calling into i915_gem_object_unlock(). The unlock should
>  ensure the object is removed from the shinker LRU, if it was
> indeed
>  swapped out, or just purged, when the shrinker drops the object
> lock.
> 
> We can optimise this(if needed) by tracking if the object is already
> visible to the shrinker(protected by the object lock), so we don't
> touch
> the shrinker LRU more than needed.
> 
> v2(Thomas)
>   - Handle managing the shrinker LRU in adjust_lru, where it is
> always
>     safe to touch the object.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.h   |  1 +
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 29 +++---
> --
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 28 +++---
> -
>  3 files changed, 46 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 1c9a1d8d3434..640dfbf1f01e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -523,6 +523,7 @@ i915_gem_object_pin_to_display_plane(struct
> drm_i915_gem_object *obj,
>  
>  void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object
> *obj);
>  void i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
> +void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
>  void i915_gem_object_make_purgeable(struct drm_i915_gem_object
> *obj);
>  
>  static inline bool cpu_write_needs_clflush(struct
> drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index 0440696f786a..4b6b2bb6f180 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -487,13 +487,12 @@ void i915_gem_object_make_unshrinkable(struct
> drm_i915_gem_object *obj)
> spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
>  }
>  
> -static void __i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj,
> - struct list_head *head)
> +static void ___i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj,
> +  struct list_head
> *head)
>  {
> struct drm_i915_private *i915 = obj_to_i915(obj);
> unsigned long flags;
>  
> -   GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> if (!i915_gem_object_is_shrinkable(obj))
> return;
>  
> @@ -512,6 +511,21 @@ static void
> __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
> spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
>  }
>  
> +/**
> + * __i915_gem_object_make_shrinkable - Move the object to the tail
> of the
> + * shrinkable list. Objects on this list might be swapped out. Used
> with
> + * WILLNEED objects.
> + * @obj: The GEM object.
> + *
> + * DO NOT USE. This is intended to be called on very special objects
> that don't
> + * yet have mm.pages, but are guaranteed to have potentially
> reclaimable pages
> + * underneath.
> + */
> +void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj)
> +{
> +   ___i915_gem_object_make_shrinkable(obj,
> +  &obj_to_i915(obj)-
> >mm.shrink_list);
> +}
>  
>  /**
>   * i915_gem_object_make_shrinkable - Move the object to the tail of
> the
> @@ -523,8 +537,8 @@ static void
> __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj,
>   */
>  void i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj)
>  {
> -   __i915_gem_object_make_shrinkable(obj,
> - &obj_to_i915(obj)-
> >mm.shrink_list);
> +   GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> +   __i915_gem_object_make_shrinkable(obj);
>  }
>  
>  /**
> @@ -538,6 +552,7 @@ void i915_gem_object_make_shrinkable(struct
> drm_i915_gem_object *obj)
>   */
>  void i915_gem_object_make_purgeable(struct drm_

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add ww context to intel_dpt_pin, v2.

[Patchwork]

== Series Details ==

Series: drm/i915: Add ww context to intel_dpt_pin, v2.
URL   : https://patchwork.freedesktop.org/series/95200/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10659 -> Patchwork_21186


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([fdo#109315])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-pnv-d510/igt@amdgpu/amd_pr...@amd-to-i915.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][4] -> [FAIL][5] ([i915#1888])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][6] ([i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#1155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#4103]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html

  * igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#3301])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][13] ([i915#4140]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/fi-pnv-d510/igt@i915_selftest@l...@requests.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4140]: https://gitlab.freedesktop.org/drm/intel/issues/4140


Participating hosts (33 -> 28)
--

  Additional (1): fi-tgl-1115g4 
  Missing(6): bat-adls-5 bat-dg1-6 fi-bsw-cyan fi-icl-u2 bat-adlp-4 
bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10659 -> Patchwork_21186

  CI-20190529: 20190529
  CI_DRM_10659: ef0ee818d075c59b51afa26326cd780e7b34ae10 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21186: 3b38e06957a60c04130c9ef47666834439eebd31 @ 
git://an

Re: [Intel-gfx] [PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem

[Thomas Hellström]

On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> This should let us do an accelerated copy directly to the shmem pages
> when temporarily moving lmem-only objects, where the i915-gem
> shrinker
> can later kick in to swap out the pages, if needed.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 194e5f1deda8..46d57541c0b2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -134,11 +134,11 @@ static enum ttm_caching
>  i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
>  {
> /*
> -    * Objects only allowed in system get cached cpu-mappings.
> -    * Other objects get WC mapping for now. Even if in system.
> +    * Objects only allowed in system get cached cpu-mappings, or
> when
> +    * evicting lmem-only buffers to system for swapping. Other
> objects get
> +    * WC mapping for now. Even if in system.
>  */
> -   if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
> -   obj->mm.n_placements <= 1)
> +   if (obj->mm.n_placements <= 1)
> return ttm_cached;
>  
> return ttm_write_combined;

We should be aware that with TTM, even evicted bos can be mapped by
user-space while evicted, and this will appear to user-space like the
WC-mapped object suddenly became WB-mapped. But it appears like mesa
doesn't care about this as long as the mappings are fully coherent.

Reviewed-by: Thomas Hellström 

Re: [Intel-gfx] [PATCH v5 13/13] drm/i915/ttm: enable shmem tt backend

[Thomas Hellström]

On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> Turn on the shmem tt backend, and enable shrinking.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 46d57541c0b2..4ae630fbc5cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -1093,6 +1093,7 @@ static u64 i915_ttm_mmap_offset(struct
> drm_i915_gem_object *obj)
>  
>  static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
> .name = "i915_gem_object_ttm",
> +   .flags = I915_GEM_OBJECT_IS_SHRINKABLE,
>  
> .get_pages = i915_ttm_get_pages,
> .put_pages = i915_ttm_put_pages,

Reviewed-by: Thomas Hellström 

Now that BAT is running a DG1 again, it might be worth to give the
series a rerun. Perhaps with the "rework object initialization
slightly" as a HAX patch to unblock the mman + following selftest.

/Thomas

Re: [Intel-gfx] [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access

[Christian König]

Am 27.09.21 um 18:14 schrieb Matthew Auld:

On Mon, 27 Sept 2021 at 12:47, Christian König  wrote:

Any objections that I just push patches 1-7 to drm-misc-next?

Please go ahead Christian. Thanks.


Well I've pushed patches #1-#4 because #5 won't apply on current 
drm-misc-next (some conflict in i915).


Could you rebase this an/or request backmerging of drm-next into 
drm-misc-next when potential i915 prerequisites have landed there.


Thanks,
Christian.




Christian.

Am 27.09.21 um 13:41 schrieb Matthew Auld:

In commit:

commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling 
Date:   Thu Jul 13 17:01:16 2017 -0400

  drm/ttm: Implement vm_operations_struct.access v2

we added the vm_access hook, where we also directly call tt_swapin for
some reason. If something is swapped-out then the ttm_tt must also be
unpopulated, and since access_kmap should also call tt_populate, if
needed, then swapping-in will already be handled there.

If anything, calling tt_swapin directly here would likely always fail
since the tt->pages won't yet be populated, or worse since the tt->pages
array is never actually cleared in unpopulate this might lead to a nasty
uaf.

Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
Reviewed-by: Thomas Hellström 
Reviewed-by: Christian König 
---
   drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
   1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..5b9b7fd01a69 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned 
long addr,

   switch (bo->resource->mem_type) {
   case TTM_PL_SYSTEM:
- if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
- ret = ttm_tt_swapin(bo->ttm);
- if (unlikely(ret != 0))
- return ret;
- }
   fallthrough;
   case TTM_PL_TT:
   ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);

Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: Handle frontbuffer rendering when PSR2 selective fetch is enabled

[Gwan-gyeong Mun]

Looks good to me.
Reviewed-by: Gwan-gyeong Mun 

On 9/23/21 10:46 PM, José Roberto de Souza wrote:

CURSURFLIVE writes has no affect when PSR2 selective fetch is enabled,
the right thing to do here would be calculate the damaged area and
program PSR2 selective fetch registers properly during vblank but
we can't do that due to performance reasons.

So for now we can workaround and offer proper rendering by disabling
PSR2 and enabling in the worker a few miliseconds later if there is
no other frontbuffer rendering.

This approach will eat some of the PSR2 power savings when userspace
makes use of frontbuffer rendering but that is the solution that we
can offer to enable PSR2 selective fetch right now while we work in
the proper solution for frontbuffer rendering and PSR2.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index a2e4ef42be60a..ba2da689920f9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1413,6 +1413,12 @@ static void psr_force_hw_tracking_exit(struct intel_dp 
*intel_dp)
  {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
  
+	/* CURSURFLIVE has no effect when Selective fetch is enabled */

+   if (intel_dp->psr.psr2_sel_fetch_enabled) {
+   intel_psr_exit(intel_dp);
+   return;
+   }
+
/*
 * Display WA #0884: skl+
 * This documented WA for bxt can be safely applied

Re: [Intel-gfx] [PATCH v5 10/13] drm/i915: try to simplify make_{un}shrinkable

[Thomas Hellström]

On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
> Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
> update the shrinker visible lists immediately. This at least
> simplifies
> the next patch, and does make the behaviour more obvious. The
> potential
> downside is that make_unshrinkable now grabs a global lock even when
> the
> object itself is no longer shrinkable(transitioning from purgeable <-
> >
> shrinkable doesn't seem to be a thing), for example in the ppGTT
> insertion paths we should now be careful not to needlessly call
> make_unshrinkable multiple times. Outside of that there is some
> fallout
> in intel_context which relies on nesting calls to shrink_pin.
> 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 

Hmm. One thing that worries me a bit here: Let's say we have, for
example an LMEM context state, and TTM has it made unshrinkable. Then
the context becomes active and calls _make_unshrinkable again. And when
it retires it callse _make_shrinkable. Doesn't it end up on the
shrinker list at that point, even if still in LMEM?

/Thomas

[Intel-gfx] [PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/

[Matthew Auld]

It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.

v2(Christian):
  - Rename these to TTM_TT_FLAGS_*
  - Fix up all the holes in the flag values

Suggested-by: Christian König 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
Acked-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c |  6 +++---
 drivers/gpu/drm/nouveau/nouveau_bo.c|  4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c |  8 
 drivers/gpu/drm/ttm/ttm_bo.c|  4 ++--
 drivers/gpu/drm/ttm/ttm_bo_util.c   |  4 ++--
 drivers/gpu/drm/ttm/ttm_bo_vm.c |  2 +-
 drivers/gpu/drm/ttm/ttm_pool.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c| 24 
 include/drm/ttm/ttm_device.h|  2 +-
 include/drm/ttm/ttm_tt.h| 18 +-
 11 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 60b12bb55244..e8d70b6e6737 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
DRM_ERROR("failed to pin userptr\n");
return r;
}
-   } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+   } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
if (!ttm->sg) {
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
 
-   if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+   if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return 0;
 
ret = ttm_pool_alloc(&adev->mman.bdev.pool, ttm, ctx);
@@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device 
*bdev,
return;
}
 
-   if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+   if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return;
 
for (i = 0; i < ttm->num_pages; ++i)
@@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct ttm_buffer_object 
*bo,
return -ENOMEM;
}
 
-   /* Set TTM_PAGE_FLAG_SG before populate but after create. */
-   bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
+   /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
+   bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
 
gtt = (void *)bo->ttm;
gtt->userptr = addr;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f0a61a9474fc..8beef57ba52b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -182,7 +182,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
 
if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
man->use_tt)
-   page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+   page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
 
ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
  i915_ttm_select_tt_caching(obj));
@@ -451,7 +451,7 @@ static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
 
-   if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+   if (ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))
return 0;
 
intel_engine_pm_get(i915->gt.migrate.context->engine);
@@ -525,7 +525,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool 
evict,
 
/* Populate ttm with pages if needed. Typically system memory. */
if (bo->ttm && (dst_man->use_tt ||
-   (bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED))) {
+   (bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED))) {
ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 33dca2565cca..b2c7e0802ac3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1249,7 +1249,7 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
struct device *dev;
-   bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
+   bool slave = !!(ttm->page_flags & TTM_TT_FLAG_EXTERNAL);
 
if (ttm_tt_is_populated(ttm))
return 0;
@@ -1272,7 +1272,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_device *bdev,

[Intel-gfx] [PATCH 2/3] drm/ttm: add some kernel-doc for TTM_TT_FLAG_*

[Matthew Auld]

Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist.

v2(Christian):
  - Add a note that FLAG_SWAPPED shouldn't need to be touched by drivers.
  - Mention what FLAG_POPULATED does.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
Reviewed-by: Christian König 
---
 include/drm/ttm/ttm_tt.h | 60 +++-
 1 file changed, 41 insertions(+), 19 deletions(-)

diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index b023cd58ff38..86d74069be3e 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -38,35 +38,57 @@ struct ttm_resource;
 struct ttm_buffer_object;
 struct ttm_operation_ctx;
 
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL   (1 << 2)
-
-#define TTM_TT_FLAG_PRIV_POPULATED  (1 << 31)
-
 /**
- * struct ttm_tt
- *
- * @pages: Array of pages backing the data.
- * @page_flags: see TTM_TT_FLAG_*
- * @num_pages: Number of pages in the page array.
- * @sg: for SG objects via dma-buf
- * @dma_address: The DMA (bus) addresses of the pages
- * @swap_storage: Pointer to shmem struct file for swap storage.
- * @pages_list: used by some page allocation backend
- * @caching: The current caching state of the pages, see enum ttm_caching.
- *
- * This is a structure holding the pages, caching- and aperture binding
- * status for a buffer object that isn't backed by fixed (VRAM / AGP)
+ * struct ttm_tt - This is a structure holding the pages, caching- and aperture
+ * binding status for a buffer object that isn't backed by fixed (VRAM / AGP)
  * memory.
  */
 struct ttm_tt {
+   /** @pages: Array of pages backing the data. */
struct page **pages;
+   /**
+* @page_flags: The page flags.
+*
+* Supported values:
+*
+* TTM_TT_FLAG_SWAPPED: Set by TTM when the pages have been unpopulated
+* and swapped out by TTM.  Calling ttm_tt_populate() will then swap the
+* pages back in, and unset the flag. Drivers should in general never
+* need to touch this.
+*
+* TTM_TT_FLAG_ZERO_ALLOC: Set if the pages will be zeroed on
+* allocation.
+*
+* TTM_TT_FLAG_EXTERNAL: Set if the underlying pages were allocated
+* externally, like with dma-buf or userptr. This effectively disables
+* TTM swapping out such pages.  Also important is to prevent TTM from
+* ever directly mapping these pages.
+*
+* Note that enum ttm_bo_type.ttm_bo_type_sg objects will always enable
+* this flag.
+*
+* TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is
+* set by TTM after ttm_tt_populate() has successfully returned, and is
+* then unset when TTM calls ttm_tt_unpopulate().
+*/
+#define TTM_TT_FLAG_SWAPPED(1 << 0)
+#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
+#define TTM_TT_FLAG_EXTERNAL   (1 << 2)
+
+#define TTM_TT_FLAG_PRIV_POPULATED  (1 << 31)
uint32_t page_flags;
+   /** @num_pages: Number of pages in the page array. */
uint32_t num_pages;
+   /** @sg: for SG objects via dma-buf. */
struct sg_table *sg;
+   /** @dma_address: The DMA (bus) addresses of the pages. */
dma_addr_t *dma_address;
+   /** @swap_storage: Pointer to shmem struct file for swap storage. */
struct file *swap_storage;
+   /**
+* @caching: The current caching state of the pages, see enum
+* ttm_caching.
+*/
enum ttm_caching caching;
 };
 
-- 
2.26.3

[Intel-gfx] [PATCH 3/3] drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE

[Matthew Auld]

In commit:

commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom 
Date:   Fri Jan 3 11:17:18 2014 +0100

drm/ttm: Refuse to fault (prime-) imported pages

we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userptr). In the next patch we
want to introduce a shmem_tt backend, which should follow all the
existing rules with TTM_PAGE_FLAG_EXTERNAL, since it will need to handle
swapping itself, but with the above mapping restriction lifted.

v2(Christian):
  - Don't OR together EXTERNAL and EXTERNAL_MAPPABLE in the definition
of EXTERNAL_MAPPABLE, just leave it the caller to handle this
correctly, otherwise we might encounter subtle issues.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c |  6 --
 drivers/gpu/drm/ttm/ttm_tt.c|  3 +++
 include/drm/ttm/ttm_tt.h| 19 ---
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 950f4f132802..33680c94127c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -163,8 +163,10 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
 * (if at all) by redirecting mmap to the exporter.
 */
if (bo->ttm && (bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL)) {
-   dma_resv_unlock(bo->base.resv);
-   return VM_FAULT_SIGBUS;
+   if (!(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE)) {
+   dma_resv_unlock(bo->base.resv);
+   return VM_FAULT_SIGBUS;
+   }
}
 
return 0;
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 86f31fde6e35..7e83c00a3f48 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -84,6 +84,9 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
if (unlikely(bo->ttm == NULL))
return -ENOMEM;
 
+   WARN_ON(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL_MAPPABLE &&
+   !(bo->ttm->page_flags & TTM_TT_FLAG_EXTERNAL));
+
return 0;
 }
 
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 86d74069be3e..f20832139815 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -67,13 +67,26 @@ struct ttm_tt {
 * Note that enum ttm_bo_type.ttm_bo_type_sg objects will always enable
 * this flag.
 *
+* TTM_TT_FLAG_EXTERNAL_MAPPABLE: Same behaviour as
+* TTM_TT_FLAG_EXTERNAL, but with the reduced restriction that it is
+* still valid to use TTM to map the pages directly. This is useful when
+* implementing a ttm_tt backend which still allocates driver owned
+* pages underneath(say with shmem).
+*
+* Note that since this also implies TTM_TT_FLAG_EXTERNAL, the usage
+* here should always be:
+*
+*   page_flags = TTM_TT_FLAG_EXTERNAL |
+*TTM_TT_FLAG_EXTERNAL_MAPPABLE;
+*
 * TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is
 * set by TTM after ttm_tt_populate() has successfully returned, and is
 * then unset when TTM calls ttm_tt_unpopulate().
 */
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL   (1 << 2)
+#define TTM_TT_FLAG_SWAPPED(1 << 0)
+#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
+#define TTM_TT_FLAG_EXTERNAL   (1 << 2)
+#define TTM_TT_FLAG_EXTERNAL_MAPPABLE  (1 << 3)
 
 #define TTM_TT_FLAG_PRIV_POPULATED  (1 << 31)
uint32_t page_flags;
-- 
2.26.3

Re: [Intel-gfx] [PATCH 7/7] drm/i915/display: Enable PSR2 selective fetch by default

[Gwan-gyeong Mun]

Reviewed-by: Gwan-gyeong Mun 

On 9/23/21 10:46 PM, José Roberto de Souza wrote:

With all the past fixes now this feature is functional and can be
enabled by default in desktop enviroments that uses compositor.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/i915_params.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index f27eceb82c0f5..8d725b64592d8 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -55,7 +55,7 @@ struct drm_printer;
param(int, enable_fbc, -1, 0600) \
param(int, enable_psr, -1, 0600) \
param(bool, psr_safest_params, false, 0400) \
-   param(bool, enable_psr2_sel_fetch, false, 0400) \
+   param(bool, enable_psr2_sel_fetch, true, 0400) \
param(int, disable_power_well, -1, 0400) \
param(int, enable_ips, 1, 0600) \
param(int, invert_brightness, 0, 0600) \

[Intel-gfx] [PATCH v2 01/13] drm/i915/tc: Fix TypeC port init/resume time sanitization

[Imre Deak]

Atm during driver loading and system resume TypeC ports are accessed
before their HW/SW state is synced. Move the TypeC port sanitization to
the encoder's sync_state hook to fix this.

v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well
(Jose, Jani)

Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state 
during init/resume")
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/icl_dsi.c   | 10 --
 drivers/gpu/drm/i915/display/intel_ddi.c |  8 +++-
 drivers/gpu/drm/i915/display/intel_display.c | 20 +---
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 060bc8fb0d307..bd210166b0793 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1599,8 +1599,14 @@ static void gen11_dsi_sync_state(struct intel_encoder 
*encoder,
 const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   enum pipe pipe = intel_crtc->pipe;
+   struct intel_crtc *intel_crtc;
+   enum pipe pipe;
+
+   if (!crtc_state)
+   return;
+
+   intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   pipe = intel_crtc->pipe;
 
/* wa verify 1409054076:icl,jsl,ehl */
if (DISPLAY_VER(dev_priv) == 11 && pipe == PIPE_B &&
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a4667741d3548..04572ce6630f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3838,7 +3838,13 @@ void hsw_ddi_get_config(struct intel_encoder *encoder,
 static void intel_ddi_sync_state(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state)
 {
-   if (intel_crtc_has_dp_encoder(crtc_state))
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+   if (intel_phy_is_tc(i915, phy))
+   intel_tc_port_sanitize(enc_to_dig_port(encoder));
+
+   if (crtc_state && intel_crtc_has_dp_encoder(crtc_state))
intel_dp_sync_state(encoder, crtc_state);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 9e407760e51f6..5f241e2415cea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12285,18 +12285,16 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
readout_plane_state(dev_priv);
 
for_each_intel_encoder(dev, encoder) {
+   struct intel_crtc_state *crtc_state = NULL;
+
pipe = 0;
 
if (encoder->get_hw_state(encoder, &pipe)) {
-   struct intel_crtc_state *crtc_state;
-
crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
crtc_state = to_intel_crtc_state(crtc->base.state);
 
encoder->base.crtc = &crtc->base;
intel_encoder_get_config(encoder, crtc_state);
-   if (encoder->sync_state)
-   encoder->sync_state(encoder, crtc_state);
 
/* read out to slave crtc as well for bigjoiner */
if (crtc_state->bigjoiner) {
@@ -12311,6 +12309,9 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
encoder->base.crtc = NULL;
}
 
+   if (encoder->sync_state)
+   encoder->sync_state(encoder, crtc_state);
+
drm_dbg_kms(&dev_priv->drm,
"[ENCODER:%d:%s] hw state readout: %s, pipe %c\n",
encoder->base.base.id, encoder->base.name,
@@ -12593,17 +12594,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
intel_modeset_readout_hw_state(dev);
 
/* HW state is read out, now we need to sanitize this mess. */
-
-   /* Sanitize the TypeC port mode upfront, encoders depend on this */
-   for_each_intel_encoder(dev, encoder) {
-   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
-
-   /* We need to sanitize only the MST primary port. */
-   if (encoder->type != INTEL_OUTPUT_DP_MST &&
-   intel_phy_is_tc(dev_priv, phy))
-   intel_tc_port_sanitize(enc_to_dig_port(encoder));
-   }
-
get_encoder_power_domains(dev_priv);
 
if (HAS_PCH_IBX(dev_priv))
-- 
2.27.0

[Intel-gfx] [PATCH v2 04/13] drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY ownership

[Imre Deak]

On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode.
To avoid taking the PHY ownership and the following spurious "PHY sudden
disconnect" messages on this platform when connecting the PHY in TBT
mode, check if there is any DP-alt or legacy sink connected before
taking the ownership.

v2: (Jose)
- Fix debug message clarifying that a TBT sink can be connected.
- Add comments describing the PHY complete HW flag semantic differences
  between adl-p and other platforms.

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 0d3555437b0b1..4e5ff823a3a30 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -270,6 +270,14 @@ static u32 tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
return icl_tc_port_live_status_mask(dig_port);
 }
 
+/*
+ * Return the PHY status complete flag indicating that display can acquire the
+ * PHY ownership. The IOM firmware sets this flag when a DP-alt or legacy sink
+ * is connected and it's ready to switch the ownership to display. The flag
+ * will be left cleared when a TBT-alt sink is connected, where the PHY is
+ * owned by the TBT subsystem and so switching the ownership to display is not
+ * required.
+ */
 static bool icl_tc_phy_status_complete(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -288,6 +296,13 @@ static bool icl_tc_phy_status_complete(struct 
intel_digital_port *dig_port)
return val & DP_PHY_MODE_STATUS_COMPLETED(dig_port->tc_phy_fia_idx);
 }
 
+/*
+ * Return the PHY status complete flag indicating that display can acquire the
+ * PHY ownership. The IOM firmware sets this flag when it's ready to switch
+ * the ownership to display, regardless of what sink is connected (TBT-alt,
+ * DP-alt, legacy or nothing). For TBT-alt sinks the PHY is owned by the TBT
+ * subsystem and so switching the ownership to display is not required.
+ */
 static bool adl_tc_phy_status_complete(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -424,6 +439,7 @@ static void icl_tc_phy_connect(struct intel_digital_port 
*dig_port,
   int required_lanes)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   u32 live_status_mask;
int max_lanes;
 
if (!tc_phy_status_complete(dig_port)) {
@@ -432,6 +448,13 @@ static void icl_tc_phy_connect(struct intel_digital_port 
*dig_port,
goto out_set_tbt_alt_mode;
}
 
+   live_status_mask = tc_port_live_status_mask(dig_port);
+   if (!(live_status_mask & (BIT(TC_PORT_DP_ALT) | BIT(TC_PORT_LEGACY {
+   drm_dbg_kms(&i915->drm, "Port %s: PHY ownership not required 
(live status %02x)\n",
+   dig_port->tc_port_name, live_status_mask);
+   goto out_set_tbt_alt_mode;
+   }
+
if (!tc_phy_take_ownership(dig_port, true) &&
!drm_WARN_ON(&i915->drm, dig_port->tc_legacy_port))
goto out_set_tbt_alt_mode;
-- 
2.27.0

[Intel-gfx] [PATCH v2 07/13] drm/i915/tc: Add a mode for the TypeC PHY's disconnected state

[Imre Deak]

A follow-up change will start to disconnect/re-connect PHYs around AUX
transfers and modeset enable/disables. To prepare for that add a new
TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
domain status (no power domain in disconnected state, mode dependent
power domain in connected state).

v2: Move the !disconnected mode and phy-owned asserts in
__intel_tc_port_lock() later in the patchset, when the asserts will
hold. (Jose)

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.h |  1 +
 drivers/gpu/drm/i915/display/intel_tc.c  | 22 +---
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index d425ee77aad71..87b96fed5e0ba 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -270,6 +270,7 @@ enum tc_port {
 };
 
 enum tc_port_mode {
+   TC_PORT_DISCONNECTED,
TC_PORT_TBT_ALT,
TC_PORT_DP_ALT,
TC_PORT_LEGACY,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 6d0a1b376767a..62a3070abf0a6 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -12,13 +12,14 @@
 static const char *tc_port_mode_name(enum tc_port_mode mode)
 {
static const char * const names[] = {
+   [TC_PORT_DISCONNECTED] = "disconnected",
[TC_PORT_TBT_ALT] = "tbt-alt",
[TC_PORT_DP_ALT] = "dp-alt",
[TC_PORT_LEGACY] = "legacy",
};
 
if (WARN_ON(mode >= ARRAY_SIZE(names)))
-   mode = TC_PORT_TBT_ALT;
+   mode = TC_PORT_DISCONNECTED;
 
return names[mode];
 }
@@ -529,10 +530,11 @@ static void icl_tc_phy_disconnect(struct 
intel_digital_port *dig_port)
case TC_PORT_LEGACY:
case TC_PORT_DP_ALT:
tc_phy_take_ownership(dig_port, false);
-   dig_port->tc_mode = TC_PORT_TBT_ALT;
-   break;
+   fallthrough;
case TC_PORT_TBT_ALT:
-   /* Nothing to do, we stay in TBT-alt mode */
+   dig_port->tc_mode = TC_PORT_DISCONNECTED;
+   fallthrough;
+   case TC_PORT_DISCONNECTED:
break;
default:
MISSING_CASE(dig_port->tc_mode);
@@ -637,31 +639,34 @@ void intel_tc_port_sanitize(struct intel_digital_port 
*dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_encoder *encoder = &dig_port->base;
-   intel_wakeref_t tc_cold_wref;
int active_links = 0;
 
mutex_lock(&dig_port->tc_lock);
-   tc_cold_wref = tc_cold_block(dig_port);
 
-   dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
if (dig_port->dp.is_mst)
active_links = intel_dp_mst_encoder_active_links(dig_port);
else if (encoder->base.crtc)
active_links = to_intel_crtc(encoder->base.crtc)->active;
 
+   drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
if (active_links) {
+   intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port);
+
+   dig_port->tc_mode = intel_tc_port_get_current_mode(dig_port);
+
if (!icl_tc_phy_is_connected(dig_port))
drm_dbg_kms(&i915->drm,
"Port %s: PHY disconnected with %d active 
link(s)\n",
dig_port->tc_port_name, active_links);
intel_tc_port_link_init_refcount(dig_port, active_links);
+
+   tc_cold_unblock(dig_port, tc_cold_wref);
}
 
drm_dbg_kms(&i915->drm, "Port %s: sanitize mode (%s)\n",
dig_port->tc_port_name,
tc_port_mode_name(dig_port->tc_mode));
 
-   tc_cold_unblock(dig_port, tc_cold_wref);
mutex_unlock(&dig_port->tc_lock);
 }
 
@@ -832,6 +837,7 @@ void intel_tc_port_init(struct intel_digital_port 
*dig_port, bool is_legacy)
 
mutex_init(&dig_port->tc_lock);
dig_port->tc_legacy_port = is_legacy;
+   dig_port->tc_mode = TC_PORT_DISCONNECTED;
dig_port->tc_link_refcount = 0;
tc_port_load_fia_params(i915, dig_port);
 }
-- 
2.27.0

[Intel-gfx] [PATCH v2 13/13] drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect

[Imre Deak]

The PHY ownership release->AUX PW disable steps during a modeset
disable->PHY disconnect sequence can hang the system if the PHY
disconnect happens after disabling the PHY's PLL. The spec doesn't
require a specific order for these two steps, so this issue is still
being root caused by HW/FW teams. Until that is found, let's make
sure the disconnect happens before the PLL is disabled, and do this on
all platforms for consistency.

v2: Add a TODO comment to remove the w/a once the issue is root
caused/fixed. (Jose)

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 4a14db604cbae..40faa18947c99 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -834,6 +834,14 @@ void intel_tc_port_put_link(struct intel_digital_port 
*dig_port)
intel_tc_port_lock(dig_port);
--dig_port->tc_link_refcount;
intel_tc_port_unlock(dig_port);
+
+   /*
+* Disconnecting the PHY after the PHY's PLL gets disabled may
+* hang the system on ADL-P, so disconnect the PHY here synchronously.
+* TODO: remove this once the root cause of the ordering requirement
+* is found/fixed.
+*/
+   intel_tc_port_flush_work(dig_port);
 }
 
 static bool
-- 
2.27.0

[Intel-gfx] [PATCH v2 08/13] drm/i915/tc: Refactor TC-cold block/unblock helpers

[Imre Deak]

A follow-up change will select the TC-cold blocking power domain based
on the TypeC mode, prepare for that here.

Also bring intel_tc_cold_requires_aux_pw() earlier to its logical place
for readability.

No functional change.

v2: Add code comment about IOM reg accesses in TCCOLD. (Jose)

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 .../drm/i915/display/intel_display_types.h|  2 +
 drivers/gpu/drm/i915/display/intel_tc.c   | 68 ---
 2 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9413ebae15f57..f41fdc376a516 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1662,8 +1662,10 @@ struct intel_digital_port {
enum intel_display_power_domain ddi_io_power_domain;
intel_wakeref_t ddi_io_wakeref;
intel_wakeref_t aux_wakeref;
+
struct mutex tc_lock;   /* protects the TypeC port mode */
intel_wakeref_t tc_lock_wakeref;
+   enum intel_display_power_domain tc_lock_power_domain;
int tc_link_refcount;
bool tc_legacy_port:1;
char tc_port_name[8];
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 62a3070abf0a6..69c917fce03e4 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -48,8 +48,16 @@ bool intel_tc_port_in_legacy_mode(struct intel_digital_port 
*dig_port)
return intel_tc_port_in_mode(dig_port, TC_PORT_LEGACY);
 }
 
+bool intel_tc_cold_requires_aux_pw(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+   return (DISPLAY_VER(i915) == 11 && dig_port->tc_legacy_port) ||
+   IS_ALDERLAKE_P(i915);
+}
+
 static enum intel_display_power_domain
-tc_cold_get_power_domain(struct intel_digital_port *dig_port)
+tc_cold_get_power_domain(struct intel_digital_port *dig_port, enum 
tc_port_mode mode)
 {
if (intel_tc_cold_requires_aux_pw(dig_port))
return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
@@ -58,23 +66,30 @@ tc_cold_get_power_domain(struct intel_digital_port 
*dig_port)
 }
 
 static intel_wakeref_t
-tc_cold_block(struct intel_digital_port *dig_port)
+tc_cold_block_in_mode(struct intel_digital_port *dig_port, enum tc_port_mode 
mode,
+ enum intel_display_power_domain *domain)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   enum intel_display_power_domain domain;
 
if (DISPLAY_VER(i915) == 11 && !dig_port->tc_legacy_port)
return 0;
 
-   domain = tc_cold_get_power_domain(dig_port);
-   return intel_display_power_get(i915, domain);
+   *domain = tc_cold_get_power_domain(dig_port, mode);
+
+   return intel_display_power_get(i915, *domain);
+}
+
+static intel_wakeref_t
+tc_cold_block(struct intel_digital_port *dig_port, enum 
intel_display_power_domain *domain)
+{
+   return tc_cold_block_in_mode(dig_port, dig_port->tc_mode, domain);
 }
 
 static void
-tc_cold_unblock(struct intel_digital_port *dig_port, intel_wakeref_t wakeref)
+tc_cold_unblock(struct intel_digital_port *dig_port, enum 
intel_display_power_domain domain,
+   intel_wakeref_t wakeref)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   enum intel_display_power_domain domain;
 
/*
 * wakeref == -1, means some error happened saving save_depot_stack but
@@ -84,8 +99,7 @@ tc_cold_unblock(struct intel_digital_port *dig_port, 
intel_wakeref_t wakeref)
if (wakeref == 0)
return;
 
-   domain = tc_cold_get_power_domain(dig_port);
-   intel_display_power_put_async(i915, domain, wakeref);
+   intel_display_power_put(i915, domain, wakeref);
 }
 
 static void
@@ -98,7 +112,8 @@ assert_tc_cold_blocked(struct intel_digital_port *dig_port)
return;
 
enabled = intel_display_power_is_enabled(i915,
-
tc_cold_get_power_domain(dig_port));
+
tc_cold_get_power_domain(dig_port,
+ 
dig_port->tc_mode));
drm_WARN_ON(&i915->drm, !enabled);
 }
 
@@ -269,6 +284,11 @@ static u32 adl_tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
struct intel_uncore *uncore = &i915->uncore;
u32 val, mask = 0;
 
+   /*
+* On ADL-P HW/FW will wake from TCCOLD to complete the read access of
+* registers in IOM. Note that this doesn't apply to PHY and FIA
+* registers.
+*/
val = intel_uncore_read(uncore, TCSS_DDI_STATUS(tc_port));
if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_ALT)
 

[Intel-gfx] [PATCH v2 09/13] drm/i915/tc: Avoid using legacy AUX PW in TBT mode

[Imre Deak]

For the ADL-P TBT mode the spec doesn't require blocking TC-cold by
using the legacy AUX power domain. To avoid the timeouts that this would
cause during PHY disconnect/reconnect sequences (which will be more
frequent after a follow-up change) use the TC_COLD_OFF power domain in
TBT mode on all platforms. On TGL this power domain blocks TC-cold via a
PUNIT command, while on other platforms the domain just takes a runtime
PM reference.

If the HPD live status indicates that the port mode needs to be reset
- for instance after switching from TBT to a DP-alt sink - still take
the AUX domain, since the IOM firmware handshake requires this.

v2: Rebased on v2 of the previous patch.

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 55 -
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 69c917fce03e4..2df4d0beb6368 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -59,10 +59,10 @@ bool intel_tc_cold_requires_aux_pw(struct 
intel_digital_port *dig_port)
 static enum intel_display_power_domain
 tc_cold_get_power_domain(struct intel_digital_port *dig_port, enum 
tc_port_mode mode)
 {
-   if (intel_tc_cold_requires_aux_pw(dig_port))
-   return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
-   else
+   if (mode == TC_PORT_TBT_ALT || !intel_tc_cold_requires_aux_pw(dig_port))
return POWER_DOMAIN_TC_COLD_OFF;
+
+   return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
 }
 
 static intel_wakeref_t
@@ -645,6 +645,36 @@ static void intel_tc_port_reset_mode(struct 
intel_digital_port *dig_port,
tc_port_mode_name(dig_port->tc_mode));
 }
 
+static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
+{
+   return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
+}
+
+static void intel_tc_port_update_mode(struct intel_digital_port *dig_port,
+ int required_lanes, bool force_disconnect)
+{
+   enum intel_display_power_domain domain;
+   intel_wakeref_t wref;
+   bool needs_reset = force_disconnect;
+
+   if (!needs_reset) {
+   /* Get power domain required to check the hotplug live status. 
*/
+   wref = tc_cold_block(dig_port, &domain);
+   needs_reset = intel_tc_port_needs_reset(dig_port);
+   tc_cold_unblock(dig_port, domain, wref);
+   }
+
+   if (!needs_reset)
+   return;
+
+   /* Get power domain required for resetting the mode. */
+   wref = tc_cold_block_in_mode(dig_port, TC_PORT_DISCONNECTED, &domain);
+
+   intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
+
+   tc_cold_unblock(dig_port, domain, wref);
+}
+
 static void
 intel_tc_port_link_init_refcount(struct intel_digital_port *dig_port,
 int refcount)
@@ -691,11 +721,6 @@ void intel_tc_port_sanitize(struct intel_digital_port 
*dig_port)
mutex_unlock(&dig_port->tc_lock);
 }
 
-static bool intel_tc_port_needs_reset(struct intel_digital_port *dig_port)
-{
-   return intel_tc_port_get_target_mode(dig_port) != dig_port->tc_mode;
-}
-
 /*
  * The type-C ports are different because even when they are connected, they 
may
  * not be available/usable by the graphics driver: see the comment on
@@ -735,18 +760,10 @@ static void __intel_tc_port_lock(struct 
intel_digital_port *dig_port,
 
mutex_lock(&dig_port->tc_lock);
 
-   if (!dig_port->tc_link_refcount) {
-   enum intel_display_power_domain domain;
-   intel_wakeref_t tc_cold_wref;
 
-   tc_cold_wref = tc_cold_block(dig_port, &domain);
-
-   if (force_disconnect || intel_tc_port_needs_reset(dig_port))
-   intel_tc_port_reset_mode(dig_port, required_lanes,
-force_disconnect);
-
-   tc_cold_unblock(dig_port, domain, tc_cold_wref);
-   }
+   if (!dig_port->tc_link_refcount)
+   intel_tc_port_update_mode(dig_port, required_lanes,
+ force_disconnect);
 
drm_WARN_ON(&i915->drm, dig_port->tc_lock_wakeref);
dig_port->tc_lock_wakeref = wakeref;
-- 
2.27.0

[Intel-gfx] [PATCH v2 11/13] drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P

[Imre Deak]

So far TC-cold was blocked only for the duration of TypeC mode resets.
The DP-alt and legacy modes require TC-cold to be blocked also whenever
the port is in use (AUX transfers, enable modeset), and this was ensured
by the held PHY ownership flag. On ADL-P this doesn't work, since the
PHY ownership flag is in a register backed by the PW#2 power well.
Whenever this power well is disabled the ownership flag is cleared by
the HW under the driver.

The only way to cleanly release and re-acquire the PHY ownership flag
and also allow for power saving (by disabling the display power wells
and reaching DC5/6 states) is to hold the TC-cold blocking power domains
while the PHY is connected and disconnect/reconnect the PHY on-demand
around AUX transfers and modeset enable/disables. Let's do that,
disconnecting a PHY with a 1 sec delay after it becomes idle. For
consistency do this on all platforms and TypeC modes.

v2: Add tc_mode!=disconnected and phy_is_owned asserts to
__intel_tc_port_lock().

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  7 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_tc.c   | 89 ---
 drivers/gpu/drm/i915/display/intel_tc.h   |  2 +-
 4 files changed, 63 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0fe77854b4557..51d07e9af9f3d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4017,8 +4017,11 @@ static void intel_ddi_encoder_destroy(struct drm_encoder 
*encoder)
 {
struct drm_i915_private *i915 = to_i915(encoder->dev);
struct intel_digital_port *dig_port = 
enc_to_dig_port(to_intel_encoder(encoder));
+   enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
 
intel_dp_encoder_flush_work(encoder);
+   if (intel_phy_is_tc(i915, phy))
+   intel_tc_port_flush_work(dig_port);
intel_display_power_flush_work(i915);
 
drm_encoder_cleanup(encoder);
@@ -4443,7 +4446,7 @@ static void intel_ddi_encoder_suspend(struct 
intel_encoder *encoder)
if (!intel_phy_is_tc(i915, phy))
return;
 
-   intel_tc_port_disconnect_phy(dig_port);
+   intel_tc_port_flush_work(dig_port);
 }
 
 static void intel_ddi_encoder_shutdown(struct intel_encoder *encoder)
@@ -4458,7 +4461,7 @@ static void intel_ddi_encoder_shutdown(struct 
intel_encoder *encoder)
if (!intel_phy_is_tc(i915, phy))
return;
 
-   intel_tc_port_disconnect_phy(dig_port);
+   intel_tc_port_flush_work(dig_port);
 }
 
 #define port_tc_name(port) ((port) - PORT_TC1 + '1')
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f41fdc376a516..6323911979373 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1666,6 +1666,7 @@ struct intel_digital_port {
struct mutex tc_lock;   /* protects the TypeC port mode */
intel_wakeref_t tc_lock_wakeref;
enum intel_display_power_domain tc_lock_power_domain;
+   struct delayed_work tc_disconnect_phy_work;
int tc_link_refcount;
bool tc_legacy_port:1;
char tc_port_name[8];
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 9367770de5d79..66cb321a4488d 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -666,6 +666,13 @@ static void intel_tc_port_update_mode(struct 
intel_digital_port *dig_port,
 
intel_tc_port_reset_mode(dig_port, required_lanes, force_disconnect);
 
+   /* Get power domain matching the new mode after reset. */
+   tc_cold_unblock(dig_port, dig_port->tc_lock_power_domain,
+   fetch_and_zero(&dig_port->tc_lock_wakeref));
+   if (dig_port->tc_mode != TC_PORT_DISCONNECTED)
+   dig_port->tc_lock_wakeref = tc_cold_block(dig_port,
+ 
&dig_port->tc_lock_power_domain);
+
tc_cold_unblock(dig_port, domain, wref);
 }
 
@@ -693,6 +700,7 @@ void intel_tc_port_sanitize(struct intel_digital_port 
*dig_port)
active_links = to_intel_crtc(encoder->base.crtc)->active;
 
drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_DISCONNECTED);
+   drm_WARN_ON(&i915->drm, dig_port->tc_lock_wakeref);
if (active_links) {
enum intel_display_power_domain domain;
intel_wakeref_t tc_cold_wref = tc_cold_block(dig_port, &domain);
@@ -705,6 +713,9 @@ void intel_tc_port_sanitize(struct intel_digital_port 
*dig_port)
dig_port->tc_port_name, active_links);
intel_tc_port_link_init_refcount(dig_p

Re: [Intel-gfx] [PATCH 6/7] drm/i915/display/adlp: Allow PSR2 to be enabled

[Gwan-gyeong Mun]

Reviewed-by: Gwan-gyeong Mun 

On 9/23/21 10:46 PM, José Roberto de Souza wrote:

With all the recent fixes PSR2 is properly working in Alderlake-P but
due to some issues that don't have software workarounds it will not be
supported in display steppings older than B0.

Even with this patch PSR2 will no be enabled by default in ADL-P, it
still requires enable_psr2_sel_fetch to be set to true, what some
of our tests does.

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 001d81f128989..37727ff2b2ec9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -830,12 +830,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
  
-	/*

-* We are missing the implementation of some workarounds to enabled PSR2
-* in Alderlake_P, until ready PSR2 should be kept disabled.
-*/
-   if (IS_ALDERLAKE_P(dev_priv)) {
-   drm_dbg_kms(&dev_priv->drm, "PSR2 is missing the implementation of 
workarounds\n");
+   if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
+   drm_dbg_kms(&dev_priv->drm, "PSR2 not completely functional in this 
stepping\n");
return false;
}
  

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
URL   : https://patchwork.freedesktop.org/series/95219/
State : failure

== Summary ==

Applying: drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
M   drivers/gpu/drm/i915/gem/i915_gem_ttm.c
M   drivers/gpu/drm/nouveau/nouveau_bo.c
M   drivers/gpu/drm/ttm/ttm_bo_util.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/ttm/ttm_bo_util.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/ttm/ttm_bo_util.c
Auto-merging drivers/gpu/drm/nouveau/nouveau_bo.c
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_ttm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_ttm.c
Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: Rework object initialization slightly (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Rework object initialization slightly (rev2)
URL   : https://patchwork.freedesktop.org/series/95107/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21187


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21187

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21187: 8d53292c0448f800c1f28b30015e53e602ce709f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8d53292c0448 drm/i915/ttm: Rework object initialization slightly

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
7a1594f1ced8 drm/i915/tc: Fix TypeC port init/resume time sanitization
c01091513a71 drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode
606f377a7dcc drm/i915/tc: Remove waiting for PHY complete during releasing 
ownership
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
commit ddec362724f9 ("drm/i915: Wait for TypeC PHY complete flag to clear in 
safe mode")

total: 0 errors, 1 warnings, 0 checks, 11 lines checked
adb7ecaceb9b drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY 
ownership
03ba5a3c3391 drm/i915/tc: Add/use helpers to retrieve TypeC port properties
560710f22702 drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o 
a sink
980d79eb09d2 drm/i915/tc: Add a mode for the TypeC PHY's disconnected state
9868a17a5a37 drm/i915/tc: Refactor TC-cold block/unblock helpers
43107536a80f drm/i915/tc: Avoid using legacy AUX PW in TBT mode
aa72ab7dada7 drm/i915/icl/tc: Remove the ICL special casing during TC-cold 
blocking
e39e52ba5422 drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P
-:139: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#139: FILE: drivers/gpu/drm/i915/display/intel_tc.c:773:
+   drm_WARN_ON(&i915->drm, dig_port->tc_mode != TC_PORT_TBT_ALT &&
+   !tc_phy_is_owned(dig_port));

total: 0 errors, 0 warnings, 1 checks, 196 lines checked
76ecfcf236e0 drm/i915/tc: Drop extra TC cold blocking from 
intel_tc_port_connected()
6e3ad889b1c9 drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block

Re: [Intel-gfx] [PATCH v5 01/13] drm/ttm: stop calling tt_swapin in vm_access

[Matthew Auld]

On Wed, 29 Sept 2021 at 13:01, Christian König  wrote:
>
> Am 27.09.21 um 18:14 schrieb Matthew Auld:
> > On Mon, 27 Sept 2021 at 12:47, Christian König  
> > wrote:
> >> Any objections that I just push patches 1-7 to drm-misc-next?
> > Please go ahead Christian. Thanks.
>
> Well I've pushed patches #1-#4 because #5 won't apply on current
> drm-misc-next (some conflict in i915).
>
> Could you rebase this an/or request backmerging of drm-next into
> drm-misc-next when potential i915 prerequisites have landed there.

Version which should apply to drm-misc-next:
https://patchwork.freedesktop.org/series/95219/

>
> Thanks,
> Christian.
>
> >
> >> Christian.
> >>
> >> Am 27.09.21 um 13:41 schrieb Matthew Auld:
> >>> In commit:
> >>>
> >>> commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
> >>> Author: Felix Kuehling 
> >>> Date:   Thu Jul 13 17:01:16 2017 -0400
> >>>
> >>>   drm/ttm: Implement vm_operations_struct.access v2
> >>>
> >>> we added the vm_access hook, where we also directly call tt_swapin for
> >>> some reason. If something is swapped-out then the ttm_tt must also be
> >>> unpopulated, and since access_kmap should also call tt_populate, if
> >>> needed, then swapping-in will already be handled there.
> >>>
> >>> If anything, calling tt_swapin directly here would likely always fail
> >>> since the tt->pages won't yet be populated, or worse since the tt->pages
> >>> array is never actually cleared in unpopulate this might lead to a nasty
> >>> uaf.
> >>>
> >>> Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
> >>> Signed-off-by: Matthew Auld 
> >>> Cc: Thomas Hellström 
> >>> Cc: Christian König 
> >>> Reviewed-by: Thomas Hellström 
> >>> Reviewed-by: Christian König 
> >>> ---
> >>>drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
> >>>1 file changed, 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
> >>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> index f56be5bc0861..5b9b7fd01a69 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> @@ -519,11 +519,6 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, 
> >>> unsigned long addr,
> >>>
> >>>switch (bo->resource->mem_type) {
> >>>case TTM_PL_SYSTEM:
> >>> - if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
> >>> - ret = ttm_tt_swapin(bo->ttm);
> >>> - if (unlikely(ret != 0))
> >>> - return ret;
> >>> - }
> >>>fallthrough;
> >>>case TTM_PL_TT:
> >>>ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gen11: Disable cursor clock gating in HDR mode (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev6)
URL   : https://patchwork.freedesktop.org/series/91674/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10659_full -> Patchwork_21185_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-skl7/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-apl1/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#1373])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-tglb1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-tglb7/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#280])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-tglb5/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][6] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-kbl2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-apl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-iclb8/igt@gem_exec_fair@basic-p...@bcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-iclb3/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2851])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_whisper@basic-contexts-all:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118] / 
[i915#95])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-glk7/igt@gem_exec_whis...@basic-contexts-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-glk5/igt@gem_exec_whis...@basic-contexts-all.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][21] ([i915#2658])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-apl3/igt@gem_pr...@exhaustion.html

  * igt@gem_softpin@evict-snoop:
- shard-iclb: NOTRUN -> [SKIP][22] ([fdo#109312])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21185/shard-iclb6/igt@gem_soft...@evict-snoop.html

  * igt

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21189


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21189

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21189: 6e3ad889b1c988e7dcb7b3604f73e458576f928a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6e3ad889b1c9 drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect
76ecfcf236e0 drm/i915/tc: Drop extra TC cold blocking from 
intel_tc_port_connected()
e39e52ba5422 drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P
aa72ab7dada7 drm/i915/icl/tc: Remove the ICL special casing during TC-cold 
blocking
43107536a80f drm/i915/tc: Avoid using legacy AUX PW in TBT mode
9868a17a5a37 drm/i915/tc: Refactor TC-cold block/unblock helpers
980d79eb09d2 drm/i915/tc: Add a mode for the TypeC PHY's disconnected state
560710f22702 drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o 
a sink
03ba5a3c3391 drm/i915/tc: Add/use helpers to retrieve TypeC port properties
adb7ecaceb9b drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY 
ownership
606f377a7dcc drm/i915/tc: Remove waiting for PHY complete during releasing 
ownership
c01091513a71 drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode
7a1594f1ced8 drm/i915/tc: Fix TypeC port init/resume time sanitization

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add ww context to intel_dpt_pin, v2.

[Patchwork]

== Series Details ==

Series: drm/i915: Add ww context to intel_dpt_pin, v2.
URL   : https://patchwork.freedesktop.org/series/95200/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10659_full -> Patchwork_21186_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-skl6/igt@kms_async_fl...@crc.html

  * igt@kms_vblank@pipe-b-wait-idle-hang:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-skl9/igt@kms_vbl...@pipe-b-wait-idle-hang.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-skl3/igt@kms_vbl...@pipe-b-wait-idle-hang.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-apl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#1373])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-tglb1/igt@gem_ctx_isolation@preservation...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-tglb7/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-tglb5/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-iclb2/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-iclb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-apl8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-wc-read:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#165] / 
[i915#62]) +10 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-apl8/igt@gem_exec_re...@basic-wc-read.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-apl3/igt@gem_exec_re...@basic-wc-read.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#456])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-tglb5/igt@gem_exec_susp...@basic-s0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_whisper@basic-contexts-all:
- shard-glk:  [PASS][21] -> [DMESG-WARN][22] ([i915#118] / 
[i915#95])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10659/shard-glk7/igt@gem_exec_whis...@basic-contexts-all.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21186/shard-glk9/igt@gem_exec_whis...@basic-con

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Disable cursor clock gating in HDR mode (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev7)
URL   : https://patchwork.freedesktop.org/series/91674/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21190


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21190

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21190: f2837e9db771588f882bbc29f7f1efed0e123f49 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f2837e9db771 drm/i915/gen11: Disable cursor clock gating in HDR mode

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin, v2.

[Intel]

On 9/29/21 10:59, Maarten Lankhorst wrote:

Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.

I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.

Changes since v1:
- Fix using the wrong pointer to retrieve error code (Julia)

Signed-off-by: Maarten Lankhorst 
Reported-by: kernel test robot 
Reported-by: Julia Lawall 


LGTM.

Reviewed-by: Thomas Hellström 


---
  drivers/gpu/drm/i915/display/intel_dpt.c | 40 +++-
  1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e..8f7b1f7534a4 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -121,32 +121,42 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
intel_wakeref_t wakeref;
struct i915_vma *vma;
void __iomem *iomem;
+   struct i915_gem_ww_ctx ww;
+   int err;
  
  	wakeref = intel_runtime_pm_get(&i915->runtime_pm);

atomic_inc(&i915->gpu_error.pending_fb_pin);
  
-	vma = i915_gem_object_ggtt_pin(dpt->obj, NULL, 0, 4096,

-  HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
-   if (IS_ERR(vma))
-   goto err;
+   for_i915_gem_ww(&ww, err, true) {
+   err = i915_gem_object_lock(dpt->obj, &ww);
+   if (err)
+   continue;
  
-	iomem = i915_vma_pin_iomap(vma);

-   i915_vma_unpin(vma);
-   if (IS_ERR(iomem)) {
-   vma = ERR_CAST(iomem);
-   goto err;
-   }
+   vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
+ HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   continue;
+   }
+
+   iomem = i915_vma_pin_iomap(vma);
+   i915_vma_unpin(vma);
  
-	dpt->vma = vma;

-   dpt->iomem = iomem;
+   if (IS_ERR(iomem)) {
+   err = PTR_ERR(iomem);
+   continue;
+   }
  
-	i915_vma_get(vma);

+   dpt->vma = vma;
+   dpt->iomem = iomem;
+
+   i915_vma_get(vma);
+   }
  
-err:

atomic_dec(&i915->gpu_error.pending_fb_pin);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
  
-	return vma;

+   return err ? ERR_PTR(err) : vma;
  }
  
  void intel_dpt_unpin(struct i915_address_space *vm)

Re: [Intel-gfx] [Freedreno] [PATCH v2 13/13] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers

[Sean Paul]

On Tue, Sep 28, 2021 at 02:35:09PM -0700, abhin...@codeaurora.org wrote:
> On 2021-09-28 11:02, Sean Paul wrote:
> > On Tue, Sep 21, 2021 at 07:25:41PM -0700, abhin...@codeaurora.org wrote:
> > > On 2021-09-15 13:38, Sean Paul wrote:
> > > > From: Sean Paul 
> > > >
> > > > This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
> > > > helpers.
> > > >
> > > > Cc: Stephen Boyd 
> > > > Signed-off-by: Sean Paul 
> > > > Link:
> > > > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> > > > #v1
> > > >
> > > > Changes in v2:
> > > > -Squash [1] into this patch with the following changes (Stephen)
> > > >   -Update the sc7180 dtsi file
> > > >   -Remove resource names and just use index (Stephen)
> > > >
> > > 
> > > 
> > > > [1]
> > > > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-14-s...@poorly.run
> > > > ---
> > 
> > /snip
> > 
> > > > diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> > > > index 904535eda0c4..98731fd262d6 100644
> > > > --- a/drivers/gpu/drm/msm/Makefile
> > > > +++ b/drivers/gpu/drm/msm/Makefile
> > > > @@ -109,6 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
> > > > dp/dp_ctrl.o \
> > > > dp/dp_display.o \
> > > > dp/dp_drm.o \
> > > > +   dp/dp_hdcp.o \
> > > > dp/dp_hpd.o \
> > > > dp/dp_link.o \
> > > > dp/dp_panel.o \
> > > > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > index 2f6247e80e9d..de16fca8782a 100644
> > > > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > > > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
> > 
> > /snip
> > 
> > > > +static ssize_t dp_hdcp_key_write(struct file *file, const char __user
> > > > *ubuf,
> > > > +size_t len, loff_t *offp)
> > > > +{
> > > > +   char *input_buffer;
> > > > +   int ret = 0;
> > > > +   struct dp_debug_private *debug = file->private_data;
> > > > +   struct drm_device *dev;
> > > > +
> > > > +   dev = debug->drm_dev;
> > > > +
> > > > +   if (len != (DRM_HDCP_KSV_LEN + DP_HDCP_NUM_KEYS * 
> > > > DP_HDCP_KEY_LEN))
> > > > +   return -EINVAL;
> > > > +
> > > > +   if (!debug->hdcp)
> > > > +   return -ENOENT;
> > > > +
> > > > +   input_buffer = memdup_user_nul(ubuf, len);
> > > > +   if (IS_ERR(input_buffer))
> > > > +   return PTR_ERR(input_buffer);
> > > > +
> > > > +   ret = dp_hdcp_ingest_key(debug->hdcp, input_buffer, len);
> > > > +
> > > > +   kfree(input_buffer);
> > > > +   if (ret < 0) {
> > > > +   DRM_ERROR("Could not ingest HDCP key, ret=%d\n", ret);
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   *offp += len;
> > > > +   return len;
> > > > +}
> > > 
> > > It seems like the HDCP keys written using debugfs, just for my
> > > understanding,
> > > are you storing this in some secure partition and the usermode reads
> > > from it
> > > and writes them here?
> > > 
> > 
> > We have not sorted out the userspace side of HDCP enablement yet, so it
> > remains
> > to be seen whether the keys will be injected via debugfs/firmware
> > file/property.
> > 
> > /snip
> > 
> > > > +static int dp_connector_atomic_check(struct drm_connector *connector,
> > > > +struct drm_atomic_state *state)
> > > > +{
> > > > +   struct drm_connector_state *conn_state;
> > > > +   struct dp_connector_state *dp_state;
> > > > +
> > > > +   conn_state = drm_atomic_get_new_connector_state(state, 
> > > > connector);
> > > > +   dp_state = to_dp_connector_state(conn_state);
> > > > +
> > > > +   dp_state->hdcp_transition = drm_hdcp_atomic_check(connector, 
> > > > state);
> > > 
> > > I have a general question related to the transition flag and overall
> > > tying
> > > the HDCP
> > > enable and authentication to the commit.
> > > So lets say there is a case where the driver needs to disable HDCP.
> > > It could
> > > be due
> > > to link integrity failure OR some other error condition which
> > > usermode is
> > > not aware of.
> > > In that case, we will set this hdcp_transition to true but in the next
> > > commit we will
> > > actually do the authentication. What if usermode doesnt issue a new
> > > frame?
> > > This question arises because currently the link intergrity check is
> > > done
> > > using SW polling
> > > in the previous patchset. But as I had commented there, this occurs
> > > in HW
> > > for us.
> > > I dont see that isr itself in this patchset. So wanted to understand
> > > if
> > > thats part of this
> > > approach to still tie it with commit.
> > > 
> > > So if we go with the HW polling based approach which is the preferred
> > > method, we need to
> > > untie this from the commit.
> > > 
> > 
> > In the case of error, the worker will detect it and try to
> > re-authenticate. If
> > the re-authentication is successf

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: Rework object initialization slightly (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/ttm: Rework object initialization slightly (rev2)
URL   : https://patchwork.freedesktop.org/series/95107/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21187_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-glk9/igt@fb...@unaligned-read.html

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-skl1/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-apl7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@hostile:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_ctx_persiste...@hostile.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-tglb1/igt@gem_ctx_persiste...@hostile.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#280]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-tglb5/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-glk8/igt@gem_exec_f...@basic-deadline.html
- shard-apl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-apl2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +97 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-skl4/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-glk2/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][17] -> [SKIP][18] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-iclb2/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2842])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21187/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][23] ([fdo#109283])
   [23]: 
https://intel-gfx-c

[Intel-gfx] [PATCH] drm/i915: Enable TPS3/4 on all platforms that support them

[Ville Syrjala]

From: Ville Syrjälä 

Stop using HBR2/3 support as a proxy for TPS3/4 support.
The two are no longer 1:1 in the hardware, arguably they
never were due to HSW ULX which does support TPS3 while
being limited to HBR1.

In more recent times GLK gained support for TPS4 while
being limited to HBR2. And on CNL+ some ports support
HBR3 while others are limited to HBR2, but all ports
support TPS4.

v2: s/INTEL_GEN/DISPLAY_VER/

Reviewed-by: Manasi Navare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c   | 12 +++-
 drivers/gpu/drm/i915/display/intel_dp.h   |  4 +--
 .../drm/i915/display/intel_dp_link_training.c | 30 +--
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 4 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 378008873e03..9dce7c0e434a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -929,18 +929,14 @@ intel_dp_mode_valid(struct drm_connector *connector,
return intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
 }
 
-bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
+bool intel_dp_source_supports_tps3(struct drm_i915_private *i915)
 {
-   int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
-
-   return max_rate >= 54;
+   return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915) || IS_HASWELL(i915);
 }
 
-bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp)
+bool intel_dp_source_supports_tps4(struct drm_i915_private *i915)
 {
-   int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
-
-   return max_rate >= 81;
+   return DISPLAY_VER(i915) >= 10;
 }
 
 static void snprintf_int_array(char *str, size_t len,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3343c2591680..ce229026dc91 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -73,8 +73,8 @@ int intel_dp_rate_select(struct intel_dp *intel_dp, int rate);
 
 void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
   u8 *link_bw, u8 *rate_select);
-bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
-bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
+bool intel_dp_source_supports_tps3(struct drm_i915_private *i915);
+bool intel_dp_source_supports_tps4(struct drm_i915_private *i915);
 
 bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 4f116cd32846..449499a5c4c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -611,6 +611,7 @@ static u32 intel_dp_training_pattern(struct intel_dp 
*intel_dp,
 const struct intel_crtc_state *crtc_state,
 enum drm_dp_phy dp_phy)
 {
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool source_tps3, sink_tps3, source_tps4, sink_tps4;
 
/* UHBR+ use separate 128b/132b TPS2 */
@@ -618,41 +619,40 @@ static u32 intel_dp_training_pattern(struct intel_dp 
*intel_dp,
return DP_TRAINING_PATTERN_2;
 
/*
-* Intel platforms that support HBR3 also support TPS4. It is mandatory
-* for all downstream devices that support HBR3. There are no known eDP
-* panels that support TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1
-* specification.
+* TPS4 support is mandatory for all downstream devices that
+* support HBR3. There are no known eDP panels that support
+* TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1 specification.
 * LTTPRs must support TPS4.
 */
-   source_tps4 = intel_dp_source_supports_hbr3(intel_dp);
+   source_tps4 = intel_dp_source_supports_tps4(i915);
sink_tps4 = dp_phy != DP_PHY_DPRX ||
drm_dp_tps4_supported(intel_dp->dpcd);
if (source_tps4 && sink_tps4) {
return DP_TRAINING_PATTERN_4;
} else if (crtc_state->port_clock == 81) {
if (!source_tps4)
-   drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
-   "8.1 Gbps link rate without source 
HBR3/TPS4 support\n");
+   drm_dbg_kms(&i915->drm,
+   "8.1 Gbps link rate without source TPS4 
support\n");
if (!sink_tps4)
-   drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
+   drm_dbg_kms(&i915->drm,
"8.1 Gbps link rate without sink TPS4 
support\n");
}
+
/*
-* Intel pl

[Intel-gfx] [PATCH v3 8/9] drm/i915: Prepare link training for per-lane drive settings

[Ville Syrjala]

From: Ville Syrjälä 

Adjust the link training code to accommodate per-lane drive settings,
if supported by the platform. Actually enabling this will involve
some changes to each platform's .set_signal_level() implementation,
so for the moment all supported platforms will keep using the current
codepath that just uses the same drive settings for all the lanes.

v2: Fix min() vs. max() fumble
v3: Compact the debug print to a single line

Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_dp_link_training.c | 78 ++-
 1 file changed, 60 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index d52929855cd0..f26c44a6b568 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -301,21 +301,33 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp 
*intel_dp,
return preemph_max;
 }
 
-void
-intel_dp_get_adjust_train(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state,
- enum drm_dp_phy dp_phy,
- const u8 link_status[DP_LINK_STATUS_SIZE])
+static bool has_per_lane_signal_levels(struct intel_dp *intel_dp,
+  enum drm_dp_phy dp_phy)
+{
+   return false;
+}
+
+static u8 intel_dp_get_lane_adjust_train(struct intel_dp *intel_dp,
+const struct intel_crtc_state 
*crtc_state,
+enum drm_dp_phy dp_phy,
+const u8 
link_status[DP_LINK_STATUS_SIZE],
+int lane)
 {
u8 v = 0;
u8 p = 0;
-   int lane;
u8 voltage_max;
u8 preemph_max;
 
-   for (lane = 0; lane < crtc_state->lane_count; lane++) {
-   v = max(v, drm_dp_get_adjust_request_voltage(link_status, 
lane));
-   p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status, 
lane));
+   if (has_per_lane_signal_levels(intel_dp, dp_phy)) {
+   lane = min(lane, crtc_state->lane_count - 1);
+
+   v = drm_dp_get_adjust_request_voltage(link_status, lane);
+   p = drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
+   } else {
+   for (lane = 0; lane < crtc_state->lane_count; lane++) {
+   v = max(v, 
drm_dp_get_adjust_request_voltage(link_status, lane));
+   p = max(p, 
drm_dp_get_adjust_request_pre_emphasis(link_status, lane));
+   }
}
 
preemph_max = intel_dp_phy_preemph_max(intel_dp, dp_phy);
@@ -328,8 +340,21 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
if (v >= voltage_max)
v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
 
+   return v | p;
+}
+
+void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ enum drm_dp_phy dp_phy,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
+{
+   int lane;
+
for (lane = 0; lane < 4; lane++)
-   intel_dp->train_set[lane] = v | p;
+   intel_dp->train_set[lane] =
+   intel_dp_get_lane_adjust_train(intel_dp, crtc_state,
+  dp_phy, link_status, 
lane);
 }
 
 static int intel_dp_training_pattern_set_reg(struct intel_dp *intel_dp,
@@ -394,22 +419,39 @@ intel_dp_program_link_training_pattern(struct intel_dp 
*intel_dp,
intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
 }
 
+#define TRAIN_SET_FMT "%d%s/%d%s/%d%s/%d%s"
+#define _TRAIN_SET_VSWING_ARGS(train_set) \
+   ((train_set) & DP_TRAIN_VOLTAGE_SWING_MASK) >> 
DP_TRAIN_VOLTAGE_SWING_SHIFT, \
+   (train_set) & DP_TRAIN_MAX_SWING_REACHED ? "(max)" : ""
+#define TRAIN_SET_VSWING_ARGS(train_set) \
+   _TRAIN_SET_VSWING_ARGS((train_set)[0]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[1]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[2]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[3])
+#define _TRAIN_SET_PREEMPH_ARGS(train_set) \
+   ((train_set) & DP_TRAIN_PRE_EMPHASIS_MASK) >> 
DP_TRAIN_PRE_EMPHASIS_SHIFT, \
+   (train_set) & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ? "(max)" : ""
+#define TRAIN_SET_PREEMPH_ARGS(train_set) \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[0]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[1]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[2]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[3])
+
 void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
enum drm_dp_phy dp_phy)
 {
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_p

[Intel-gfx] [PATCH v2 9/9] drm/i915: Allow per-lane drive settings with LTTPRs

[Ville Syrjala]

From: Ville Syrjälä 

LTTPRs should support per-lane drive settings I think, and even if
they don't they should implement their own fallback logic to determine
suitable common drive settings to use for all the lanes.

v2: Actually check the correct thing

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index f26c44a6b568..eeea6c73e218 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -304,7 +304,7 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp 
*intel_dp,
 static bool has_per_lane_signal_levels(struct intel_dp *intel_dp,
   enum drm_dp_phy dp_phy)
 {
-   return false;
+   return !intel_dp_phy_is_downstream_of_source(intel_dp, dp_phy);
 }
 
 static u8 intel_dp_get_lane_adjust_train(struct intel_dp *intel_dp,
-- 
2.32.0

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@fb...@unaligned-read.html

  * igt@gem_eio@reset-stress:
- shard-skl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/igt@gem_...@reset-stress.html

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl7/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +106 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_gttfill@basic:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
[i915#95]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk1/igt@gem_exec_gttf...@basic.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109283])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-t

Re: [Intel-gfx] [PATCH 1/9] drm/i915: s/ddi_translations/trans/

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:47PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> "ddi_translations" is a bit too long, let's shorten it to just "trans".
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  92 +--
>  .../drm/i915/display/intel_ddi_buf_trans.c| 628 +-
>  drivers/gpu/drm/i915/display/intel_snps_phy.c |  12 +-
>  3 files changed, 366 insertions(+), 366 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a4667741d354..39bacef87ef2 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -104,10 +104,10 @@ void hsw_prepare_dp_ddi_buffers(struct intel_encoder 
> *encoder,
>   u32 iboost_bit = 0;
>   int i, n_entries;
>   enum port port = encoder->port;
> - const struct intel_ddi_buf_trans *ddi_translations;
> + const struct intel_ddi_buf_trans *trans;
>  
> - ddi_translations = encoder->get_buf_trans(encoder, crtc_state, 
> &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
>  
>   /* If we're boosting the current, set bit 31 of trans1 */
> @@ -117,9 +117,9 @@ void hsw_prepare_dp_ddi_buffers(struct intel_encoder 
> *encoder,
>  
>   for (i = 0; i < n_entries; i++) {
>   intel_de_write(dev_priv, DDI_BUF_TRANS_LO(port, i),
> -ddi_translations->entries[i].hsw.trans1 | 
> iboost_bit);
> +trans->entries[i].hsw.trans1 | iboost_bit);
>   intel_de_write(dev_priv, DDI_BUF_TRANS_HI(port, i),
> -ddi_translations->entries[i].hsw.trans2);
> +trans->entries[i].hsw.trans2);
>   }
>  }
>  
> @@ -136,10 +136,10 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
> intel_encoder *encoder,
>   u32 iboost_bit = 0;
>   int n_entries;
>   enum port port = encoder->port;
> - const struct intel_ddi_buf_trans *ddi_translations;
> + const struct intel_ddi_buf_trans *trans;
>  
> - ddi_translations = encoder->get_buf_trans(encoder, crtc_state, 
> &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
>   level = n_entries - 1;
> @@ -151,9 +151,9 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
> intel_encoder *encoder,
>  
>   /* Entry 9 is for HDMI: */
>   intel_de_write(dev_priv, DDI_BUF_TRANS_LO(port, 9),
> -ddi_translations->entries[level].hsw.trans1 | 
> iboost_bit);
> +trans->entries[level].hsw.trans1 | iboost_bit);
>   intel_de_write(dev_priv, DDI_BUF_TRANS_HI(port, 9),
> -ddi_translations->entries[level].hsw.trans2);
> +trans->entries[level].hsw.trans2);
>  }
>  
>  void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
> @@ -971,16 +971,16 @@ static void skl_ddi_set_iboost(struct intel_encoder 
> *encoder,
>   iboost = intel_bios_encoder_dp_boost_level(encoder->devdata);
>  
>   if (iboost == 0) {
> - const struct intel_ddi_buf_trans *ddi_translations;
> + const struct intel_ddi_buf_trans *trans;
>   int n_entries;
>  
> - ddi_translations = encoder->get_buf_trans(encoder, crtc_state, 
> &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
>   level = n_entries - 1;
>  
> - iboost = ddi_translations->entries[level].hsw.i_boost;
> + iboost = trans->entries[level].hsw.i_boost;
>   }
>  
>   /* Make sure that the requested I_boost is valid */
> @@ -1000,21 +1000,21 @@ static void bxt_ddi_vswing_sequence(struct 
> intel_encoder *encoder,
>   int level)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - const struct intel_ddi_buf_trans *ddi_translations;
> + const struct intel_ddi_buf_trans *trans;
>   enum port port = encoder->port;
>   int n_entries;
>  
> - ddi_translations = encoder->get_buf_trans(encoder, crtc_state, 
> &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&dev_priv->d

Re: [Intel-gfx] [PATCH] drm/i915: Enable TPS3/4 on all platforms that support them

[Jani Nikula]

On Wed, 29 Sep 2021, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Stop using HBR2/3 support as a proxy for TPS3/4 support.
> The two are no longer 1:1 in the hardware, arguably they
> never were due to HSW ULX which does support TPS3 while
> being limited to HBR1.
>
> In more recent times GLK gained support for TPS4 while
> being limited to HBR2. And on CNL+ some ports support
> HBR3 while others are limited to HBR2, but all ports
> support TPS4.
>
> v2: s/INTEL_GEN/DISPLAY_VER/
>
> Reviewed-by: Manasi Navare 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 12 +++-
>  drivers/gpu/drm/i915/display/intel_dp.h   |  4 +--
>  .../drm/i915/display/intel_dp_link_training.c | 30 +--
>  drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
>  4 files changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 378008873e03..9dce7c0e434a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -929,18 +929,14 @@ intel_dp_mode_valid(struct drm_connector *connector,
>   return intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
>  }
>  
> -bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
> +bool intel_dp_source_supports_tps3(struct drm_i915_private *i915)

I guess it's fathomable we'd have different ports supporting different
training patterns, similar to the max rates. But it's easy enough to
pass intel_dp again in that case.

Acked-by: Jani Nikula 



>  {
> - int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
> -
> - return max_rate >= 54;
> + return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915) || IS_HASWELL(i915);
>  }
>  
> -bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp)
> +bool intel_dp_source_supports_tps4(struct drm_i915_private *i915)
>  {
> - int max_rate = intel_dp->source_rates[intel_dp->num_source_rates - 1];
> -
> - return max_rate >= 81;
> + return DISPLAY_VER(i915) >= 10;
>  }
>  
>  static void snprintf_int_array(char *str, size_t len,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 3343c2591680..ce229026dc91 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -73,8 +73,8 @@ int intel_dp_rate_select(struct intel_dp *intel_dp, int 
> rate);
>  
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
>  u8 *link_bw, u8 *rate_select);
> -bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> -bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
> +bool intel_dp_source_supports_tps3(struct drm_i915_private *i915);
> +bool intel_dp_source_supports_tps4(struct drm_i915_private *i915);
>  
>  bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
>  int intel_dp_link_required(int pixel_clock, int bpp);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 4f116cd32846..449499a5c4c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -611,6 +611,7 @@ static u32 intel_dp_training_pattern(struct intel_dp 
> *intel_dp,
>const struct intel_crtc_state *crtc_state,
>enum drm_dp_phy dp_phy)
>  {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   bool source_tps3, sink_tps3, source_tps4, sink_tps4;
>  
>   /* UHBR+ use separate 128b/132b TPS2 */
> @@ -618,41 +619,40 @@ static u32 intel_dp_training_pattern(struct intel_dp 
> *intel_dp,
>   return DP_TRAINING_PATTERN_2;
>  
>   /*
> -  * Intel platforms that support HBR3 also support TPS4. It is mandatory
> -  * for all downstream devices that support HBR3. There are no known eDP
> -  * panels that support TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1
> -  * specification.
> +  * TPS4 support is mandatory for all downstream devices that
> +  * support HBR3. There are no known eDP panels that support
> +  * TPS4 as of Feb 2018 as per VESA eDP_v1.4b_E1 specification.
>* LTTPRs must support TPS4.
>*/
> - source_tps4 = intel_dp_source_supports_hbr3(intel_dp);
> + source_tps4 = intel_dp_source_supports_tps4(i915);
>   sink_tps4 = dp_phy != DP_PHY_DPRX ||
>   drm_dp_tps4_supported(intel_dp->dpcd);
>   if (source_tps4 && sink_tps4) {
>   return DP_TRAINING_PATTERN_4;
>   } else if (crtc_state->port_clock == 81) {
>   if (!source_tps4)
> - drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> - "8.1 Gbps link rate without source 
> HBR3/TPS4 support\n");
> + d

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable TPS3/4 on all platforms that support them (rev2)
URL   : https://patchwork.freedesktop.org/series/88186/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21191


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  [PASS][1] -> [INCOMPLETE][2] ([i915#4130])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][3] -> [FAIL][4] ([i915#1888])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-kbl-soraka:  [PASS][5] -> [FAIL][6] ([i915#2122])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-kbl-soraka/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/fi-kbl-soraka/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html

  * igt@runner@aborted:
- fi-tgl-u2:  NOTRUN -> [FAIL][7] ([i915#1602] / [i915#2722])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/fi-tgl-u2/igt@run...@aborted.html

  
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#4130]: https://gitlab.freedesktop.org/drm/intel/issues/4130


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21191

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21191: 5fc40e2c64bb03117efa244ac68458e94d0ffb60 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5fc40e2c64bb drm/i915: Enable TPS3/4 on all platforms that support them

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: DP per-lane drive settings prep work (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev4)
URL   : https://patchwork.freedesktop.org/series/95122/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5ca7aed58062 drm/i915: s/ddi_translations/trans/
-:1809: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#1809: FILE: drivers/gpu/drm/i915/display/intel_snps_phy.c:73:
+   val |= REG_FIELD_PREP(SNPS_PHY_TX_EQ_PRE, 
trans->entries[level].snps.snps_pre_cursor);

-:1810: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#1810: FILE: drivers/gpu/drm/i915/display/intel_snps_phy.c:74:
+   val |= REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 
trans->entries[level].snps.snps_post_cursor);

total: 0 errors, 2 warnings, 0 checks, 1677 lines checked
12af5655d6e9 drm/i915: Generalize .set_signal_levels()
148ee4908c2b drm/i915: Nuke usless .set_signal_levels() wrappers
96ccc8d77127 drm/i915: De-wrapper bxt_ddi_phy_set_signal_levels()
40be81462b60 drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()
025b7bd7473d drm/i915: Nuke intel_ddi_hdmi_num_entries()
68f42730e749 drm/i915: Pass the lane to intel_ddi_level()
24cdd73489e8 drm/i915: Prepare link training for per-lane drive settings
-:95: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'train_set' - possible 
side-effects?
#95: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:423:
+#define _TRAIN_SET_VSWING_ARGS(train_set) \
+   ((train_set) & DP_TRAIN_VOLTAGE_SWING_MASK) >> 
DP_TRAIN_VOLTAGE_SWING_SHIFT, \
+   (train_set) & DP_TRAIN_MAX_SWING_REACHED ? "(max)" : ""

-:98: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#98: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:426:
+#define TRAIN_SET_VSWING_ARGS(train_set) \
+   _TRAIN_SET_VSWING_ARGS((train_set)[0]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[1]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[2]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[3])

-:98: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'train_set' - possible 
side-effects?
#98: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:426:
+#define TRAIN_SET_VSWING_ARGS(train_set) \
+   _TRAIN_SET_VSWING_ARGS((train_set)[0]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[1]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[2]), \
+   _TRAIN_SET_VSWING_ARGS((train_set)[3])

-:103: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'train_set' - possible 
side-effects?
#103: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:431:
+#define _TRAIN_SET_PREEMPH_ARGS(train_set) \
+   ((train_set) & DP_TRAIN_PRE_EMPHASIS_MASK) >> 
DP_TRAIN_PRE_EMPHASIS_SHIFT, \
+   (train_set) & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ? "(max)" : ""

-:106: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#106: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:434:
+#define TRAIN_SET_PREEMPH_ARGS(train_set) \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[0]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[1]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[2]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[3])

-:106: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'train_set' - possible 
side-effects?
#106: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:434:
+#define TRAIN_SET_PREEMPH_ARGS(train_set) \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[0]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[1]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[2]), \
+   _TRAIN_SET_PREEMPH_ARGS((train_set)[3])

total: 2 errors, 0 warnings, 4 checks, 111 lines checked
def5bc2e3c93 drm/i915: Allow per-lane drive settings with LTTPRs

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: DP per-lane drive settings prep work (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev4)
URL   : https://patchwork.freedesktop.org/series/95122/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block

Re: [Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

[Harry Wentland]

On 2021-09-28 23:58, Navare, Manasi D wrote:
> [AMD Official Use Only]
> 
> We have merged such DRM definition dependencies previously through a topic 
> branch in order to avoid redefining inside the driver.
> But yes guarding this with ifdef is good.
> 
> Reviewed-by: Manasi Navare 
> 

Ah, I merged it already. But thanks for your review.

I agree these are better defined in drm headers, with a preparatory
patch if needed by the driver. We're working on cleaning it up and
dropping the driver defines.

Harry

> Manasi
> 
> -Original Message-
> From: Zuo, Jerry 
> Sent: Tuesday, September 28, 2021 11:11 PM
> To: Wentland, Harry ; Deucher, Alexander 
> ; amd-...@lists.freedesktop.org
> Cc: Nikula, Jani ; Li, Sun peng (Leo) 
> ; nat...@kernel.org; intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Navare, 
> Manasi D ; Koenig, Christian 
> ; Pan, Xinhui ; 
> s...@canb.auug.org.au; linux-n...@vger.kernel.org; airl...@gmail.com; 
> daniel.vet...@ffwll.ch; Wentland, Harry 
> Subject: RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not 
> already defined
> 
> [AMD Official Use Only]
> 
>> -Original Message-
>> From: Harry Wentland 
>> Sent: September 28, 2021 1:08 PM
>> To: Deucher, Alexander ; amd-
>> g...@lists.freedesktop.org; Zuo, Jerry 
>> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
>> nat...@kernel.org; intel-gfx@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
>> manasi.d.nav...@intel.com; Koenig, Christian
>> ; Pan, Xinhui ;
>> s...@canb.auug.org.au; linux- n...@vger.kernel.org; airl...@gmail.com;
>> daniel.vet...@ffwll.ch; Wentland, Harry 
>> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
>> already defined
>>
>> [Why]
>> For some reason we're defining DP 2.0 definitions inside our driver.
>> Now that patches to introduce relevant definitions are slated to be
>> merged into drm- next this is causing conflicts.
>>
>> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
>> ./include/drm/drm_dp_helper.h:1322:9: error:
>> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
>> Werror,-Wmacro-redefined]
>> ^
>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
>> previous definition is here
>> ^
>> 1 error generated.
>>
>> v2: Add one missing endif
>>
>> [How]
>> Guard all display driver defines with #ifndef for now. Once we pull in
>> the new definitions into amd-staging-drm-next we will follow up and
>> drop definitions from our driver and provide follow-up header updates
>> for any addition DP
>> 2.0 definitions required by our driver.
>>
>> Signed-off-by: Harry Wentland 
> 
> Reviewed-by: Fangzhi Zuo 
> 
>> ---
>>  drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
>> ++--
>>  1 file changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> index a5e798b5da79..9de86ff5ef1b 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> @@ -860,28 +860,72 @@ struct psr_caps {  };
>>
>>  #if defined(CONFIG_DRM_AMD_DC_DCN)
>> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
>>  #define DP_MAIN_LINK_CHANNEL_CODING_CAP  0x006
>> +#endif
>> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
>>  #define DP_SINK_VIDEO_FALLBACK_FORMATS   0x020
>> +#endif
>> +#ifndef DP_FEC_CAPABILITY_1
>>  #define DP_FEC_CAPABILITY_1  0x091
>> +#endif
>> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
>>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0A3
>> +#endif
>> +#ifndef DP_DSC_CONFIGURATION
>>  #define DP_DSC_CONFIGURATION 0x161
>> +#endif
>> +#ifndef DP_PHY_SQUARE_PATTERN
>>  #define DP_PHY_SQUARE_PATTERN0x249
>> +#endif
>> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
>>  #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
>> +#endif
>> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>>  #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>>   0x2216
>> +#endif
>> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
>>  #define DP_TEST_264BIT_CUSTOM_PATTERN_7_00X2230
>> +#endif
>> +#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>>  #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256
>>   0X2250
>> +#endif
>> +#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
>>  #define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260
>> +#endif
>> +#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>>  #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
>>   0x2270
>> -# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 <<
>> 0)
>> -# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
>>   (0b

Re: [Intel-gfx] [PATCH 4/7] drm/i915/display/psr: Handle plane restrictions at every page flip

[Gwan-gyeong Mun]

On 9/23/21 10:46 PM, José Roberto de Souza wrote:

PSR2 selective is not supported over rotated and scaled planes.
We had the rotation check in intel_psr2_sel_fetch_config_valid()
but that code path is only execute when a modeset is needed and
change those plane parameters do not require a modeset.

Also need to check those restricions in the second
for_each_oldnew_intel_plane_in_state() loop because the state could
only have a plane that is not affected by those restricitons but
the damaged area intersect with planes that has those restrictions,
so a full plane fetch is required.

BSpec: 55229
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
  drivers/gpu/drm/i915/display/intel_psr.c | 45 ++--
  1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 1cc4130dec7b1..356e0e96abf4e 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -720,11 +720,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp 
*intel_dp,
  static bool intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
  struct intel_crtc_state 
*crtc_state)
  {
-   struct intel_atomic_state *state = 
to_intel_atomic_state(crtc_state->uapi.state);
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   struct intel_plane_state *plane_state;
-   struct intel_plane *plane;
-   int i;
  
  	if (!dev_priv->params.enable_psr2_sel_fetch &&

intel_dp->psr.debug != I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
@@ -739,14 +735,6 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
  
-	for_each_new_intel_plane_in_state(state, plane, plane_state, i) {

-   if (plane_state->uapi.rotation != DRM_MODE_ROTATE_0) {
-   drm_dbg_kms(&dev_priv->drm,
-   "PSR2 sel fetch not enabled, plane 
rotated\n");
-   return false;
-   }
-   }
-
/* Wa_14010254185 Wa_14010103792 */
if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
drm_dbg_kms(&dev_priv->drm,
@@ -1586,6 +1574,26 @@ static void cursor_area_workaround(const struct 
intel_plane_state *new_plane_sta
clip_area_update(pipe_clip, damaged_area);
  }
  
+/*

+ * TODO: Not clear how to handle planes with negative position,
+ * also planes are not updated if they have a negative X
+ * position so for now doing a full update in this cases
+ *
+ * Plane scaling and rotation is not supported by selective fetch and both
+ * properties can change without a modeset, so need to be check at every
+ * atomic commmit.
+ */
+static bool psr2_sel_fetch_plane_state_supported(const struct 
intel_plane_state *plane_state)
+{
+   if (plane_state->uapi.dst.y1 < 0 ||
+   plane_state->uapi.dst.x1 < 0 ||
intel_atomic_plane_check_clipping() function makes 
plane_state->uapi.dst.x1 and plane_state->uapi.dst.y1 non-negative 
values, so there is no need to deal with negative positions here.


And the rest of the changes look good to me.

+   plane_state->scaler_id >= 0 ||
+   plane_state->uapi.rotation != DRM_MODE_ROTATE_0)
+   return false;
+
+   return true;
+}
+
  int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
  {
@@ -1618,13 +1626,7 @@ int intel_psr2_sel_fetch_update(struct 
intel_atomic_state *state,
!old_plane_state->uapi.visible)
continue;
  
-		/*

-* TODO: Not clear how to handle planes with negative position,
-* also planes are not updated if they have a negative X
-* position so for now doing a full update in this cases
-*/
-   if (new_plane_state->uapi.dst.y1 < 0 ||
-   new_plane_state->uapi.dst.x1 < 0) {
+   if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {
full_update = true;
break;
}
@@ -1703,6 +1705,11 @@ int intel_psr2_sel_fetch_update(struct 
intel_atomic_state *state,
if (!drm_rect_intersect(&inter, &new_plane_state->uapi.dst))
continue;
  
+		if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {

+   full_update = true;
+   break;
+   }
+
sel_fetch_area = &new_plane_state->psr2_sel_fetch_area;
sel_fetch_area->y1 = inter.y1 - new_plane_state->uapi.dst.y1;
sel_fetch_area->y2 = inter.y2 - new_plane_state->uapi.dst.y1;

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gen11: Disable cursor clock gating in HDR mode (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev7)
URL   : https://patchwork.freedesktop.org/series/91674/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21190_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-skl9/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][2] ([i915#280]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-tglb8/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: NOTRUN -> [TIMEOUT][3] ([i915#2369] / [i915#3063] / 
[i915#3648])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-tglb3/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-iclb1/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][6] -> [FAIL][7] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-glk9/igt@gem_exec_f...@basic-deadline.html
- shard-apl:  NOTRUN -> [FAIL][8] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-apl7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][9] ([fdo#109271]) +139 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-skl3/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-glk4/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-iclb8/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#112283])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-tglb3/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#644])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl2/igt@gem_pp...@flink-and-close-vma-leak.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/shard-skl7/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pread@exhaustion:
- shard-kbl:  NOTRUN -> [WARN][22] ([i915#2658])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21190/sha

Re: [Intel-gfx] [PATCH v2] drm/i915/bdb: Fix version check

[Souza, Jose]

On Thu, 2021-09-23 at 18:49 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch calculates expected size of the structure for a given
> BDB version and compares it with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)

Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")

> 
> Tested-by: Lukasz Majczak 
> Signed-off-by: Lukasz Majczak 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 11 +--
>  drivers/gpu/drm/i915/display/intel_vbt_defs.h |  5 +
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..90eae6da12e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -428,6 +428,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>   const struct lfp_backlight_data_entry *entry;
>   int panel_type = i915->vbt.panel_type;
>   u16 level;
> + size_t exp_size;
>  
>   backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
>   if (!backlight_data)
> @@ -450,9 +451,15 @@ parse_lfp_backlight(struct drm_i915_private *i915,
>   return;
>   }
>  
> + if (bdb->version <= 234)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> + else if (bdb->version > 234 && bdb->version <= 236)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_236;
> + else
> + exp_size = sizeof(struct bdb_lfp_backlight_data);

Usually we go by the newest(IP version, platform...) to the oldest:


if (bdb->version >= 236)
exp_size = sizeof(struct bdb_lfp_backlight_data);
else if (bdb->version >= 234)
exp_size = offsetof(struct bdb_lfp_backlight_data, 
brightness_precision_bits);
else
exp_size = offsetof(struct bdb_lfp_backlight_data, brightness_level);


backlight_control was added in version 191 so no need to set exp_size for older 
versions.

> +
>   i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> - if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> + if (bdb->version >= 191  && get_blocksize(backlight_data) >= exp_size) {
>   const struct lfp_backlight_control_method *method;
>  
>   method = &backlight_data->backlight_control[panel_type];
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..ba9990e5983c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
>   u16 reserved;
>  } __packed;
>  
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_level)

version 234 starts at brightness_level but the size of 234 data must be 
included to the size, so it should be:
offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits).

> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_236 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)

> +
>  struct bdb_lfp_backlight_data {
>   u8 entry_size;
>   struct lfp_backlight_data_entry data[16];

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DP per-lane drive settings prep work (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev4)
URL   : https://patchwork.freedesktop.org/series/95122/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21192


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (33 -> 28)
--

  Missing(5): bat-dg1-6 fi-tgl-u2 fi-bsw-cyan bat-adlp-4 bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21192

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21192: def5bc2e3c93d986e7f69476bb0722ea7cbe0f11 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

def5bc2e3c93 drm/i915: Allow per-lane drive settings with LTTPRs
24cdd73489e8 drm/i915: Prepare link training for per-lane drive settings
68f42730e749 drm/i915: Pass the lane to intel_ddi_level()
025b7bd7473d drm/i915: Nuke intel_ddi_hdmi_num_entries()
40be81462b60 drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()
96ccc8d77127 drm/i915: De-wrapper bxt_ddi_phy_set_signal_levels()
148ee4908c2b drm/i915: Nuke usless .set_signal_levels() wrappers
12af5655d6e9 drm/i915: Generalize .set_signal_levels()
5ca7aed58062 drm/i915: s/ddi_translations/trans/

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915/display/psr: Handle plane restrictions at every page flip

[Ville Syrjälä]

On Wed, Sep 29, 2021 at 08:50:12PM +0300, Gwan-gyeong Mun wrote:
> 
> 
> On 9/23/21 10:46 PM, José Roberto de Souza wrote:
> > PSR2 selective is not supported over rotated and scaled planes.
> > We had the rotation check in intel_psr2_sel_fetch_config_valid()
> > but that code path is only execute when a modeset is needed and
> > change those plane parameters do not require a modeset.
> > 
> > Also need to check those restricions in the second
> > for_each_oldnew_intel_plane_in_state() loop because the state could
> > only have a plane that is not affected by those restricitons but
> > the damaged area intersect with planes that has those restrictions,
> > so a full plane fetch is required.
> > 
> > BSpec: 55229
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >   drivers/gpu/drm/i915/display/intel_psr.c | 45 ++--
> >   1 file changed, 26 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 1cc4130dec7b1..356e0e96abf4e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -720,11 +720,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp 
> > *intel_dp,
> >   static bool intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
> >   struct intel_crtc_state 
> > *crtc_state)
> >   {
> > -   struct intel_atomic_state *state = 
> > to_intel_atomic_state(crtc_state->uapi.state);
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > -   struct intel_plane_state *plane_state;
> > -   struct intel_plane *plane;
> > -   int i;
> >   
> > if (!dev_priv->params.enable_psr2_sel_fetch &&
> > intel_dp->psr.debug != I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
> > @@ -739,14 +735,6 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
> > intel_dp *intel_dp,
> > return false;
> > }
> >   
> > -   for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
> > -   if (plane_state->uapi.rotation != DRM_MODE_ROTATE_0) {
> > -   drm_dbg_kms(&dev_priv->drm,
> > -   "PSR2 sel fetch not enabled, plane 
> > rotated\n");
> > -   return false;
> > -   }
> > -   }
> > -
> > /* Wa_14010254185 Wa_14010103792 */
> > if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > drm_dbg_kms(&dev_priv->drm,
> > @@ -1586,6 +1574,26 @@ static void cursor_area_workaround(const struct 
> > intel_plane_state *new_plane_sta
> > clip_area_update(pipe_clip, damaged_area);
> >   }
> >   
> > +/*
> > + * TODO: Not clear how to handle planes with negative position,
> > + * also planes are not updated if they have a negative X
> > + * position so for now doing a full update in this cases
> > + *
> > + * Plane scaling and rotation is not supported by selective fetch and both
> > + * properties can change without a modeset, so need to be check at every
> > + * atomic commmit.
> > + */
> > +static bool psr2_sel_fetch_plane_state_supported(const struct 
> > intel_plane_state *plane_state)
> > +{
> > +   if (plane_state->uapi.dst.y1 < 0 ||
> > +   plane_state->uapi.dst.x1 < 0 ||
> intel_atomic_plane_check_clipping() function makes 
> plane_state->uapi.dst.x1 and plane_state->uapi.dst.y1 non-negative 
> values, so there is no need to deal with negative positions here.

Cursor can have negative coordinates as it's hardware that will do the
clipping for us.

> 
> And the rest of the changes look good to me.
> > +   plane_state->scaler_id >= 0 ||
> > +   plane_state->uapi.rotation != DRM_MODE_ROTATE_0)
> > +   return false;
> > +
> > +   return true;
> > +}
> > +
> >   int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
> > struct intel_crtc *crtc)
> >   {
> > @@ -1618,13 +1626,7 @@ int intel_psr2_sel_fetch_update(struct 
> > intel_atomic_state *state,
> > !old_plane_state->uapi.visible)
> > continue;
> >   
> > -   /*
> > -* TODO: Not clear how to handle planes with negative position,
> > -* also planes are not updated if they have a negative X
> > -* position so for now doing a full update in this cases
> > -*/
> > -   if (new_plane_state->uapi.dst.y1 < 0 ||
> > -   new_plane_state->uapi.dst.x1 < 0) {
> > +   if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {
> > full_update = true;
> > break;
> > }
> > @@ -1703,6 +1705,11 @@ int intel_psr2_sel_fetch_update(struct 
> > intel_atomic_state *state,
> > if (!drm_rect_intersect(&inter, &new_plane_state->uapi.dst))
> > continue;
> >   
> > +   if (!psr2_sel_fetch_plane_state_supported(new_plane_state)) {
> > +   full_update = tru

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

[Wang, Zhi A]

On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
>
>> Yes. I was thinking of the possibility of putting off some work later so
>> that we don't need to make a lot of changes. GVT-g needs to take a
>> snapshot of GPU registers as the initial virtual states for other vGPUs,
>> which requires the initialization happens at a certain early time of
>> initialization of i915. I was thinking maybe we can take other patches
>> from Christoph like "de-virtualize*" except this one because currently
>> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built
>> as kernel module.
> How about just capture these registers in the main module/device and
> not try so hard to isolate it to the gvt stuff?

Hi Jason:

Thanks for the idea. I am not sure i915 guys would take this idea since 
that it's only for GVT-g, i915 doesn't use this at all. We need to take 
a snapshot of both PCI configuration space and MMIO registers before 
i915 driver starts to touch the HW.

One idea is we capture the registers in intel_gvt.c during the early 
initialization and do everything else when i915.ko is fully loaded. But 
how about dependence between i915.ko and kvmgt.ko? We cannot do 
request_module("kvmgt") in i915.ko.

Maybe Christoph can give more input on this and how we can deal with 
this? Before we figure out an solution, we have to pick that patch out 
since it blocks our pull request schedule.

Also I was thinking if moving gvt into kvmgt.ko is the right direction. 
It seems the module loading system in kernel is not designed for "module 
A loading module B, which needs symbols from module A, in the 
initialization path of module A".

Thanks,

Zhi.

> Jason

[Intel-gfx] [PATCH v2 0/3] Rename IS_ACTIVE() and move to kconfig.h

[Lucas De Marchi]

As we try to reduce our i915-only helpers, let's try to improve
IS_ACTIVE() logic and move to kconfig.h.

I'm not 100% happy with the name, but it's the best I could come up
with, hopefully a little better than trying to add IS_ACTIVE() to be
used broadly.

v2: now with Cc/To list fixed up - no changes to the patches.

Lucas De Marchi (3):
  drm/i915: rename IS_ACTIVE
  drm/i915/utils: do not depend on config being defined
  Move IS_CONFIG_NONZERO() to kconfig.h

 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |  4 ++--
 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h |  2 +-
 .../gpu/drm/i915/gt/intel_execlists_submission.c |  2 +-
 .../gpu/drm/i915/gt/selftest_engine_heartbeat.c  |  4 ++--
 drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++---
 drivers/gpu/drm/i915/i915_config.c   |  2 +-
 drivers/gpu/drm/i915/i915_request.c  |  2 +-
 drivers/gpu/drm/i915/i915_utils.h| 13 -
 include/linux/kconfig.h  | 16 ++--
 12 files changed, 32 insertions(+), 33 deletions(-)

-- 
2.33.0

[Intel-gfx] [PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h

[Lucas De Marchi]

The check for config value doesn't really belong to i915_utils.h - we
are trying to eliminate that utils helper and share them when possible
with other drivers and subsystems.

Rationale for having such macro is in commit
babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean 
predicates")
whereas later it is improved to not break the build if used with
undefined configs. The caveat is detailed in the documentation: unlike
IS_ENABLED(): it's not preprocessor-only logic so can't be used for
things like `#if IS_CONFIG_NONZERO(...)`

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_utils.h | 17 -
 include/linux/kconfig.h   | 16 ++--
 2 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 436ce612c46a..62f189e064a9 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -459,20 +458,4 @@ static inline bool timer_expired(const struct timer_list 
*t)
return timer_active(t) && !timer_pending(t);
 }
 
-/*
- * This is a lookalike for IS_ENABLED() that takes a kconfig value,
- * e.g. CONFIG_DRM_I915_SPIN_REQUEST, and evaluates whether it is non-zero
- * i.e. whether the configuration is active. Wrapping up the config inside
- * a boolean context prevents clang and smatch from complaining about potential
- * issues in confusing logical-&& with bitwise-& for constants.
- *
- * Sadly IS_ENABLED() itself does not work with kconfig values.
- *
- * Returns 0 if @config is 0, 1 if set to any value.
- */
-#define IS_CONFIG_NONZERO(config) (
\
-   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
\
-   __stringify_1(config)[0] == '-' 
\
-)
-
 #endif /* !__I915_UTILS_H */
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index 20d1079e92b4..e84f7c1c8e26 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -2,6 +2,7 @@
 #ifndef __LINUX_KCONFIG_H
 #define __LINUX_KCONFIG_H
 
+#include 
 #include 
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
@@ -26,8 +27,8 @@
 #define or(arg1_or_junk, y)__take_second_arg(arg1_or_junk 
1, y)
 
 /*
- * Helper macros to use CONFIG_ options in C/CPP expressions. Note that
- * these only work with boolean and tristate options.
+ * Helper macros to use CONFIG_ options in C/CPP expressions. Note that except
+ * for IS_CONFIG_NONZERO, these only work with boolean and tristate options.
  */
 
 /*
@@ -72,4 +73,15 @@
  */
 #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
 
+/*
+ * This is a lookalike for IS_ENABLED(), but works with int kconfig options
+ * with the caveat that it can't be used on preprocessor checks.
+ *
+ * Returns 0 if @config is 0 or undefined, 1 if set to any value.
+ */
+#define IS_CONFIG_NONZERO(config) (
\
+   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
\
+   __stringify_1(config)[0] == '-' 
\
+)
+
 #endif /* __LINUX_KCONFIG_H */
-- 
2.33.0

[Intel-gfx] [PATCH v2 1/3] drm/i915: rename IS_ACTIVE

[Lucas De Marchi]

It took me some time to understand the need for IS_ACTIVE and why we
couldn't use kconfig.h. Rename it to something else that would be more
suitable to include in kconfig.h and shared with other subsystems rather
than maintaining it only in i915.

Name here is pretty open for suggestions, but I think this is slightly
better than "active".

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine.h |  4 ++--
 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h   |  2 +-
 .../gpu/drm/i915/gt/intel_execlists_submission.c   |  2 +-
 .../gpu/drm/i915/gt/selftest_engine_heartbeat.c|  4 ++--
 drivers/gpu/drm/i915/gt/selftest_execlists.c   | 14 +++---
 drivers/gpu/drm/i915/i915_config.c |  2 +-
 drivers/gpu/drm/i915/i915_request.c|  2 +-
 drivers/gpu/drm/i915/i915_utils.h  |  2 +-
 11 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..ff748441a0e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -761,7 +761,7 @@ static int intel_context_set_gem(struct intel_context *ce,
intel_engine_has_semaphores(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
 
-   if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+   if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
ctx->i915->params.request_timeout_ms) {
unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5130e8ed9564..9e12c026e59f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -395,7 +395,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
/* Track the mmo associated with the fenced vma */
vma->mmo = mmo;
 
-   if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
+   if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
   
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 87579affb952..f181c8654cbf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -273,7 +273,7 @@ static inline bool intel_engine_uses_guc(const struct 
intel_engine_cs *engine)
 static inline bool
 intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
 {
-   if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
+   if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
return false;
 
return intel_engine_has_preemption(engine);
@@ -300,7 +300,7 @@ intel_virtual_engine_has_heartbeat(const struct 
intel_engine_cs *engine)
 static inline bool
 intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
 {
-   if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+   if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return false;
 
if (intel_engine_is_virtual(engine))
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 74775ae961b2..9b2eb0491c9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -207,7 +207,7 @@ static void heartbeat(struct work_struct *wrk)
 
 void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine)
 {
-   if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+   if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
return;
 
next_heartbeat(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5ae1207c363b..938b49e41e48 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -556,7 +556,7 @@ intel_engine_has_semaphores(const struct intel_engine_cs 
*engine)
 static inline bool
 intel_engine_has_timeslices(const struct intel_engine_cs *engine)
 {
-   if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+   if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
 
return engine->flags & I915_ENGINE_HAS_TIMESLICES;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7147fe80919e..851dce6bfc6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/inte

[Intel-gfx] [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined

[Lucas De Marchi]

Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.

The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.

Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:

old:
 if (((2) != 0) &&
new:
 if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&

New one looks worse, but is also eliminated from the object:

$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
   textdata bss dec hex filename
  520211070 232   53323d04b 
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
  520211070 232   53323d04b 
drivers/gpu/drm/i915/gem/i915_gem_context.o.old

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_utils.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
  *
  * Returns 0 if @config is 0, 1 if set to any value.
  */
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
\
+   __stringify_1(config)[0] == '-' 
\
+)
 
 #endif /* !__I915_UTILS_H */
-- 
2.33.0

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Rename IS_ACTIVE() and move to kconfig.h

[Patchwork]

== Series Details ==

Series: Rename IS_ACTIVE() and move to kconfig.h
URL   : https://patchwork.freedesktop.org/series/95229/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
700a1ad38302 drm/i915: rename IS_ACTIVE
74e2f2ef0ee5 drm/i915/utils: do not depend on config being defined
-:29: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#29: 
  520211070 232   53323d04b 
drivers/gpu/drm/i915/gem/i915_gem_context.o.new

-:51: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'config' - possible 
side-effects?
#51: FILE: drivers/gpu/drm/i915/i915_utils.h:473:
+#define IS_CONFIG_NONZERO(config) (
\
+   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
\
+   __stringify_1(config)[0] == '-' 
\
+)

total: 0 errors, 1 warnings, 1 checks, 17 lines checked
c3464f46082b Move IS_CONFIG_NONZERO() to kconfig.h
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean 
predicates")

-:85: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'config' - possible 
side-effects?
#85: FILE: include/linux/kconfig.h:82:
+#define IS_CONFIG_NONZERO(config) (
\
+   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
\
+   __stringify_1(config)[0] == '-' 
\
+)

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

[Intel-gfx] [PATCH v3 5/6] drm/i915: Reject user modes that don't match fixed mode's refresh rate

[Ville Syrjala]

From: Ville Syrjälä 

When using a panel with a fixed mode we don't change the refresh
rate of the display. Reject any user requested mode which doesn't
match that fixed refresh rate.

Unfortunately when Xorg sees the scaling_mode property on the
connecor it likes to automagically cook up modes whose refresh
rate is a fair bit off from the fixed refresh rate we use. So
we have to give it some extra latitude so that we don't start to
reject all of it.

v2: sDVO now uses intel_panel_compute_config() too
v3: Add a debug message to inform the user what happened

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 77c1ca387de0..a0c8e43db5eb 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -53,6 +53,21 @@ int intel_panel_compute_config(struct intel_connector 
*connector,
if (!fixed_mode)
return 0;
 
+   /*
+* We don't want to lie too much to the user about the refresh
+* rate they're going to get. But we have to allow a bit of latitude
+* for Xorg since it likes to automagically cook up modes with slightly
+* off refresh rates.
+*/
+   if (abs(drm_mode_vrefresh(adjusted_mode) - 
drm_mode_vrefresh(fixed_mode)) > 1) {
+   drm_dbg_kms(connector->base.dev,
+   "[CONNECTOR:%d:%s] Requested mode vrefresh (%d Hz) 
does not match fixed mode vrefresh (%d Hz)\n",
+   connector->base.base.id, connector->base.name,
+   drm_mode_vrefresh(adjusted_mode), 
drm_mode_vrefresh(fixed_mode));
+
+   return -EINVAL;
+   }
+
drm_mode_copy(adjusted_mode, fixed_mode);
 
drm_mode_set_crtcinfo(adjusted_mode, 0);
-- 
2.32.0

[Intel-gfx] ✓ Fi.CI.BAT: success for Rename IS_ACTIVE() and move to kconfig.h

[Patchwork]

== Series Details ==

Series: Rename IS_ACTIVE() and move to kconfig.h
URL   : https://patchwork.freedesktop.org/series/95229/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21193


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21193

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21193: c3464f46082bfe80c44da890b292d50b27344688 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c3464f46082b Move IS_CONFIG_NONZERO() to kconfig.h
74e2f2ef0ee5 drm/i915/utils: do not depend on config being defined
700a1ad38302 drm/i915: rename IS_ACTIVE

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Generalize .set_signal_levels()

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently .set_signal_levels() is only used by encoders in DP mode.
> For most modern platforms there is no essential difference between
> DP and HDMI, and both codepaths just end up calling the same function
> under the hood. Let's get remove the need for that extra indirection
> by moving .set_signal_levels() into the encoder from intel_dp.
> Since we already plumb the crtc_state/etc. into .set_signal_levels()
> the code will do the right thing for both DP and HDMI.

I wondered about the rational to add vfuncs to intel_digital_port or
intel_encoder, I assume the latter needs less type casting.

> HSW/BDW/SKL are the only platforms that need a bit of care on
> account of having to preload the hardware buf_trans register
> with the full set of values. So we must still remember to call
> hsw_prepare_{dp,hdmi}_ddi_buffers() to do said preloading, and
> .set_signal_levels() will just end up selecting the correct entry
> for DP, and also setting up the iboost magic for both DP and HDMI.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/g4x_dp.c |  33 +++---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 108 +-
>  .../drm/i915/display/intel_display_types.h|   5 +-
>  .../drm/i915/display/intel_dp_link_training.c |   5 +-
>  4 files changed, 75 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index 8e0620ae2ed1..e348f075a41d 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -813,10 +813,10 @@ static u8 intel_dp_preemph_max_3(struct intel_dp 
> *intel_dp)
>   return DP_TRAIN_PRE_EMPH_LEVEL_3;
>  }
>  
> -static void vlv_set_signal_levels(struct intel_dp *intel_dp,
> +static void vlv_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   unsigned long demph_reg_value, preemph_reg_value,
>   uniqtranscale_reg_value;
>   u8 train_set = intel_dp->train_set[0];
> @@ -899,10 +899,10 @@ static void vlv_set_signal_levels(struct intel_dp 
> *intel_dp,
>uniqtranscale_reg_value, 0);
>  }
>  
> -static void chv_set_signal_levels(struct intel_dp *intel_dp,
> +static void chv_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   u32 deemph_reg_value, margin_reg_value;
>   bool uniq_trans_scale = false;
>   u8 train_set = intel_dp->train_set[0];
> @@ -1020,10 +1020,11 @@ static u32 g4x_signal_levels(u8 train_set)
>  }
>  
>  static void
> -g4x_set_signal_levels(struct intel_dp *intel_dp,
> +g4x_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   u8 train_set = intel_dp->train_set[0];
>   u32 signal_levels;
>  
> @@ -1067,10 +1068,11 @@ static u32 snb_cpu_edp_signal_levels(u8 train_set)
>  }
>  
>  static void
> -snb_cpu_edp_set_signal_levels(struct intel_dp *intel_dp,
> +snb_cpu_edp_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   u8 train_set = intel_dp->train_set[0];
>   u32 signal_levels;
>  
> @@ -1118,10 +1120,11 @@ static u32 ivb_cpu_edp_signal_levels(u8 train_set)
>  }
>  
>  static void
> -ivb_cpu_edp_set_signal_levels(struct intel_dp *intel_dp,
> +ivb_cpu_edp_set_signal_levels(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state)
>  {
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   u8 train_set = intel_dp->train_set[0];
>   u32 signal_levels;
>  
> @@ -1364,15 +1367,15 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
>   dig_port->dp.set_link_train = g4x_set_link_train;
>  
>   if (IS_CHERRYVIEW(dev_priv))
> - dig_port->dp.set_signal_levels = chv_set_signal_levels;
> + intel_encoder->set_signal_levels = chv_set_signal_levels;
>   else 

Re: [Intel-gfx] [PATCH v2 01/13] drm/i915/tc: Fix TypeC port init/resume time sanitization

[Souza, Jose]

On Wed, 2021-09-29 at 16:28 +0300, Imre Deak wrote:
> Atm during driver loading and system resume TypeC ports are accessed
> before their HW/SW state is synced. Move the TypeC port sanitization to
> the encoder's sync_state hook to fix this.
> 
> v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well
> (Jose, Jani)

Reviewed-by: José Roberto de Souza 

> 
> Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state 
> during init/resume")
> Cc: José Roberto de Souza 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c   | 10 --
>  drivers/gpu/drm/i915/display/intel_ddi.c |  8 +++-
>  drivers/gpu/drm/i915/display/intel_display.c | 20 +---
>  3 files changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 060bc8fb0d307..bd210166b0793 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1599,8 +1599,14 @@ static void gen11_dsi_sync_state(struct intel_encoder 
> *encoder,
>const struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - enum pipe pipe = intel_crtc->pipe;
> + struct intel_crtc *intel_crtc;
> + enum pipe pipe;
> +
> + if (!crtc_state)
> + return;
> +
> + intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + pipe = intel_crtc->pipe;
>  
>   /* wa verify 1409054076:icl,jsl,ehl */
>   if (DISPLAY_VER(dev_priv) == 11 && pipe == PIPE_B &&
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a4667741d3548..04572ce6630f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3838,7 +3838,13 @@ void hsw_ddi_get_config(struct intel_encoder *encoder,
>  static void intel_ddi_sync_state(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state)
>  {
> - if (intel_crtc_has_dp_encoder(crtc_state))
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> +
> + if (intel_phy_is_tc(i915, phy))
> + intel_tc_port_sanitize(enc_to_dig_port(encoder));
> +
> + if (crtc_state && intel_crtc_has_dp_encoder(crtc_state))
>   intel_dp_sync_state(encoder, crtc_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9e407760e51f6..5f241e2415cea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12285,18 +12285,16 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   readout_plane_state(dev_priv);
>  
>   for_each_intel_encoder(dev, encoder) {
> + struct intel_crtc_state *crtc_state = NULL;
> +
>   pipe = 0;
>  
>   if (encoder->get_hw_state(encoder, &pipe)) {
> - struct intel_crtc_state *crtc_state;
> -
>   crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
>   crtc_state = to_intel_crtc_state(crtc->base.state);
>  
>   encoder->base.crtc = &crtc->base;
>   intel_encoder_get_config(encoder, crtc_state);
> - if (encoder->sync_state)
> - encoder->sync_state(encoder, crtc_state);
>  
>   /* read out to slave crtc as well for bigjoiner */
>   if (crtc_state->bigjoiner) {
> @@ -12311,6 +12309,9 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   encoder->base.crtc = NULL;
>   }
>  
> + if (encoder->sync_state)
> + encoder->sync_state(encoder, crtc_state);
> +
>   drm_dbg_kms(&dev_priv->drm,
>   "[ENCODER:%d:%s] hw state readout: %s, pipe %c\n",
>   encoder->base.base.id, encoder->base.name,
> @@ -12593,17 +12594,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>   intel_modeset_readout_hw_state(dev);
>  
>   /* HW state is read out, now we need to sanitize this mess. */
> -
> - /* Sanitize the TypeC port mode upfront, encoders depend on this */
> - for_each_intel_encoder(dev, encoder) {
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> -
> - /* We need to sanitize only the MST primary port. */
> - if (encoder->type != INTEL_OUTPUT_DP_MST &&
> - intel_phy_is_tc(dev_priv, phy))
> - intel_tc_port_sanitize(enc_to_dig_port(encoder));
> - }
> -
>

[Intel-gfx] [PATCH v3] drm/i915: Update memory bandwidth formulae

[Radhakrishna Sripada]

The formulae has been updated to include more variables. Make
sure the code carries the same.

Bspec: 64631

v2: Make GEN11 follow the default route and fix calculation of
maxdebw(RK)
v3: Fix div by zero on Gen11 and Correct indent for fallthrough(Jani)

Cc: Ville Syrjälä 
Suggested-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 69 -
 1 file changed, 56 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 4b94256d7319..d9de2a812b27 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -27,6 +27,9 @@ struct intel_qgv_info {
u8 num_points;
u8 num_psf_points;
u8 t_bl;
+   u8 max_numchannels;
+   u8 channel_width;
+   u8 deinterleave;
 };
 
 static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
@@ -137,6 +140,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
 {
const struct dram_info *dram_info = &dev_priv->dram_info;
int i, ret;
+   bool is_y_tile = true; /* assume y tile may be used */
 
qi->num_points = dram_info->num_qgv_points;
qi->num_psf_points = dram_info->num_psf_gv_points;
@@ -144,13 +148,35 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
if (DISPLAY_VER(dev_priv) == 12)
switch (dram_info->type) {
case INTEL_DRAM_DDR4:
-   qi->t_bl = 4;
+   qi->t_bl = is_y_tile ? 8 : 4;
+   qi->max_numchannels = 2;
+   qi->channel_width = 64;
+   qi->deinterleave = is_y_tile ? 1 : 2;
break;
case INTEL_DRAM_DDR5:
-   qi->t_bl = 8;
+   qi->t_bl = is_y_tile ? 16 : 8;
+   qi->max_numchannels = 4;
+   qi->channel_width = 32;
+   qi->deinterleave = is_y_tile ? 1 : 2;
+   break;
+   case INTEL_DRAM_LPDDR4:
+   if (IS_ROCKETLAKE(dev_priv)) {
+   qi->t_bl = 8;
+   qi->max_numchannels = 4;
+   qi->channel_width = 32;
+   qi->deinterleave = 2;
+   break;
+   }
+   fallthrough;
+   case INTEL_DRAM_LPDDR5:
+   qi->t_bl = 16;
+   qi->max_numchannels = 8;
+   qi->channel_width = 16;
+   qi->deinterleave = is_y_tile ? 2 : 4;
break;
default:
qi->t_bl = 16;
+   qi->max_numchannels = 1;
break;
}
else if (DISPLAY_VER(dev_priv) == 11)
@@ -263,12 +289,13 @@ static const struct intel_sa_info adlp_sa_info = {
 static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
intel_sa_info *sa)
 {
struct intel_qgv_info qi = {};
-   bool is_y_tile = true; /* assume y tile may be used */
+   const struct dram_info *dram_info = &dev_priv->dram_info;
int num_channels = max_t(u8, 1, dev_priv->dram_info.num_channels);
-   int deinterleave;
int ipqdepth, ipqdepthpch;
int dclk_max;
-   int maxdebw;
+   int maxdebw, peakbw;
+   int clperchgroup;
+   int num_groups = ARRAY_SIZE(dev_priv->max_bw);
int i, ret;
 
ret = icl_get_qgv_points(dev_priv, &qi);
@@ -278,22 +305,38 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
return ret;
}
 
-   deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
-   dclk_max = icl_sagv_max_dclk(&qi);
+   if (dram_info->type == INTEL_DRAM_LPDDR4 || dram_info->type == 
INTEL_DRAM_LPDDR5)
+   num_channels *= 2;
+
+   if (num_channels < qi.max_numchannels && DISPLAY_VER(dev_priv) >= 12)
+   qi.deinterleave = DIV_ROUND_UP(qi.deinterleave, 2);
+
+   num_channels = min_t(u8, num_channels, qi.max_numchannels);
+   dclk_max = icl_calc_bw(icl_sagv_max_dclk(&qi), 16, 1);
 
ipqdepthpch = 16;
 
-   maxdebw = min(sa->deprogbwlimit * 1000,
- icl_calc_bw(dclk_max, 16, 1) * 6 / 10); /* 60% */
+   peakbw = num_channels * DIV_ROUND_UP(qi.deinterleave, 8) * dclk_max;
+   maxdebw = min(sa->deprogbwlimit * 1000, peakbw * 6 / 10); /* 60% */
ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
+   /*
+* clperchgroup = 4kpagespermempage * clperchperblock,
+* clperchperblock = 8 /num_channels * interleave
+*/
+   clperchgroup = 4 * DIV_ROUND_UP(8, num_channels) * qi.deinterleave;
 
-   for (i = 0; 

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Nuke usless .set_signal_levels() wrappers

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Now that .set_signal_levels() is used for HDMI as well, we can
> remove the extra level of indirection and just plug the correct
> stuff straight into .set_signal_levels().
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 119 +-
>  drivers/gpu/drm/i915/display/intel_ddi.h  |   6 +-
>  drivers/gpu/drm/i915/display/intel_snps_phy.c |   7 +-
>  drivers/gpu/drm/i915/display/intel_snps_phy.h |   5 +-
>  4 files changed, 39 insertions(+), 98 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4a22dcde66d9..62ab57c391ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -995,11 +995,11 @@ static void skl_ddi_set_iboost(struct intel_encoder 
> *encoder,
>   _skl_ddi_set_iboost(dev_priv, PORT_E, iboost);
>  }
>  
> -static void bxt_ddi_vswing_sequence(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - int level)
> +static void bxt_set_signal_levels(struct intel_encoder *encoder,
> +   const struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + int level = intel_ddi_level(encoder, crtc_state);
>   const struct intel_ddi_buf_trans *trans;
>   enum port port = encoder->port;
>   int n_entries;
> @@ -1047,10 +1047,10 @@ static u8 intel_ddi_dp_preemph_max(struct intel_dp 
> *intel_dp)
>  }
>  
>  static void icl_ddi_combo_vswing_program(struct intel_encoder *encoder,
> -  const struct intel_crtc_state 
> *crtc_state,
> -  int level)
> +  const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + int level = intel_ddi_level(encoder, crtc_state);
>   const struct intel_ddi_buf_trans *trans;
>   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
>   int n_entries, ln;
> @@ -1109,9 +1109,8 @@ static void icl_ddi_combo_vswing_program(struct 
> intel_encoder *encoder,
>   intel_de_write(dev_priv, ICL_PORT_TX_DW7_GRP(phy), val);
>  }
>  
> -static void icl_combo_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
> -   const struct intel_crtc_state 
> *crtc_state,
> -   int level)
> +static void icl_combo_phy_set_signal_levels(struct intel_encoder *encoder,
> + const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> @@ -1162,7 +1161,7 @@ static void icl_combo_phy_ddi_vswing_sequence(struct 
> intel_encoder *encoder,
>   intel_de_write(dev_priv, ICL_PORT_TX_DW5_GRP(phy), val);
>  
>   /* 5. Program swing and de-emphasis */
> - icl_ddi_combo_vswing_program(encoder, crtc_state, level);
> + icl_ddi_combo_vswing_program(encoder, crtc_state);
>  
>   /* 6. Set training enable to trigger update */
>   val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
> @@ -1170,12 +1169,12 @@ static void icl_combo_phy_ddi_vswing_sequence(struct 
> intel_encoder *encoder,
>   intel_de_write(dev_priv, ICL_PORT_TX_DW5_GRP(phy), val);
>  }
>  
> -static void icl_mg_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
> -const struct intel_crtc_state 
> *crtc_state,
> -int level)
> +static void icl_mg_phy_set_signal_levels(struct intel_encoder *encoder,
> +  const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder->port);
> + int level = intel_ddi_level(encoder, crtc_state);
>   const struct intel_ddi_buf_trans *trans;
>   int n_entries, ln;
>   u32 val;
> @@ -1293,26 +1292,12 @@ static void icl_mg_phy_ddi_vswing_sequence(struct 
> intel_encoder *encoder,
>   }
>  }
>  
> -static void icl_ddi_vswing_sequence(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - int level)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> -
> - if (intel_phy_is_combo(dev_priv, phy))
> - icl_combo_phy_ddi_vswing_sequence(encoder, crtc_state, level);
> - else
> - icl_mg_phy_ddi_vswing_seq

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject bogus modes with fixed mode panels (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject bogus modes with fixed mode panels (rev4)
URL   : https://patchwork.freedesktop.org/series/95003/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21194


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-1115g4:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html

  
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21194

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21194: 757c93b34f28fa06ae5d6d3e8df3890209ccc560 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

757c93b34f28 drm/i915: Drop pointless fixed_mode checks from dsi code
3c1fa96c8f68 drm/i915: Reject user modes that don't match fixed mode's refresh 
rate
f7cdd9e01604 drm/i915: Introduce intel_panel_compute_config()
533507b364f4 drm/i915: Reject modes that don't match fixed_mode vrefresh
d9423a841736 drm/i915: Use intel_panel_mode_valid() for DSI/LVDS/DVO
1167de2f2bef drm/i915: Extract intel_panel_mode_valid()

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/9] drm/i915: De-wrapper bxt_ddi_phy_set_signal_levels()

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:50PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Convert bxt_ddi_phy_set_signal_levels() to act as the full
> .set_signal_levels() hook instead of going through a pointless wrapper.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 24 +--
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c | 30 +--
>  drivers/gpu/drm/i915/display/intel_dpio_phy.h |  5 ++--
>  3 files changed, 24 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 62ab57c391ef..970a796a4f52 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -995,28 +995,6 @@ static void skl_ddi_set_iboost(struct intel_encoder 
> *encoder,
>   _skl_ddi_set_iboost(dev_priv, PORT_E, iboost);
>  }
>  
> -static void bxt_set_signal_levels(struct intel_encoder *encoder,
> -   const struct intel_crtc_state *crtc_state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - int level = intel_ddi_level(encoder, crtc_state);
> - const struct intel_ddi_buf_trans *trans;
> - enum port port = encoder->port;
> - int n_entries;
> -
> - trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
> - return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
> -
> - bxt_ddi_phy_set_signal_level(dev_priv, port,
> -  trans->entries[level].bxt.margin,
> -  trans->entries[level].bxt.scale,
> -  trans->entries[level].bxt.enable,
> -  trans->entries[level].bxt.deemphasis);
> -}
> -
>  static u8 intel_ddi_dp_voltage_max(struct intel_dp *intel_dp,
>  const struct intel_crtc_state *crtc_state)
>  {
> @@ -4574,7 +4552,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   else
>   encoder->set_signal_levels = 
> icl_mg_phy_set_signal_levels;
>   } else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) {
> - encoder->set_signal_levels = bxt_set_signal_levels;
> + encoder->set_signal_levels = bxt_ddi_phy_set_signal_levels;
>   } else {
>   encoder->set_signal_levels = hsw_set_signal_levels;
>   }
> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> index 48507ed79950..4d604e4cfa5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> @@ -23,6 +23,8 @@
>  
>  #include "display/intel_dp.h"
>  
> +#include "intel_ddi.h"
> +#include "intel_ddi_buf_trans.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_dpio_phy.h"
> @@ -266,15 +268,24 @@ void bxt_port_to_phy_channel(struct drm_i915_private 
> *dev_priv, enum port port,
>   *ch = DPIO_CH0;
>  }
>  
> -void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
> -   enum port port, u32 margin, u32 scale,
> -   u32 enable, u32 deemphasis)
> +void bxt_ddi_phy_set_signal_levels(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state)
>  {
> - u32 val;
> - enum dpio_phy phy;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + int level = intel_ddi_level(encoder, crtc_state);
> + const struct intel_ddi_buf_trans *trans;
>   enum dpio_channel ch;
> + enum dpio_phy phy;
> + int n_entries;
> + u32 val;
>  
> - bxt_port_to_phy_channel(dev_priv, port, &phy, &ch);
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
> + return;
> + if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> + level = n_entries - 1;
> +
> + bxt_port_to_phy_channel(dev_priv, encoder->port, &phy, &ch);
>  
>   /*
>* While we write to the group register to program all lanes at once we
> @@ -286,12 +297,13 @@ void bxt_ddi_phy_set_signal_level(struct 
> drm_i915_private *dev_priv,
>  
>   val = intel_de_read(dev_priv, BXT_PORT_TX_DW2_LN0(phy, ch));
>   val &= ~(MARGIN_000 | UNIQ_TRANS_SCALE);
> - val |= margin << MARGIN_000_SHIFT | scale << UNIQ_TRANS_SCALE_SHIFT;
> + val |= trans->entries[level].bxt.margin << MARGIN_000_SHIFT |
> + trans->entries[level].bxt.scale << UNIQ_TRANS_SCALE_SHIFT;
>   intel_de_write(dev_priv, BXT_PORT_TX_DW2_GRP(phy, ch), val);
>  
>   val = intel_de_read(dev_priv, BXT_PORT_TX_DW3_LN0(phy, ch));
>   val 

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:51PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> All callers of intel_ddi_level() duplicate the check+WARN
> to make sure the returned level is actually present in the
> appropriate buf_trans table. Let's push that stuff into
> intel_ddi_level() so the callers don't have to worry about it.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 27 ++-
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c |  2 --
>  drivers/gpu/drm/i915/display/intel_snps_phy.c |  2 --
>  3 files changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 970a796a4f52..0fd67d2487ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -141,8 +141,6 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
> intel_encoder *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   /* If we're boosting the current, set bit 31 of trans1 */
>   if (DISPLAY_VER(dev_priv) == 9 && !IS_BROXTON(dev_priv) &&
> @@ -977,8 +975,6 @@ static void skl_ddi_set_iboost(struct intel_encoder 
> *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   iboost = trans->entries[level].hsw.i_boost;
>   }
> @@ -1037,8 +1033,6 @@ static void icl_ddi_combo_vswing_program(struct 
> intel_encoder *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP)) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> @@ -1163,8 +1157,6 @@ static void icl_mg_phy_set_signal_levels(struct 
> intel_encoder *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   /* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */
>   for (ln = 0; ln < 2; ln++) {
> @@ -1286,8 +1278,6 @@ static void tgl_dkl_phy_set_signal_levels(struct 
> intel_encoder *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   dpcnt_mask = (DKL_TX_PRESHOOT_COEFF_MASK |
> DKL_TX_DE_EMPAHSIS_COEFF_MASK |
> @@ -1357,10 +1347,23 @@ static int intel_ddi_dp_level(struct intel_dp 
> *intel_dp)
>  int intel_ddi_level(struct intel_encoder *encoder,
>   const struct intel_crtc_state *crtc_state)
>  {
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + const struct intel_ddi_buf_trans *trans;
> + int level, n_entries;
> +
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&i915->drm, !trans))
> + return 0;
> +
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> - return intel_ddi_hdmi_level(encoder, crtc_state);
> + level = intel_ddi_hdmi_level(encoder, crtc_state);
>   else
> - return intel_ddi_dp_level(enc_to_intel_dp(encoder));
> + level = intel_ddi_dp_level(enc_to_intel_dp(encoder));
> +
> + if (drm_WARN_ON_ONCE(&i915->drm, level >= n_entries))
> + level = n_entries - 1;
> +
> + return level;
>  }
>  
>  static void
> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> index 4d604e4cfa5d..96650369164d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> @@ -282,8 +282,6 @@ void bxt_ddi_phy_set_signal_levels(struct intel_encoder 
> *encoder,
>   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
>   if (drm_WARN_ON_ONCE(&dev_priv->drm, !trans))
>   return;
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
>  
>   bxt_port_to_phy_channel(dev_priv, encoder->port, &phy, &ch);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_snp

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Nuke intel_ddi_hdmi_num_entries()

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Since intel_ddi_level() now looks that buf_trans table there's
> no point in having intel_ddi_hdmi_num_entries() around. Just
> roll the necessary bits of locic into
> intel_ddi_hdmi_level()/intel_ddi_level().
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 17 +---
>  .../drm/i915/display/intel_ddi_buf_trans.c| 20 ---
>  .../drm/i915/display/intel_ddi_buf_trans.h|  4 
>  3 files changed, 5 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 0fd67d2487ad..05124bf4abac 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -74,20 +74,13 @@ static const u8 index_to_dp_signal_levels[] = {
>  };
>  
>  static int intel_ddi_hdmi_level(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state)
> + const struct intel_ddi_buf_trans *trans)
>  {
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - int n_entries, level, default_entry;
> + int level;
>  
> - n_entries = intel_ddi_hdmi_num_entries(encoder, crtc_state, 
> &default_entry);
> - if (n_entries == 0)
> - return 0;
>   level = intel_bios_hdmi_level_shift(encoder);
>   if (level < 0)
> - level = default_entry;
> -
> - if (drm_WARN_ON_ONCE(&dev_priv->drm, level >= n_entries))
> - level = n_entries - 1;
> + level = trans->hdmi_default_entry;
>  
>   return level;
>  }
> @@ -132,7 +125,7 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
> intel_encoder *encoder,
>const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - int level = intel_ddi_hdmi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state);
>   u32 iboost_bit = 0;
>   int n_entries;
>   enum port port = encoder->port;
> @@ -1356,7 +1349,7 @@ int intel_ddi_level(struct intel_encoder *encoder,
>   return 0;
>  
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> - level = intel_ddi_hdmi_level(encoder, crtc_state);
> + level = intel_ddi_hdmi_level(encoder, trans);
>   else
>   level = intel_ddi_dp_level(enc_to_intel_dp(encoder));
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 449daba7afb3..a2d39131ea53 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1617,26 +1617,6 @@ dg2_get_snps_buf_trans(struct intel_encoder *encoder,
>   return intel_get_buf_trans(&dg2_snps_trans, n_entries);
>  }
>  
> -int intel_ddi_hdmi_num_entries(struct intel_encoder *encoder,
> -const struct intel_crtc_state *crtc_state,
> -int *default_entry)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - const struct intel_ddi_buf_trans *trans;
> - int n_entries;
> -
> - trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> -
> - if (drm_WARN_ON(&dev_priv->drm, !trans)) {
> - *default_entry = 0;
> - return 0;
> - }
> -
> - *default_entry = trans->hdmi_default_entry;
> -
> - return n_entries;
> -}
> -
>  void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.h 
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.h
> index 94d338287f61..6cdb8e9073c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.h
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.h
> @@ -68,10 +68,6 @@ struct intel_ddi_buf_trans {
>  
>  bool is_hobl_buf_trans(const struct intel_ddi_buf_trans *table);
>  
> -int intel_ddi_hdmi_num_entries(struct intel_encoder *encoder,
> -const struct intel_crtc_state *crtc_state,
> -int *default_entry);
> -
>  void intel_ddi_buf_trans_init(struct intel_encoder *encoder);
>  
>  #endif
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Pass the lane to intel_ddi_level()

[Imre Deak]

On Mon, Sep 27, 2021 at 09:24:53PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> In order to have per-lane drive settings we need intel_ddi_level()
> to accept the lane as a parameter. That is, the eventual goal is to
> call intel_ddi_level() once for each lane. For now we just pass in
> a hardcoded 0 and use the same settings for every lane. Ie. no
> change in behaviour yet.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 19 ++-
>  drivers/gpu/drm/i915/display/intel_ddi.h  |  3 ++-
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_snps_phy.c |  2 +-
>  4 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 05124bf4abac..e6256d4c5af8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -125,7 +125,7 @@ static void hsw_prepare_hdmi_ddi_buffers(struct 
> intel_encoder *encoder,
>const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - int level = intel_ddi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state, 0);
>   u32 iboost_bit = 0;
>   int n_entries;
>   enum port port = encoder->port;
> @@ -1017,7 +1017,7 @@ static void icl_ddi_combo_vswing_program(struct 
> intel_encoder *encoder,
>const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - int level = intel_ddi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state, 0);
>   const struct intel_ddi_buf_trans *trans;
>   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
>   int n_entries, ln;
> @@ -1139,7 +1139,7 @@ static void icl_mg_phy_set_signal_levels(struct 
> intel_encoder *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder->port);
> - int level = intel_ddi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state, 0);
>   const struct intel_ddi_buf_trans *trans;
>   int n_entries, ln;
>   u32 val;
> @@ -1260,7 +1260,7 @@ static void tgl_dkl_phy_set_signal_levels(struct 
> intel_encoder *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder->port);
> - int level = intel_ddi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state, 0);
>   const struct intel_ddi_buf_trans *trans;
>   u32 val, dpcnt_mask, dpcnt_val;
>   int n_entries, ln;
> @@ -1328,9 +1328,9 @@ static int translate_signal_level(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> -static int intel_ddi_dp_level(struct intel_dp *intel_dp)
> +static int intel_ddi_dp_level(struct intel_dp *intel_dp, int lane)
>  {
> - u8 train_set = intel_dp->train_set[0];
> + u8 train_set = intel_dp->train_set[lane];
>   u8 signal_levels = train_set & (DP_TRAIN_VOLTAGE_SWING_MASK |
>   DP_TRAIN_PRE_EMPHASIS_MASK);
>  
> @@ -1338,7 +1338,8 @@ static int intel_ddi_dp_level(struct intel_dp *intel_dp)
>  }
>  
>  int intel_ddi_level(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state)
> + const struct intel_crtc_state *crtc_state,
> + int lane)
>  {
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>   const struct intel_ddi_buf_trans *trans;
> @@ -1351,7 +1352,7 @@ int intel_ddi_level(struct intel_encoder *encoder,
>   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>   level = intel_ddi_hdmi_level(encoder, trans);
>   else
> - level = intel_ddi_dp_level(enc_to_intel_dp(encoder));
> + level = intel_ddi_dp_level(enc_to_intel_dp(encoder), lane);
>  
>   if (drm_WARN_ON_ONCE(&i915->drm, level >= n_entries))
>   level = n_entries - 1;
> @@ -1365,7 +1366,7 @@ hsw_set_signal_levels(struct intel_encoder *encoder,
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> - int level = intel_ddi_level(encoder, crtc_state);
> + int level = intel_ddi_level(encoder, crtc_state, 0);
>   enum port port = encoder->port;
>   u32 signal_levels;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h 
> b/drivers/gpu/drm/i915/display/intel_ddi.h
> index d6947c06a455..d6971717ef9c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.h
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.h
> @@ -64,6 +64,7 @@ int intel

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Enable TPS3/4 on all platforms that support them (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Enable TPS3/4 on all platforms that support them (rev2)
URL   : https://patchwork.freedesktop.org/series/88186/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21191_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-skl8/igt@kms_async_fl...@crc.html

  * igt@kms_flip_tiling@flip-y-tiled@dp-1-pipe-a:
- shard-kbl:  [PASS][2] -> [DMESG-WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@kms_flip_tiling@flip-y-ti...@dp-1-pipe-a.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-kbl4/igt@kms_flip_tiling@flip-y-ti...@dp-1-pipe-a.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-apl3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#280]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-tglb7/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: NOTRUN -> [TIMEOUT][6] ([i915#2369] / [i915#3063] / 
[i915#3648])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-tglb1/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-kbl1/igt@gem_exec_f...@basic-deadline.html
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-glk8/igt@gem_exec_f...@basic-deadline.html
- shard-apl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-apl8/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +139 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-skl4/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-iclb4/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-tglb1/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#112283])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-tglb1/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_pread@exhaustion:
- shard-kbl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-kbl6/igt@gem_pr...@exhaustion.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  NOTRUN -> [DMESG-WARN][21] ([i915#180])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21191/shard-apl6/igt@gem_workarou...@suspend-resume.html

  * igt@gen3_render_til

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update memory bandwidth formulae (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Update memory bandwidth formulae (rev3)
URL   : https://patchwork.freedesktop.org/series/95138/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660 -> Patchwork_21195


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### CI changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * boot:
- {fi-jsl-1}: [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/fi-jsl-1/boot.html
- {fi-ehl-2}: [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-ehl-2/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/fi-ehl-2/boot.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-icl-y:   [PASS][5] -> [FAIL][6] ([i915#3521])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-icl-y/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/fi-icl-y/boot.html
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([i915#3521])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/fi-icl-u2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/fi-icl-u2/boot.html

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

  [i915#3521]: https://gitlab.freedesktop.org/drm/intel/issues/3521


Participating hosts (33 -> 29)
--

  Missing(4): fi-bsw-cyan bat-jsl-1 bat-dg1-6 bat-adlp-4 


Build changes
-

  * Linux: CI_DRM_10660 -> Patchwork_21195

  CI-20190529: 20190529
  CI_DRM_10660: 05888a7b7b4aec560d6692e5e9173adc7e76c0df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6227: 6ac2da7fd6b13f04f9aa0ec10f86b831d2756946 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21195: 326a2a72e268238642d6885d421b9139166b32ff @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

326a2a72e268 drm/i915: Update memory bandwidth formulae

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 8/9] drm/i915: Prepare link training for per-lane drive settings

[Imre Deak]

On Wed, Sep 29, 2021 at 07:54:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Adjust the link training code to accommodate per-lane drive settings,
> if supported by the platform. Actually enabling this will involve
> some changes to each platform's .set_signal_level() implementation,
> so for the moment all supported platforms will keep using the current
> codepath that just uses the same drive settings for all the lanes.
> 
> v2: Fix min() vs. max() fumble
> v3: Compact the debug print to a single line
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../drm/i915/display/intel_dp_link_training.c | 78 ++-
>  1 file changed, 60 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index d52929855cd0..f26c44a6b568 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -301,21 +301,33 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp 
> *intel_dp,
>   return preemph_max;
>  }
>  
> -void
> -intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> -   const struct intel_crtc_state *crtc_state,
> -   enum drm_dp_phy dp_phy,
> -   const u8 link_status[DP_LINK_STATUS_SIZE])
> +static bool has_per_lane_signal_levels(struct intel_dp *intel_dp,
> +enum drm_dp_phy dp_phy)
> +{
> + return false;
> +}
> +
> +static u8 intel_dp_get_lane_adjust_train(struct intel_dp *intel_dp,
> +  const struct intel_crtc_state 
> *crtc_state,
> +  enum drm_dp_phy dp_phy,
> +  const u8 
> link_status[DP_LINK_STATUS_SIZE],
> +  int lane)
>  {
>   u8 v = 0;
>   u8 p = 0;
> - int lane;
>   u8 voltage_max;
>   u8 preemph_max;
>  
> - for (lane = 0; lane < crtc_state->lane_count; lane++) {
> - v = max(v, drm_dp_get_adjust_request_voltage(link_status, 
> lane));
> - p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status, 
> lane));
> + if (has_per_lane_signal_levels(intel_dp, dp_phy)) {
> + lane = min(lane, crtc_state->lane_count - 1);
> +
> + v = drm_dp_get_adjust_request_voltage(link_status, lane);
> + p = drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
> + } else {
> + for (lane = 0; lane < crtc_state->lane_count; lane++) {
> + v = max(v, 
> drm_dp_get_adjust_request_voltage(link_status, lane));
> + p = max(p, 
> drm_dp_get_adjust_request_pre_emphasis(link_status, lane));
> + }
>   }
>  
>   preemph_max = intel_dp_phy_preemph_max(intel_dp, dp_phy);
> @@ -328,8 +340,21 @@ intel_dp_get_adjust_train(struct intel_dp *intel_dp,
>   if (v >= voltage_max)
>   v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
>  
> + return v | p;
> +}
> +
> +void
> +intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> +   const struct intel_crtc_state *crtc_state,
> +   enum drm_dp_phy dp_phy,
> +   const u8 link_status[DP_LINK_STATUS_SIZE])
> +{
> + int lane;
> +
>   for (lane = 0; lane < 4; lane++)
> - intel_dp->train_set[lane] = v | p;
> + intel_dp->train_set[lane] =
> + intel_dp_get_lane_adjust_train(intel_dp, crtc_state,
> +dp_phy, link_status, 
> lane);
>  }
>  
>  static int intel_dp_training_pattern_set_reg(struct intel_dp *intel_dp,
> @@ -394,22 +419,39 @@ intel_dp_program_link_training_pattern(struct intel_dp 
> *intel_dp,
>   intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
>  }
>  
> +#define TRAIN_SET_FMT "%d%s/%d%s/%d%s/%d%s"
> +#define _TRAIN_SET_VSWING_ARGS(train_set) \
> + ((train_set) & DP_TRAIN_VOLTAGE_SWING_MASK) >> 
> DP_TRAIN_VOLTAGE_SWING_SHIFT, \
> + (train_set) & DP_TRAIN_MAX_SWING_REACHED ? "(max)" : ""
> +#define TRAIN_SET_VSWING_ARGS(train_set) \
> + _TRAIN_SET_VSWING_ARGS((train_set)[0]), \
> + _TRAIN_SET_VSWING_ARGS((train_set)[1]), \
> + _TRAIN_SET_VSWING_ARGS((train_set)[2]), \
> + _TRAIN_SET_VSWING_ARGS((train_set)[3])
> +#define _TRAIN_SET_PREEMPH_ARGS(train_set) \
> + ((train_set) & DP_TRAIN_PRE_EMPHASIS_MASK) >> 
> DP_TRAIN_PRE_EMPHASIS_SHIFT, \
> + (train_set) & DP_TRAIN_MAX_PRE_EMPHASIS_REACHED ? "(max)" : ""
> +#define TRAIN_SET_PREEMPH_ARGS(train_set) \
> + _TRAIN_SET_PREEMPH_ARGS((train_set)[0]), \
> + _TRAIN_SET_PREEMPH_ARGS((train_set)[1]), \
> + _TRAIN_SET_PREEMPH_ARGS((train_set)[2]), \
> + _TRAIN_SET_PREEMPH_ARGS((train_set)[3])
> +
>  void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
>   const struct int

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Allow per-lane drive settings with LTTPRs

[Imre Deak]

On Wed, Sep 29, 2021 at 07:55:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> LTTPRs should support per-lane drive settings I think, and even if
> they don't they should implement their own fallback logic to determine
> suitable common drive settings to use for all the lanes.
> 
> v2: Actually check the correct thing
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index f26c44a6b568..eeea6c73e218 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -304,7 +304,7 @@ static u8 intel_dp_phy_preemph_max(struct intel_dp 
> *intel_dp,
>  static bool has_per_lane_signal_levels(struct intel_dp *intel_dp,
>  enum drm_dp_phy dp_phy)
>  {
> - return false;
> + return !intel_dp_phy_is_downstream_of_source(intel_dp, dp_phy);
>  }
>  
>  static u8 intel_dp_get_lane_adjust_train(struct intel_dp *intel_dp,
> -- 
> 2.32.0
> 

Re: [Intel-gfx] [PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests

[John Harrison]

On 8/20/2021 15:44, Matthew Brost wrote:

If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arrises because with multi-lrc

arrises -> arises


breadcrumbs there is a handshake between the parent and children to make
forwad progress. If all the requests are not present this handshake

forwad -> forward


doesn't work. To work around this, if multi-lrc request has an error we
skip the handshake but still emit the breadcrumbs seqno.

Signed-off-by: Matthew Brost 
---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ++-
  1 file changed, 58 insertions(+), 3 deletions(-)

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 2ef38557b0f0..61e737fd1eee 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3546,8 +3546,8 @@ static int 
emit_bb_start_child_no_preempt_mid_batch(struct i915_request *rq,
  }
  
  static u32 *

-emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
-u32 *cs)
+__emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+  u32 *cs)
  {
struct intel_context *ce = rq->context;
u8 i;
@@ -3575,6 +3575,41 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct 
i915_request *rq,
  get_children_go_addr(ce),
  0);
  
+	return cs;

+}
+
+/*
+ * If this true, a submission of multi-lrc requests had an error and the
+ * requests need to be skipped. The front end (execuf IOCTL) should've called
+ * i915_request_skip which squashes the BB but we still need to emit the fini
+ * breadrcrumbs seqno write. At this point we don't know how many of the
+ * requests in the multi-lrc submission were generated so we can't do the
+ * handshake between the parent and children (e.g. if 4 requests should be
+ * generated but 2nd hit an error only 1 would be seen by the GuC backend).
+ * Simply skip the handshake, but still emit the breadcrumbd seqno, if an error
+ * has occurred on any of the requests in submission / relationship.
+ */
+static inline bool skip_handshake(struct i915_request *rq)
+{
+   return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, &rq->fence.flags);
+}
+
+static u32 *
+emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
+u32 *cs)
+{
+   struct intel_context *ce = rq->context;
+
+   GEM_BUG_ON(!intel_context_is_parent(ce));
+
+   if (unlikely(skip_handshake(rq))) {
+   memset(cs, 0, sizeof(u32) *
+  (ce->engine->emit_fini_breadcrumb_dw - 6));
+   cs += ce->engine->emit_fini_breadcrumb_dw - 6;
Why -6? There are 12 words about to be written. Indeed the value of 
emit_..._dw is '12 + 4*num_children'. This should only be skipping over 
the 4*children, right? As it stands, it will skip all but the last six 
words, then write an extra twelve words and thus overflow the 
reservation by six. Unless I am totally confused?


I assume there is some reason why the amount of data written must 
exactly match the space reserved? It's a while since I've looked at the 
ring buffer code!


Seems like it would be clearer to not split the semaphore writes out but 
have them right next to the skip code that is meant to replicate them 
but with no-ops.



+   } else {
+   cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
+   }
+
/* Emit fini breadcrumb */
cs = gen8_emit_ggtt_write(cs,
  rq->fence.seqno,
@@ -3591,7 +3626,8 @@ emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct 
i915_request *rq,
  }
  
  static u32 *

-emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq, u32 
*cs)
+__emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+ u32 *cs)
  {
struct intel_context *ce = rq->context;
  
@@ -3617,6 +3653,25 @@ emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq, u32 *cs

*cs++ = get_children_go_addr(ce->parent);
*cs++ = 0;
  
+	return cs;

+}
+
+static u32 *
+emit_fini_breadcrumb_child_no_preempt_mid_batch(struct i915_request *rq,
+   u32 *cs)
+{
+   struct intel_context *ce = rq->context;
+
+   GEM_BUG_ON(!intel_context_is_child(ce));
+
+   if (unlikely(skip_handshake(rq))) {
+   memset(cs, 0, sizeof(u32) *
+  (ce->engine->emit_fini_breadcrumb_dw - 6));
+   cs += ce->engine->emit_fini_breadcrumb_dw - 6;
+   } else {
+   cs = __emit_fini_breadcrumb_child_no_preempt_m

Re: [Intel-gfx] [PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests

[Matthew Brost]

On Wed, Sep 29, 2021 at 01:44:10PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > If an error occurs in the front end when multi-lrc requests are getting
> > generated we need to skip these in the backend but we still need to
> > emit the breadcrumbs seqno. An issues arrises because with multi-lrc
> arrises -> arises
> 

Yep.

> > breadcrumbs there is a handshake between the parent and children to make
> > forwad progress. If all the requests are not present this handshake
> forwad -> forward
> 

Yep.

> > doesn't work. To work around this, if multi-lrc request has an error we
> > skip the handshake but still emit the breadcrumbs seqno.
> > 
> > Signed-off-by: Matthew Brost 
> > ---
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 61 ++-
> >   1 file changed, 58 insertions(+), 3 deletions(-)
> > 
> > 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 2ef38557b0f0..61e737fd1eee 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -3546,8 +3546,8 @@ static int 
> > emit_bb_start_child_no_preempt_mid_batch(struct i915_request *rq,
> >   }
> >   static u32 *
> > -emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > -u32 *cs)
> > +__emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > +  u32 *cs)
> >   {
> > struct intel_context *ce = rq->context;
> > u8 i;
> > @@ -3575,6 +3575,41 @@ 
> > emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> >   get_children_go_addr(ce),
> >   0);
> > +   return cs;
> > +}
> > +
> > +/*
> > + * If this true, a submission of multi-lrc requests had an error and the
> > + * requests need to be skipped. The front end (execuf IOCTL) should've 
> > called
> > + * i915_request_skip which squashes the BB but we still need to emit the 
> > fini
> > + * breadrcrumbs seqno write. At this point we don't know how many of the
> > + * requests in the multi-lrc submission were generated so we can't do the
> > + * handshake between the parent and children (e.g. if 4 requests should be
> > + * generated but 2nd hit an error only 1 would be seen by the GuC backend).
> > + * Simply skip the handshake, but still emit the breadcrumbd seqno, if an 
> > error
> > + * has occurred on any of the requests in submission / relationship.
> > + */
> > +static inline bool skip_handshake(struct i915_request *rq)
> > +{
> > +   return test_bit(I915_FENCE_FLAG_SKIP_PARALLEL, &rq->fence.flags);
> > +}
> > +
> > +static u32 *
> > +emit_fini_breadcrumb_parent_no_preempt_mid_batch(struct i915_request *rq,
> > +u32 *cs)
> > +{
> > +   struct intel_context *ce = rq->context;
> > +
> > +   GEM_BUG_ON(!intel_context_is_parent(ce));
> > +
> > +   if (unlikely(skip_handshake(rq))) {
> > +   memset(cs, 0, sizeof(u32) *
> > +  (ce->engine->emit_fini_breadcrumb_dw - 6));
> > +   cs += ce->engine->emit_fini_breadcrumb_dw - 6;
> Why -6? There are 12 words about to be written. Indeed the value of
> emit_..._dw is '12 + 4*num_children'. This should only be skipping over the
> 4*children, right? As it stands, it will skip all but the last six words,
> then write an extra twelve words and thus overflow the reservation by six.
> Unless I am totally confused?
> 

Let me decode the length:

'Wait on children' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 4 
* num_children
'Turn on preemption' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 2
'Tell children go' (in __emit_fini_breadcrumb_parent_no_preempt_mid_batch) = 4
'Emit fini breadcrumb' (in emit_fini_breadcrumb_child_no_preempt_mid_batch) = 4
'User interrupt' (in emit_fini_breadcrumb_child_no_preempt_mid_batch) = 2

So for a total (emit_fini_breadcrumb_dw) we have '12 + 4 * num_children'

We want skip everything in __emit_fini_breadcrumb_parent_no_preempt_mid_batch, 
so that is
'6 + 4 * num_children' or 'emit_fini_breadcrumb_dw - 6'

Make sense?

> I assume there is some reason why the amount of data written must exactly
> match the space reserved? It's a while since I've looked at the ring buffer
> code!
> 

I think it because the ring space is reserved at request creation time
but the fini breadcrumbs are not written until submission time.

> Seems like it would be clearer to not split the semaphore writes out but
> have them right next to the skip code that is meant to replicate them but
> with no-ops.
>

I guess that works too, I personally like the way it is but if you
insist I can change it.

> > +   } else {
> > +   cs = __emit_fini_breadcrumb_parent_no_preempt_mid_batch(rq, cs);
> > +   }
> > +
> > /* Emit fini breadcrumb */
> > cs = 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: DP per-lane drive settings prep work (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: DP per-lane drive settings prep work (rev4)
URL   : https://patchwork.freedesktop.org/series/95122/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21192_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-skl9/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-apl2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][3] ([i915#280]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb7/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-skl:  NOTRUN -> [TIMEOUT][4] ([i915#2369] / [i915#3063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-skl7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-glk3/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-iclb4/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb2/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][14] ([fdo#112283])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb2/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#456])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb3/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb7/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118] / 
[i915#95]) +4 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk4/igt@gem_exec_whis...@basic-queues-forked-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-glk8/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  NOTRUN -> [DMESG-WARN][19] ([i915#180])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-apl8/igt@gem_soft...@noreloc-s3.html

  * igt@gen3_render_tiledy_blits:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289]) +2 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21192/shard-tglb8/igt@gen3_render_tiledy_blits.html

  * igt@gen9_exec_parse@bb-start-param:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#2856]) 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined

[Andrzej Hajda]

W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
> Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
> return the right thing when the config is not defined rather than a
> build error, with the limitation that it can't be used on preprocessor
> context.
>
> The trick here is that macro names can't start with a number or dash, so
> we stringify the argument and check that the first char is a number != 0
> (or starting with a dash to cover negative numbers). Except for -O0
> builds the strings are all eliminated.
>
> Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
> drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
> following output of the preprocessor:
>
> old:
>   if (((2) != 0) &&
> new:
>   if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
>
> New one looks worse, but is also eliminated from the object:
>
> $ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
> textdata bss dec hex filename
>520211070 232   53323d04b 
> drivers/gpu/drm/i915/gem/i915_gem_context.o.new
>520211070 232   53323d04b 
> drivers/gpu/drm/i915/gem/i915_gem_context.o.old
>
> Signed-off-by: Lucas De Marchi 
> ---
>   drivers/gpu/drm/i915/i915_utils.h | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h 
> b/drivers/gpu/drm/i915/i915_utils.h
> index 02bbfa4d68d3..436ce612c46a 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -28,6 +28,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   
> @@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list 
> *t)
>*
>* Returns 0 if @config is 0, 1 if set to any value.
>*/
> -#define IS_CONFIG_NONZERO(config) ((config) != 0)
> +#define IS_CONFIG_NONZERO(config) (  
> \
> + (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
> \
> + __stringify_1(config)[0] == '-' 
> \
> +)


Quite clever trick, but I see two issues:

- gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as 
non-constant expressions, so they cannot be used everywhere, for example 
in global variable initializations,

- it does not work with hex (0x1) or octal values (01)

It is probably OK for private macro, but it can hurt in kconfig.h, 
especially the 2nd issue


Regards

Andrzej

>   
>   #endif /* !__I915_UTILS_H */

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Imre Deak]

On Wed, Sep 29, 2021 at 04:58:46PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
> URL   : https://patchwork.freedesktop.org/series/94878/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_21189_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_21189_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_21189_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@fbdev@unaligned-read:
> - shard-glk:  [PASS][1] -> [FAIL][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@fb...@unaligned-read.html
> 
>   * igt@gem_eio@reset-stress:
> - shard-skl:  [PASS][3] -> [FAIL][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/igt@gem_...@reset-stress.html
> 
>   * igt@kms_async_flips@crc:
> - shard-skl:  NOTRUN -> [FAIL][5]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl7/igt@kms_async_fl...@crc.html

The above platforms don't have any TypeC ports, so the failures are
unrelated.

Thanks for the review, I pushed the patchset to drm-intel-next.

> Known issues
> 
> 
>   Here are the changes found in Patchwork_21189_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_create@create-massive:
> - shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/igt@gem_cre...@create-massive.html
> 
>   * igt@gem_ctx_sseu@mmap-args:
> - shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/igt@gem_ctx_s...@mmap-args.html
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / 
> [i915#2481] / [i915#3070])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/igt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_fair@basic-deadline:
> - shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2846])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/igt@gem_exec_f...@basic-deadline.html
> 
>   * igt@gem_exec_fair@basic-flow@rcs0:
> - shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +106 similar 
> issues
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/igt@gem_exec_fair@basic-f...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
> issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none-vip@rcs0:
> - shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html
> 
>   * igt@gem_exec_fair@basic-pace@rcs0:
> - shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842])
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html
> 
>   * igt@gem_exec_gttfill@basic:
> - shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
> [i915#95]) +1 similar issue
>[20]: 
> https://intel-gfx-c

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@reset-stress:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/igt@gem_...@reset-stress.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#4218])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@fb...@unaligned-read.html

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][6] ([i915#280])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +106 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_gttfill@basic:
- shard-glk:  [PASS][19] -> [DMESG-WARN][20] ([i915#118] / 
[i915#95]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk1/igt@gem_exec_gttf...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109283])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#112283])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@secure-non-master.html

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@reset-stress:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/igt@gem_...@reset-stress.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#4218])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@fb...@unaligned-read.html

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][6] ([i915#280])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271]) +106 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_gttfill@basic:
- shard-glk:  [PASS][19] -> [DMESG-WARN][20] ([i915#118] / 
[i915#95]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk1/igt@gem_exec_gttf...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109283])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#112283])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@secure-non-master.html

[Intel-gfx] ✗ Fi.CI.IGT: failure for Rename IS_ACTIVE() and move to kconfig.h

[Patchwork]

== Series Details ==

Series: Rename IS_ACTIVE() and move to kconfig.h
URL   : https://patchwork.freedesktop.org/series/95229/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21193_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible@d-edp1:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@kms_flip@blocking-absolute-wf_vblank-interrupti...@d-edp1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-tglb7/igt@kms_flip@blocking-absolute-wf_vblank-interrupti...@d-edp1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#4218])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-glk3/igt@fb...@unaligned-read.html

  * igt@gem_ctx_persistence@hostile:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2410])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_ctx_persiste...@hostile.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-tglb8/igt@gem_ctx_persiste...@hostile.html

  * igt@gem_ctx_sseu@engines:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-tglb5/igt@gem_ctx_s...@engines.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-apl:  NOTRUN -> [SKIP][8] ([fdo#109271]) +205 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-apl2/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-apl7/igt@gem_...@in-flight-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-apl6/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-skl:  NOTRUN -> [TIMEOUT][11] ([i915#2369] / [i915#3063])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-skl6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][12] ([i915#2846])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-kbl4/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271]) +133 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-skl10/igt@gem_exec_fair@basic-f...@rcs0.html
- shard-tglb: NOTRUN -> [FAIL][14] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2842]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-iclb4/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2842])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21193/shard-tglb8/igt@gem_

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Patchwork]

== Series Details ==

Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
URL   : https://patchwork.freedesktop.org/series/94878/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_async_flips@crc:
- {shard-rkl}:NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-rkl-1/igt@kms_async_fl...@crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-read:
- shard-glk:  [PASS][2] -> [FAIL][3] ([i915#4218])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@fb...@unaligned-read.html

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#280])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@reset-stress:
- shard-skl:  [PASS][6] -> [FAIL][7] ([i915#4225])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/igt@gem_...@reset-stress.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +106 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_gttfill@basic:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
[i915#95]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk1/igt@gem_exec_gttf...@basic.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109283])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][23] ([fdo#112283])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb3/igt@gem_exec_par...@secure-non-

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)

[Vudum, Lakshminarayana]

I have addressed the regressions and I filed below issues
https://gitlab.freedesktop.org/drm/intel/-/issues/4225
igt@gem_eio@reset-stress - fail - Failed assertion: count > 2

https://gitlab.freedesktop.org/drm/intel/-/issues/4224
igt@kms_async_flips@crc - fail - Failed assertion: !mismatch || 
igt_skip_crc_compare

Lakshmi,

-Original Message-
From: Deak, Imre  
Sent: Wednesday, September 29, 2021 2:17 PM
To: intel-gfx@lists.freedesktop.org; Souza, Jose ; Vudum, 
Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/tc: Fix TypeC connect/disconnect 
sequences (rev8)

On Wed, Sep 29, 2021 at 04:58:46PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/tc: Fix TypeC connect/disconnect sequences (rev8)
> URL   : https://patchwork.freedesktop.org/series/94878/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21189_full 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_21189_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_21189_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_21189_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@fbdev@unaligned-read:
> - shard-glk:  [PASS][1] -> [FAIL][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk3/igt@fb...@unaligned-read.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk4/ig
> t@fb...@unaligned-read.html
> 
>   * igt@gem_eio@reset-stress:
> - shard-skl:  [PASS][3] -> [FAIL][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl1/igt@gem_...@reset-stress.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl2/ig
> t@gem_...@reset-stress.html
> 
>   * igt@kms_async_flips@crc:
> - shard-skl:  NOTRUN -> [FAIL][5]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl7/ig
> t@kms_async_fl...@crc.html

The above platforms don't have any TypeC ports, so the failures are unrelated.

Thanks for the review, I pushed the patchset to drm-intel-next.

> Known issues
> 
> 
>   Here are the changes found in Patchwork_21189_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_create@create-massive:
> - shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-apl6/ig
> t@gem_cre...@create-massive.html
> 
>   * igt@gem_ctx_sseu@mmap-args:
> - shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb2/i
> gt@gem_ctx_s...@mmap-args.html
> 
>   * igt@gem_eio@unwedge-stress:
> - shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / 
> [i915#2481] / [i915#3070])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/igt@gem_...@unwedge-stress.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-iclb3/i
> gt@gem_...@unwedge-stress.html
> 
>   * igt@gem_exec_fair@basic-deadline:
> - shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2846])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-glk8/igt@gem_exec_f...@basic-deadline.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-glk1/ig
> t@gem_exec_f...@basic-deadline.html
> 
>   * igt@gem_exec_fair@basic-flow@rcs0:
> - shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +106 similar 
> issues
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-skl1/ig
> t@gem_exec_fair@basic-f...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar 
> issue
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-tglb6/i
> gt@gem_exec_fair@basic-none-sh...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none-vip@rcs0:
> - shard-kbl:  [PASS][15] -> [FAIL][16] ([i915#2842])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21189/shard-kbl2/ig
> t@gem_exec_fair@basic-none-...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs1:
> - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
>[17]: 
> https://in

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reject bogus modes with fixed mode panels (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject bogus modes with fixed mode panels (rev4)
URL   : https://patchwork.freedesktop.org/series/95003/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21194_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@fbdev@unaligned-read:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@fb...@unaligned-read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-iclb3/igt@fb...@unaligned-read.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-skl:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@unaligned-read:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#4218])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb3/igt@fb...@unaligned-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb1/igt@fb...@unaligned-read.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#280])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb6/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][8] ([i915#2846])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-apl1/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl:  NOTRUN -> [SKIP][9] ([fdo#109271]) +138 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-skl3/igt@gem_exec_fair@basic-f...@rcs0.html
- shard-tglb: NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2842] / [i915#3468])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/igt@gem_exec_fair@basic-p...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-iclb6/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109283])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#112283])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb3/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_pread@exhaustion:
- shard-kbl:  NOTRUN -> [WARN][21] ([i915#2658])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-kbl6/igt@gem_pr...@exhaustion.html

  * igt@gen7_exec_parse@batch-without-end:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109289])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21194/shard-tglb6/igt@gen7_exec_pa...@bat

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined

[Lucas De Marchi]

On Wed, Sep 29, 2021 at 11:08:18PM +0200, Andrzej Hajda wrote:


W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:

Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.

The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.

Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:

old:
  if (((2) != 0) &&
new:
  if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&

New one looks worse, but is also eliminated from the object:

$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
textdata bss dec hex filename
   520211070 232   53323d04b 
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
   520211070 232   53323d04b 
drivers/gpu/drm/i915/gem/i915_gem_context.o.old

Signed-off-by: Lucas De Marchi 
---
  drivers/gpu/drm/i915/i915_utils.h | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
   *
   * Returns 0 if @config is 0, 1 if set to any value.
   */
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+   (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||   
  \
+   __stringify_1(config)[0] == '-' 
\
+)



Quite clever trick, but I see two issues:

- gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as
non-constant expressions, so they cannot be used everywhere, for example
in global variable initializations,


ugh, that would kill the idea - having the strings and additional
runtime checks would not be good. Maybe if we check with
__builtin_constant_p() and do the simpler expansion if it's not
constant?



- it does not work with hex (0x1) or octal values (01)


indeed, but I guess that would be fixable by checking (s[0] == '0' && s[1] == 
'\0')?
However, it seems kconfig doesn't support setting int options to hex or
octal.

If I try an hex value in menuconfig it says "You have made an invalid entry."
If I try editing .config or setting via scripts/config --set-val, it
just gets reset when trying to generate include/generated/autoconf.h

Lucas De Marchi



It is probably OK for private macro, but it can hurt in kconfig.h,
especially the 2nd issue


Regards

Andrzej



  #endif /* !__I915_UTILS_H */

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

[Jason Gunthorpe]

On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> >
> >> Yes. I was thinking of the possibility of putting off some work later so
> >> that we don't need to make a lot of changes. GVT-g needs to take a
> >> snapshot of GPU registers as the initial virtual states for other vGPUs,
> >> which requires the initialization happens at a certain early time of
> >> initialization of i915. I was thinking maybe we can take other patches
> >> from Christoph like "de-virtualize*" except this one because currently
> >> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built
> >> as kernel module.
> > How about just capture these registers in the main module/device and
> > not try so hard to isolate it to the gvt stuff?
> 
> Hi Jason:
> 
> Thanks for the idea. I am not sure i915 guys would take this idea since 
> that it's only for GVT-g, i915 doesn't use this at all. We need to take 
> a snapshot of both PCI configuration space and MMIO registers before 
> i915 driver starts to touch the HW.

Given the code is already linked into i915 I don't see there is much
to object to here. It can remain conditional on the kernel parameter
as today.

As a general philosophy this would all be much less strange if the
mdev .ko is truely optional. It should be cleanly seperate from its
base device and never request_module'd..

In this case auxiliary device might be a good option, have i915 create
one and the mdev module be loaded against it.

In the mean time is there some shortcut to get this series to move
ahead? Is patch 4 essential to the rest of the series?

A really awful hack would be to push the pci_driver_register into a
WQ so that the request_module is guarenteed to not be part of the
module_init callchain.

> Also I was thinking if moving gvt into kvmgt.ko is the right direction. 
> It seems the module loading system in kernel is not designed for "module 
> A loading module B, which needs symbols from module A, in the 
> initialization path of module A".

Of course not, that is a circular module dependency, it should not be
that way. The SW layers need to be clean and orderly - meaning the
i915 module needs to have the minimal amount of code to support the
mdev module.

Jason

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Update memory bandwidth formulae (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Update memory bandwidth formulae (rev3)
URL   : https://patchwork.freedesktop.org/series/95138/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10660_full -> Patchwork_21195_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-iclb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], 
[FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], 
[FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], 
[FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], 
[FAIL][48], [FAIL][49], [FAIL][50]) ([i915#3521])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb8/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb7/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb1/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb5/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb5/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb5/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb6/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb6/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10660/shard-iclb6/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb7/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb7/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb6/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb5/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb5/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb5/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb4/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb4/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb3/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb3/boot.html
   [43]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb3/boot.html
   [44]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21195/shard-iclb2/boot.html
   [45]: 

[Intel-gfx] [PATCH v2 1/9] drm/i915/display/psr: Handle plane and pipe restrictions at every page flip

[José Roberto de Souza]

PSR2 selective is not supported over rotated and scaled planes.
We had the rotation check in intel_psr2_sel_fetch_config_valid()
but that code path is only execute when a modeset is needed and
those plane parameters can change without a modeset.

Pipe selective fetch restrictions are also needed, it could be added
in intel_psr_compute_config() but pippe scaling is computed after
it is executed, so leaving as is for now.
There is no much loss in this approach as it would cause selective
fetch to not enabled as for alderlake-P and newer will cause it to
switch to PSR1 that will have the same power-savings as do full pipe
fetch.

Also need to check those restricions in the second
for_each_oldnew_intel_plane_in_state() loop because the state could
only have a plane that is not affected by those restricitons but
the damaged area intersect with planes that has those restrictions,
so a full pipe fetch is required.

v2:
- also handling pipe restrictions

BSpec: 55229
Reviewed-by: Gwan-gyeong Mun  # v1
Cc: Ville Syrjälä 
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 65 +---
 1 file changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 19a96d3c4acf4..e3af1dc358bd2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -720,11 +720,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp 
*intel_dp,
 static bool intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
  struct intel_crtc_state 
*crtc_state)
 {
-   struct intel_atomic_state *state = 
to_intel_atomic_state(crtc_state->uapi.state);
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   struct intel_plane_state *plane_state;
-   struct intel_plane *plane;
-   int i;
 
if (!dev_priv->params.enable_psr2_sel_fetch &&
intel_dp->psr.debug != I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
@@ -739,14 +735,6 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
 
-   for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
-   if (plane_state->uapi.rotation != DRM_MODE_ROTATE_0) {
-   drm_dbg_kms(&dev_priv->drm,
-   "PSR2 sel fetch not enabled, plane 
rotated\n");
-   return false;
-   }
-   }
-
/* Wa_14010254185 Wa_14010103792 */
if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
drm_dbg_kms(&dev_priv->drm,
@@ -1580,6 +1568,41 @@ static void cursor_area_workaround(const struct 
intel_plane_state *new_plane_sta
clip_area_update(pipe_clip, damaged_area);
 }
 
+/*
+ * TODO: Not clear how to handle planes with negative position,
+ * also planes are not updated if they have a negative X
+ * position so for now doing a full update in this cases
+ *
+ * Plane scaling and rotation is not supported by selective fetch and both
+ * properties can change without a modeset, so need to be check at every
+ * atomic commmit.
+ */
+static bool psr2_sel_fetch_plane_state_supported(const struct 
intel_plane_state *plane_state)
+{
+   if (plane_state->uapi.dst.y1 < 0 ||
+   plane_state->uapi.dst.x1 < 0 ||
+   plane_state->scaler_id >= 0 ||
+   plane_state->uapi.rotation != DRM_MODE_ROTATE_0)
+   return false;
+
+   return true;
+}
+
+/*
+ * Check for pipe properties that is not supported by selective fetch.
+ *
+ * TODO: pipe scaling causes a modeset but skl_update_scaler_crtc() is executed
+ * after intel_psr_compute_config(), so for now keeping PSR2 selective fetch
+ * enabled and going to the full update path.
+ */
+static bool psr2_sel_fetch_pipe_state_supported(const struct intel_crtc_state 
*crtc_state)
+{
+   if (crtc_state->scaler_state.scaler_id >= 0)
+   return false;
+
+   return true;
+}
+
 int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
 {
@@ -1593,6 +1616,11 @@ int intel_psr2_sel_fetch_update(struct 
intel_atomic_state *state,
if (!crtc_state->enable_psr2_sel_fetch)
return 0;
 
+   if (!psr2_sel_fetch_pipe_state_supported(crtc_state)) {
+   full_update = true;
+   goto skip_sel_fetch_set_loop;
+   }
+
/*
 * Calculate minimal selective fetch area of each plane and calculate
 * the pipe damaged area.
@@ -1612,13 +1640,7 @@ int intel_psr2_sel_fetch_update(struct 
intel_atomic_state *state,
!old_plane_state->uapi.visible)
continue;
 
-   /*
-* TODO: Not clear how to handle planes with negative position,
-* also planes are not updated if they have a ne

[Intel-gfx] [PATCH v2 3/9] drm/i915/display: Drop unnecessary frontbuffer flushes

[José Roberto de Souza]

This unnecessary flushes are hurting power-savings are it causes
features like PSR, FBC and DRRS to disable it self to handle
frontbuffer rendering, below some explanation of why each removed
call is not necessary.

The flush in intel_prepare_plane_fb() is not required as framebuffer
will be flipped and power-saving features do the proper flip handling
in hardware.

intel_find_initial_plane_obj() flush is not required because it is
only executed during driver load and at this point the power-saving
features are not even enabled.

And the last one intelfb_create(), is also not required as at this
point the fbdev was just allocated, userspace will draw on
it what will trigger frontbuffer invalidates and flushes later on.

Cc: Ville Syrjälä 
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 ---
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 4ce80ca7751f0..9e9db1b0a907b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1711,8 +1711,6 @@ intel_find_initial_plane_obj(struct intel_crtc *crtc,
plane_state->uapi.crtc = &crtc->base;
intel_plane_copy_uapi_to_hw_state(plane_state, plane_state, crtc);
 
-   intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
-
atomic_or(plane->frontbuffer_bit, &to_intel_frontbuffer(fb)->bits);
 }
 
@@ -10755,7 +10753,6 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
return ret;
 
i915_gem_object_wait_priority(obj, 0, &attr);
-   i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
 
if (!new_plane_state->uapi.fence) { /* implicit fencing */
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 60d3ded270476..53484267b2a4a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -230,8 +230,6 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unlock;
}
 
-   intel_frontbuffer_flush(to_frontbuffer(ifbdev), ORIGIN_DIRTYFB);
-
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
drm_err(&dev_priv->drm, "Failed to allocate fb_info\n");
-- 
2.33.0

[Intel-gfx] [PATCH v2 5/9] drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled

[José Roberto de Souza]

Legacy cursor APIs are handled by intel_legacy_cursor_update(), that
calls drm_atomic_helper_update_plane() when going through the
slow/atomic path to update cursor, what was the case for PSR2
selective fetch.

drm_atomic_helper_update_plane() sets
drm_atomic_state->legacy_cursor_update to true when updating the
cursor plane, to allow several cursor updates to happen within the
same frame, as userspace does that.
If drivers waited for a vblank increment at the end of every cursor
movement that would cause a visible lag in the cursor.

But this optimization do not properly work with PSR2 selective fetch
dirt area calculation, for example if within a single frame the cursor
had 3 moves the final dirt area programmed to PSR2_MAN_TRK_CTL would
be based in the second movement as old state and third movement as new
state, not updating the area where cursor was in the first state.

So here switching back to the fast path approach in
intel_legacy_cursor_update() and handling cursor movements as
frontbuffer rendering(psr_force_hw_tracking_exit()), that is not the
most optimal for power-savings but is the solution that we have until
mailbox style updates is implemented.

Also removing the cursor workaround as not it is properly undestand
the issue and is know that it will never cover all the cases.

Cc: Ville Syrjälä 
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_cursor.c   |  5 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
 .../gpu/drm/i915/display/intel_frontbuffer.h  |  1 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 59 +--
 4 files changed, 20 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 901ad3a4c8c3b..f6dcb5aa63f64 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -639,8 +639,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
 * FIXME bigjoiner fastpath would be good
 */
if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
-   crtc_state->update_pipe || crtc_state->bigjoiner ||
-   crtc_state->enable_psr2_sel_fetch)
+   crtc_state->update_pipe || crtc_state->bigjoiner)
goto slow;
 
/*
@@ -698,7 +697,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
goto out_free;
 
intel_frontbuffer_flush(to_intel_frontbuffer(new_plane_state->hw.fb),
-   ORIGIN_FLIP);
+   ORIGIN_CURSOR_UPDATE);
intel_frontbuffer_track(to_intel_frontbuffer(old_plane_state->hw.fb),
to_intel_frontbuffer(new_plane_state->hw.fb),
plane->frontbuffer_bit);
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 46f62fdf9eeeb..77b00e3a92c23 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1199,7 +1199,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
if (!HAS_FBC(dev_priv))
return;
 
-   if (origin == ORIGIN_FLIP)
+   if (origin == ORIGIN_FLIP || origin == ORIGIN_CURSOR_UPDATE)
return;
 
mutex_lock(&fbc->lock);
@@ -1224,7 +1224,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
 
fbc->busy_bits &= ~frontbuffer_bits;
 
-   if (origin == ORIGIN_FLIP)
+   if (origin == ORIGIN_FLIP || origin == ORIGIN_CURSOR_UPDATE)
goto out;
 
if (!fbc->busy_bits && fbc->crtc &&
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.h 
b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
index 4b977c1e4d52b..a88441edc8f94 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
@@ -37,6 +37,7 @@ enum fb_op_origin {
ORIGIN_CS,
ORIGIN_FLIP,
ORIGIN_DIRTYFB,
+   ORIGIN_CURSOR_UPDATE,
 };
 
 struct intel_frontbuffer {
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7185801d5deff..e8af39591dfea 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1558,28 +1558,6 @@ static void intel_psr2_sel_fetch_pipe_alignment(const 
struct intel_crtc_state *c
drm_warn(&dev_priv->drm, "Missing PSR2 sel fetch alignment with 
DSC\n");
 }
 
-/*
- * FIXME: Not sure why but when moving the cursor fast it causes some artifacts
- * of the cursor to be left in the cursor path, adding some pixels above the
- * cursor to the damaged area fixes the issue.
- */
-static void cursor_area_workaround(const struct intel_plane_state 
*new_plane_state,
-  struct drm_rect *damaged_area,
-  struct drm_rect *pipe_clip)
-{
- 

[Intel-gfx] [PATCH v2 6/9] drm/i915/display/adlp: Optimize PSR2 power-savings in corner cases

[José Roberto de Souza]

The Wa_14014971508 is required to fix scanout when a feature that i915
do not support is enabled and this feature is not planned to be enabled
for adlp.

Keeping this workaround enabled can badly hurt power-savings when
a full frame fetch is required(see psr2_sel_fetch_plane_state_supported()
and psr2_sel_fetch_pipe_state_supported()).

Here a example that could badly hurt power-savings, userspace does
a page flip to a rotated plane, so CONTINUOS_FULL_FRAME set.
But then for a whole 30 seconds nothing in the screen requires updates
but because CONTINUOS_FULL_FRAME is set, it will not go into DC5/DC6.

Reverting Wa_14014971508 fixes that, as only a single frame will be
sent and then display can go to DC5/DC6 for those 30 seconds of
idleness.

BSpec: 54369
Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index e8af39591dfea..b37f123fe0c97 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1499,15 +1499,10 @@ static void psr2_man_trk_ctl_calc(struct 
intel_crtc_state *crtc_state,
 
if (full_update) {
/*
-* Wa_14014971508:adlp
-* SINGLE_FULL_FRAME bit is not hold in register so can not be
-* restored by DMC, so using CONTINUOS_FULL_FRAME to mimic that
+* Not applying Wa_14014971508:adlp as we do not support the
+* feature that requires this workaround.
 */
-   if (IS_ALDERLAKE_P(dev_priv))
-   val |= ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME;
-   else
-   val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
-
+   val |= man_trk_ctl_single_full_frame_bit_get(dev_priv);
goto exit;
}
 
-- 
2.33.0

[Intel-gfx] [PATCH v2 7/9] drm/i915/display/adlp: Allow PSR2 to be enabled

[José Roberto de Souza]

With all the recent fixes PSR2 is properly working in Alderlake-P but
due to some issues that don't have software workarounds it will not be
supported in display steppings older than B0.

Even with this patch PSR2 will no be enabled by default in ADL-P, it
still requires enable_psr2_sel_fetch to be set to true, what some
of our tests does.

Cc: Gwan-gyeong Mun 
Reviewed-by: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index b37f123fe0c97..06a96368b18f1 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -830,12 +830,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
-   /*
-* We are missing the implementation of some workarounds to enabled PSR2
-* in Alderlake_P, until ready PSR2 should be kept disabled.
-*/
-   if (IS_ALDERLAKE_P(dev_priv)) {
-   drm_dbg_kms(&dev_priv->drm, "PSR2 is missing the implementation 
of workarounds\n");
+   if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
+   drm_dbg_kms(&dev_priv->drm, "PSR2 not completely functional in 
this stepping\n");
return false;
}
 
-- 
2.33.0

[Intel-gfx] [PATCH v2 4/9] drm/i915/display: Handle frontbuffer rendering when PSR2 selective fetch is enabled

[José Roberto de Souza]

When PSR2 selective fetch is enabled writes to CURSURFLIVE alone do
not causes the panel to be updated when doing frontbuffer rendering.

>From what I was able to figure from experiments the writes to
CURSURFLIVE takes PSR2 from deep sleep but panel is not updated
because PSR2_MAN_TRK_CTL has no start and end region set.

As we don't have the dirt area from current flush and invalidate API
and even if we did userspace could do several draws to frontbuffer and
we would need a way to append all the damaged areas of all the draws
that need to be part of next frame.

So here only programing PSR2_MAN_TRK_CTL to do a single full frame
fetch.

It is a safe approach as if scanout is in the visible area
the single full frame will only be visible for hardware in the next
frame because of the double buffering, and if scanout is in vblank
area it will be draw in the current frame.

No need to disable PSR and wait a few miliseconds to enable it again.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8534cbb0d5144..7185801d5deff 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1397,10 +1397,22 @@ void intel_psr_resume(struct intel_dp *intel_dp)
mutex_unlock(&psr->lock);
 }
 
+static inline u32 man_trk_ctl_single_full_frame_bit_get(struct 
drm_i915_private *dev_priv)
+{
+   return IS_ALDERLAKE_P(dev_priv) ?
+  ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME :
+  PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
+}
+
 static void psr_force_hw_tracking_exit(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
+   if (intel_dp->psr.psr2_sel_fetch_enabled)
+   intel_de_rmw(dev_priv,
+PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder), 0,
+man_trk_ctl_single_full_frame_bit_get(dev_priv));
+
/*
 * Display WA #0884: skl+
 * This documented WA for bxt can be safely applied
-- 
2.33.0

[Intel-gfx] [PATCH v2 8/9] drm/i915/display: Enable PSR2 selective fetch by default

[José Roberto de Souza]

With all the past fixes now this feature is functional and can be
enabled by default in desktop enviroments that uses compositor.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Reviewed-by: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index f27eceb82c0f5..8d725b64592d8 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -55,7 +55,7 @@ struct drm_printer;
param(int, enable_fbc, -1, 0600) \
param(int, enable_psr, -1, 0600) \
param(bool, psr_safest_params, false, 0400) \
-   param(bool, enable_psr2_sel_fetch, false, 0400) \
+   param(bool, enable_psr2_sel_fetch, true, 0400) \
param(int, disable_power_well, -1, 0400) \
param(int, enable_ips, 1, 0600) \
param(int, invert_brightness, 0, 0600) \
-- 
2.33.0

[Intel-gfx] [PATCH v2 2/9] drm/i915/display/psr: Do full fetch when handling multi-planar formats

[José Roberto de Souza]

From: Gwan-gyeong Mun 

We are still missing the PSR2 selective fetch handling of multi-planar
formats but until proper handle is added we can workaround it by
doing full frames fetch when state has such formats.

Cc: Ville Syrjälä 
Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index e3af1dc358bd2..8534cbb0d5144 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1573,6 +1573,9 @@ static void cursor_area_workaround(const struct 
intel_plane_state *new_plane_sta
  * also planes are not updated if they have a negative X
  * position so for now doing a full update in this cases
  *
+ * TODO: We are missing multi-planar formats handling, until it is
+ * implemented it will send full frame updates.
+ *
  * Plane scaling and rotation is not supported by selective fetch and both
  * properties can change without a modeset, so need to be check at every
  * atomic commmit.
@@ -1582,6 +1585,7 @@ static bool psr2_sel_fetch_plane_state_supported(const 
struct intel_plane_state
if (plane_state->uapi.dst.y1 < 0 ||
plane_state->uapi.dst.x1 < 0 ||
plane_state->scaler_id >= 0 ||
+   plane_state->hw.fb->format->num_planes > 1 ||
plane_state->uapi.rotation != DRM_MODE_ROTATE_0)
return false;
 
-- 
2.33.0

[Intel-gfx] [PATCH v2 9/9] drm/i915/display: Always wait vblank counter to increment when commit needs a modeset

[José Roberto de Souza]

Not waiting for vblank counter to increment could potentialy cause
issues as commits after the one that needs a modeset could change
state of entities that are not committed into hardware yet.

Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 9e9db1b0a907b..9c49b6031cb5e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10494,15 +10494,24 @@ static int intel_atomic_commit(struct drm_device *dev,
 * FIXME doing watermarks and fb cleanup from a vblank worker
 * (assuming we had any) would solve these problems.
 */
-   if (DISPLAY_VER(dev_priv) < 9 && state->base.legacy_cursor_update) {
+   if (state->base.legacy_cursor_update) {
struct intel_crtc_state *new_crtc_state;
struct intel_crtc *crtc;
int i;
 
-   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
-   if (new_crtc_state->wm.need_postvbl_update ||
-   new_crtc_state->update_wm_post)
+   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, 
i) {
+   if (intel_crtc_needs_modeset(new_crtc_state)) {
+   state->base.legacy_cursor_update = false;
+   break;
+   }
+
+   if (DISPLAY_VER(dev_priv) < 9 &&
+   (new_crtc_state->wm.need_postvbl_update ||
+new_crtc_state->update_wm_post)) {
state->base.legacy_cursor_update = false;
+   break;
+   }
+   }
}
 
ret = intel_atomic_prepare_commit(state);
-- 
2.33.0