Re: [Intel-gfx] [PATCH 00/20] drm/i915: Fix up DP DFP 4:2:0 handling more

[Nautiyal, Ankit K]

Hi Ville,

Thanks for the patch and getting a unified approach for DP, HDMI and DFP 
for YCbCr420 output.


I am trying to have 8k@60 YUV420 via an HDMI2.1 PCON, without having to 
use PCONs Color conversion capability,


but running into different issues, and failing miserably. I think this 
patch series will help get there.


There are a couple of queries and suggestions I have regarding the big 
joiner and DSC, which I'll reply to the patches.


I will also try to test these on the setup I have available.

Thanks & Regards,

Ankit

On 10/15/2021 7:09 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently we're failing to respect the sink's max TMDS clock
in the DP HDMI DFP code, and exceeding them means the sink
won't show a picture [1]. So let's improve the situation by
checking those limits, and generally fixing up a bunch things
in the deep color/4:2:0 related stuff for both native HDMI
and DP HDMI DFPs.

The end result is fairly unified apporach to this stuff on
both sides of the aisle. There's probably more we could try
to abstract to share even more code. But that will need a lot
of actual thought so leave it for later.

The high level algorithm is basically now:
for_each(respect TMDS clock limits, disrespect TMDS clock limits)
for_each(YCbCr 4:2:0 only, RGB 4:4:4, YCbCr 4:2:0 also)
for_each(12bpc,10bpc,8bpc)
compute_and_check_the_things
with some obvious tweaks for HDMI vs. DP specifics.

[1] https://gitlab.freedesktop.org/drm/intel/-/issues/4095

Ville Syrjälä (20):
   drm/i915/hdmi: Split intel_hdmi_bpc_possible() to source vs. sink pair
   drm/i915/hdmi: Introduce intel_hdmi_is_ycbr420()
   drm/i915/hdmi: Introduce intel_hdmi_tmds_clock()
   drm/i915/hdmi: Unify "4:2:0 also" logic between .mode_valid() and
 .compute_config()
   drm/i915/hdmi: Extract intel_hdmi_output_format()
   drm/i915/hdmi: Clean up TMDS clock limit exceeding user mode handling
   drm/i915/hdmi: Simplify intel_hdmi_mode_clock_valid()
   drm/i915/dp: Reuse intel_hdmi_tmds_clock()
   drm/i915/dp: Extract intel_dp_tmds_clock_valid()
   drm/i915/dp: Respect the sink's max TMDS clock when dealing with
 DP->HDMI DFPs
   drm/i915/dp: Extract intel_dp_has_audio()
   drm/i915/dp: s/intel_dp_hdmi_ycbcr420/intel_dp_is_ycbcr420/
   drm/i915/dp: Reorder intel_dp_compute_config() a bit
   drm/i915/dp: Pass around intel_connector rather than drm_connector
   drm/i915/dp: Make intel_dp_output_format() usable for "4:2:0 also"
 modes
   drm/i915/dp: Rework HDMI DFP TMDS clock handling
   drm/i915/dp: Add support for "4:2:0 also" modes for DP
   drm/i915/dp: Duplicate native HDMI TMDS clock limit handling for DP
 HDMI DFPs
   drm/i915/dp: Fix DFP rgb->ycbcr conversion matrix
   drm/i915/dp: Disable DFP RGB->YCbCr conversion for now

  drivers/gpu/drm/i915/display/intel_dp.c   | 339 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c | 220 --
  drivers/gpu/drm/i915/display/intel_hdmi.h |   5 +-
  3 files changed, 342 insertions(+), 222 deletions(-)

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Restructure probe to handle multi-tile platforms

[Lucas De Marchi]

On Wed, Oct 13, 2021 at 03:12:55PM +0300, Jani Nikula wrote:

On Fri, 08 Oct 2021, Matt Roper  wrote:

On a multi-tile platform, each tile has its own registers + GGTT space,
and BAR 0 is extended to cover all of them.  Upcoming patches will start
exposing the tiles as multiple GTs within a single PCI device.  In
preparation for supporting such setups, restructure the driver's probe
code a bit.

Only the primary/root tile is initialized for now; the other tiles will
be detected and plugged in by future patches once the necessary
infrastructure is in place to handle them.

Original-author: Abdiel Janulgue
Cc: Daniele Ceraolo Spurio 
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c   | 45 
 drivers/gpu/drm/i915/gt/intel_gt.h   |  3 ++
 drivers/gpu/drm/i915/gt/intel_gt_pm.c|  9 -
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  5 +++
 drivers/gpu/drm/i915/i915_drv.c  | 20 +--
 drivers/gpu/drm/i915/intel_uncore.c  | 12 +++
 drivers/gpu/drm/i915/intel_uncore.h  |  3 +-
 7 files changed, 76 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 1cb1948ac959..f4bea1f1de77 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -900,6 +900,51 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt, 
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
 }

+static int
+tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t phys_addr)
+{
+   int ret;
+
+   intel_uncore_init_early(gt->uncore, gt->i915);
+
+   ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+   if (ret)
+   return ret;
+
+   gt->phys_addr = phys_addr;
+
+   return 0;
+}
+
+static void tile_cleanup(struct intel_gt *gt)
+{
+   intel_uncore_cleanup_mmio(gt->uncore);
+}
+
+int intel_probe_gts(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   phys_addr_t phys_addr;
+   unsigned int mmio_bar;
+   int ret;
+
+   mmio_bar = GRAPHICS_VER(i915) == 2 ? 1 : 0;
+   phys_addr = pci_resource_start(pdev, mmio_bar);
+
+   /* We always have at least one primary GT on any device */
+   ret = tile_setup(&i915->gt, 0, phys_addr);
+   if (ret)
+   return ret;
+
+   /* TODO: add more tiles */
+   return 0;
+}
+
+void intel_gts_release(struct drm_i915_private *i915)
+{
+   tile_cleanup(&i915->gt);
+}


Please call the functions intel_gt_*.


actually besides the name, the fact that these take i915 as argument
seems to suggest they are in the wrong place. Probably this part should
remain in i915_drv.c with name i915_setup_gts()?

then we could export tile_setup as intel_gt_setup() or something else
(name here is confusing IMO as in some places we have
`init(); ...; setup()` and in other this is `setup(); ...; init();` like
in patch 1. We already have

  - intel_gt_init_early()
  - intel_gt_init_hw_early()
  - intel_gt_init_mmio()
  - intel_gt_init()


given this is just initiliazing mmio for that specific gt (tile), do we
actually need a new init/setup entrypoint?



BR,
Jani.




+
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 74e771871a9b..f4f35a70cbe4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -85,6 +85,9 @@ static inline bool intel_gt_needs_read_steering(struct 
intel_gt *gt,

 u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);

+int intel_probe_gts(struct drm_i915_private *i915);
+void intel_gts_release(struct drm_i915_private *i915);
+
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p);

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 524eaf678790..76f498edb0d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -126,7 +126,14 @@ static const struct intel_wakeref_ops wf_ops = {

 void intel_gt_pm_init_early(struct intel_gt *gt)
 {
-   intel_wakeref_init(>->wakeref, gt->uncore->rpm, &wf_ops);
+   /*
+* We access the runtime_pm structure via gt->i915 here rather than
+* gt->uncore as we do elsewhere in the file because gt->uncore is not
+* yet initialized for all tiles at this point in the driver startup.
+* runtime_pm is per-device rather than per-tile, so this is still the
+* correct structure.
+*/
+   intel_wakeref_init(>->wakeref, >->i915->runtime_pm, &wf_ops);
seqcount_mutex_init(>->stats.lock, >->wakeref.mutex);
 }

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/dr

Re: [Intel-gfx] [PATCH] drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers

[Kasireddy, Vivek]

Hi Ville,

> 
> On Mon, Oct 25, 2021 at 11:38:11PM -0700, Vivek Kasireddy wrote:
> > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> > more framebuffers/scanout buffers results in only one that is mappable/
> > fenceable. Therefore, pageflipping between these 2 FBs where only one
> > is mappable/fenceable creates latencies large enough to miss alternate
> > vblanks thereby producing less optimal framerate.
> >
> > This mainly happens because when i915_gem_object_pin_to_display_plane()
> > is called to pin one of the FB objs, the associated vma is identified
> > as misplaced and therefore i915_vma_unbind() is called which unbinds and
> > evicts it. This misplaced vma gets subseqently pinned only when
> > i915_gem_object_ggtt_pin_ww() is called without the mappable flag. This
> > results in a latency of ~10ms and happens every other vblank/repaint cycle.
> >
> > Testcase:
> > Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
> > with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
> > a frame ~7ms before the next vblank, the latencies seen between atomic
> > commit and flip event is 7, 24 (7 + 16.66), 7, 24. suggesting that
> > it misses the vblank every other frame.
> >
> > Here is the ftrace snippet that shows the source of the ~10ms latency:
> >   i915_gem_object_pin_to_display_plane() {
> > 0.102 us   |i915_gem_object_set_cache_level();
> > i915_gem_object_ggtt_pin_ww() {
> > 0.390 us   |  i915_vma_instance();
> > 0.178 us   |  i915_vma_misplaced();
> >   i915_vma_unbind() {
> >   __i915_active_wait() {
> > 0.082 us   |i915_active_acquire_if_busy();
> > 0.475 us   |  }
> >   intel_runtime_pm_get() {
> > 0.087 us   |intel_runtime_pm_acquire();
> > 0.259 us   |  }
> >   __i915_active_wait() {
> > 0.085 us   |i915_active_acquire_if_busy();
> > 0.240 us   |  }
> >   __i915_vma_evict() {
> > ggtt_unbind_vma() {
> >   gen8_ggtt_clear_range() {
> > 10507.255 us |}
> > 10507.689 us |  }
> > 10508.516 us |   }
> >
> > Cc: Maarten Lankhorst 
> > Cc: Tvrtko Ursulin 
> > Cc: Manasi Navare 
> > Signed-off-by: Vivek Kasireddy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_fb_pin.c  | 11 +--
> >  drivers/gpu/drm/i915/display/intel_overlay.c | 11 ---
> >  drivers/gpu/drm/i915/gem/i915_gem_domain.c   |  6 --
> >  drivers/gpu/drm/i915/gem/i915_gem_object.h   |  3 ++-
> >  4 files changed, 23 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > index 3f77f3013584..53c156d9a9f9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > @@ -144,7 +144,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> >
> > if (!ret) {
> > vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
> > -  view, pinctl);
> > +  view, pinctl, 
> > uses_fence);
> > if (IS_ERR(vma)) {
> > ret = PTR_ERR(vma);
> > goto err_unpin;
> > @@ -218,9 +218,16 @@ int intel_plane_pin_fb(struct intel_plane_state 
> > *plane_state)
> > INTEL_INFO(dev_priv)->display.cursor_needs_physical;
> >
> > if (!intel_fb_uses_dpt(fb)) {
> > +   struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> > +   struct intel_crtc_state *crtc_state =
> > +   to_intel_crtc_state(crtc->base.state);
> > +   bool uses_fence = intel_plane_uses_fence(plane_state);
> > +   bool is_bigjoiner = crtc_state->bigjoiner ||
> > +   crtc_state->bigjoiner_slave;
> 
> Bigjoiner is just an implementation detail. It is not the cause of any
> of this.
[Kasireddy, Vivek] Right, bigjoiner/8K is just exposing the underlying issue; 
which is
that sometimes, large objects/scanout buffers that fail range overflow checks 
and thus
are not mappable/fenceable keep getting evicted and reinserted leading to 
latencies. 
I guess I could mark an object/vma as permanently un-mappable/un-fenceable and 
try
not to map it subsequently but this would result in one scanout buffer that is 
mappable
but others that are not. Would this be acceptable -- assuming we are 
pageflipping
between multiple FBs?
Any ideas on solving this issue cleanly?

Thanks,
Vivek
 
> 
> > +
> > vma = intel_pin_and_fence_fb_obj(fb, phys_cursor,
> >  &plane_state->view.gtt,
> > -
> > intel_plane_uses_fence(plane_state),
> > +uses_fence && !is_bigjoiner,
> >   

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

[Thomas Hellström]

Hi, John,

On 10/26/21 21:55, John Harrison wrote:

On 10/21/2021 23:23, Thomas Hellström wrote:

On 10/21/21 22:37, Matthew Brost wrote:

On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:

Hi, Matthew,

On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:

The hangcheck selftest blocks per engine resets by setting magic bits
in
the reset flags. This is incorrect for GuC submission because if the
GuC
fails to reset an engine we would like to do a full GT reset. Do no
set
these magic bits when using GuC submission.

Side note this lockless algorithm with magic bits to block resets
really
should be ripped out.


Lockless algorithm aside, from a quick look at the code in
intel_reset.c it appears to me like the interface that falls back to a
full GT reset is intel_gt_handle_error() whereas intel_engine_reset()
is explicitly intended to not do that, so is there a discrepancy
between GuC and non-GuC here?


With GuC submission when an engine reset fails, we get an engine reset
failure notification which triggers a full GT reset
(intel_guc_engine_failure_process_msg in intel_guc_submission.c). That
reset is blocking by setting these magic bits. Clearing the bits in 
this

function doesn't seem to unblock that reset either, the driver tries to
unload with a worker blocked, and results in the blow up. Something 
with

this lockless algorithm could be wrong as clear of the bit should
unlblock the reset but it is doesn't. We can look into that but in the
meantime we need to fix this test to be able to fail gracefully and not
crash CI.


Yeah, for that lockless algorithm if needed, we might want to use a 
ww_mutex per engine or something,
but point was that AFAICT at least one of the tests that set those 
flags explicitly tested the functionality that no other engines than 
the intended one was reset when the intel_engine_reset() function was 
used, and then if GuC submission doesn't honor that, wouldn't a 
better approach be to make a code comment around intel_engine_reset() 
to explain the differences and disable that particular test for GuC?. 
Also wouldn't we for example we see a duplicated full GT reset with 
GuC if intel_engine_reset() fails as part of the 
intel_gt_handle_error() function?

Re-reading this thread, I think there is a misunderstanding.

The selftests themselves have already been updated to support GuC 
based engine resets. That is done by submitting a hanging context and 
letting the GuC detect the hang and issue a reset. There is no 
mechanism available for i915 to directly issue or request an engine 
based reset (because i915 does not know what is running on any given 
engine at any given time, being disconnected from the scheduler).


So the tests are already correctly testing per engine resets and do 
not go anywhere near either intel_engine_reset() or 
intel_gt_handle_error() when GuC submission is used. The problem is 
what happens if the engine reset fails (which supposedly can only 
happen with broken hardware). In that scenario, there is an 
asynchronous message from GuC to i915 to notify us of the failure. The 
KMD receives that notification and then (eventually) calls 
intel_gt_handle_error() to issue a full GT reset. However, that is 
blocked because the selftest is not expecting it and has vetoed the 
possibility.


This is where my understanding of the discussion differs. According to 
Matthew, the selftest actually proceeds to clear the bits, but the 
worker that calls into intel_gt_handle_error() never wakes up. (and 
that's probably due to clear_bit() being used instead of 
clear_and_wake_up_bit()).


And my problem with this particular patch is that it adds even more "if 
(!guc_submission)" which is already sprinkled all over the place in the 
selftests to the point that it becomes difficult to see what (if 
anything) the tests are really testing. For example 
igt_reset_nop_engine() from a cursory look looks like it's doing 
something but inside the engine loop it becomes clear that the test 
doesn't do *anything* except iterate over engines. Same for 
igt_reset_engines() in the !TEST_ACTIVE case and for 
igt_reset_idle_engine(). For some other tests the reset_count checks are 
gone, leaving only a test that we actually do a reset.


So if possible, as previously mentioned, I think a solution without 
adding more of this in the selftests is preferrable. To me the best 
option is probably be the one you suggest in your previous email: Don't 
wait on the I915_RESET_ENGINE bits with GuC in intel_gt_handle_error(), 
(or perhaps extract what's left in a separate function called from the 
GuC handler).


Thanks,

Thomas

Re: [Intel-gfx] [PATCH 3/3] drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

[Imre Deak]

On Tue, Oct 26, 2021 at 08:52:12PM +0300, Jani Nikula wrote:
> On Tue, 26 Oct 2021, Imre Deak  wrote:
> > By using the modifier plane capability flags to encode the modifiers'
> > CCS type and tiling attributes, it becomes simpler to the check for
> > any of these capabilities when providing the list of supported
> > modifiers.
> >
> > This also allows distinguishing modifiers on future platforms where
> > platforms with the same display version support different modifiers. An
> > example is DG2 and ADLP, both being D13, where DG2 supports only F and X
> > tiling, while ADLP supports only Y and X tiling. With the
> > PLANE_HAS_TILING_* plane caps added in this patch we can provide the
> > correct modifiers for each platform.
> >
> > Cc: Juha-Pekka Heikkila 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/i9xx_plane.c |  2 +-
> >  drivers/gpu/drm/i915/display/intel_fb.c   | 80 +--
> >  drivers/gpu/drm/i915/display/intel_fb.h   | 11 ++-
> >  drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
> >  .../drm/i915/display/skl_universal_plane.c|  7 +-
> >  5 files changed, 53 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
> > b/drivers/gpu/drm/i915/display/i9xx_plane.c
> > index a939accff7ee2..fdb857df8b0be 100644
> > --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> > +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> > @@ -860,7 +860,7 @@ intel_primary_plane_create(struct drm_i915_private 
> > *dev_priv, enum pipe pipe)
> > plane->disable_flip_done = ilk_primary_disable_flip_done;
> > }
> >  
> > -   modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING);
> > +   modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING_X);
> >  
> > if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv))
> > ret = drm_universal_plane_init(&dev_priv->drm, &plane->base,
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index 6b68f69940f0b..6339669d86df5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -120,29 +120,25 @@ struct intel_modifier_desc {
> > .formats = format_list, \
> > .format_count = ARRAY_SIZE(format_list)
> >  
> > -   u8 tiling;
> > -   u8 is_linear:1;
> > +   u8 plane_caps;
> >  
> > struct {
> > -#define INTEL_CCS_RC   BIT(0)
> > -#define INTEL_CCS_RC_CCBIT(1)
> > -#define INTEL_CCS_MC   BIT(2)
> > -
> > -#define INTEL_CCS_ANY  (INTEL_CCS_RC | INTEL_CCS_RC_CC | 
> > INTEL_CCS_MC)
> > -   u8 type:3;
> > u8 cc_planes:3;
> > u8 packed_aux_planes:4;
> > u8 planar_aux_planes:4;
> > } ccs;
> >  };
> >  
> > +#define PLANE_HAS_CCS_ANY  (PLANE_HAS_CCS_RC | PLANE_HAS_CCS_RC_CC | 
> > PLANE_HAS_CCS_MC)
> > +#define PLANE_HAS_TILING_ANY   (PLANE_HAS_TILING_X | 
> > PLANE_HAS_TILING_Y | PLANE_HAS_TILING_Yf)
> 
> _MASK seems like the customary suffix for things that are masks.

Ok, will rename this.

> > +#define PLANE_HAS_TILING_NONE  0
> > +
> >  static const struct intel_modifier_desc intel_modifiers[] = {
> > {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > .display_ver = { 12, 13 },
> > -   .tiling = I915_TILING_Y,
> > +   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_MC,
> >  
> > -   .ccs.type = INTEL_CCS_MC,
> > .ccs.packed_aux_planes = BIT(1),
> > .ccs.planar_aux_planes = BIT(2) | BIT(3),
> >  
> > @@ -150,18 +146,16 @@ static const struct intel_modifier_desc 
> > intel_modifiers[] = {
> > }, {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > .display_ver = { 12, 13 },
> > -   .tiling = I915_TILING_Y,
> > +   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC,
> >  
> > -   .ccs.type = INTEL_CCS_RC,
> > .ccs.packed_aux_planes = BIT(1),
> >  
> > FORMAT_OVERRIDE(gen12_ccs_formats),
> > }, {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC,
> > .display_ver = { 12, 13 },
> > -   .tiling = I915_TILING_Y,
> > +   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC_CC,
> >  
> > -   .ccs.type = INTEL_CCS_RC_CC,
> > .ccs.cc_planes = BIT(2),
> > .ccs.packed_aux_planes = BIT(1),
> >  
> > @@ -169,39 +163,34 @@ static const struct intel_modifier_desc 
> > intel_modifiers[] = {
> > }, {
> > .modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
> > .display_ver = { 9, 11 },
> > -   .tiling = I915_TILING_NONE,
> > +   .plane_caps = PLANE_HAS_TILING_Yf | PLANE_HAS_CCS_RC,
> >  
> > -   .ccs.type = INTEL_CCS_RC,
> > .ccs.packed_aux_planes = BIT(1),
> >  
> > FORMAT_OVERRIDE(skl_ccs_formats),
> > 

Re: [Intel-gfx] [PATCH 02/11] drm/i915: split general MMIO setup from per-GT uncore init

[Lucas De Marchi]

On Fri, Oct 08, 2021 at 02:56:26PM -0700, Matt Roper wrote:

From: Daniele Ceraolo Spurio 

In coming patches we'll be doing the actual tile initialization between
these two uncore init phases.

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi

Re: [Intel-gfx] [PATCH 01/11] drm/i915: rework some irq functions to take intel_gt as argument

[Lucas De Marchi]

On Fri, Oct 08, 2021 at 02:56:25PM -0700, Matt Roper wrote:

From: Paulo Zanoni 

We'll be adding multi-tile support soon; on multi-tile platforms
interrupts are per-tile and every tile has the full set of
interrupt registers.

In this commit we start passing intel_gt instead of dev_priv for the
functions that are related to Xe_HP irq handling. Right now we're still
passing tile 0 everywhere, but in later patches we'll start actually
passing the correct tile.

Signed-off-by: Paulo Zanoni 
Co-authored-by: Tvrtko Ursulin 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Matt Roper 



mostly replacing the i915->uncore with the gt->uncore, which right now
should be the same. The other changes are just changing

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

Re: [Intel-gfx] [PATCH] drm/i915: abstraction for iosf to compile on all archs

[Lucas De Marchi]

On Sat, Oct 23, 2021 at 12:57:56AM +0530, Mullati Siva wrote:

From: "Mullati, Siva" 

The asm/iosf_mbi.h header is x86-only. Let's make IOSF_MBI kconfig
selection conditional to x86 and provide a header with stubs for other
architectures. This helps getting i915 available for other
architectures in future.

Signed-off-by: Mullati, Siva 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi

[Intel-gfx] ✗ Fi.CI.BUILD: failure for use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace

[Patchwork]

== Series Details ==

Series: use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace
URL   : https://patchwork.freedesktop.org/series/96327/
State : failure

== Summary ==

Applying: dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES macro and callbacks
Applying: drm: fix doc grammar
Applying: amdgpu: use dyndbg.CATEGORIES to control existing pr_dbgs
Applying: i915/gvt: trim spaces from pr_debug "gvt: core:" prefixes
Applying: i915/gvt: use dyndbg.CATEGORIES for existing pr_debugs
Applying: drm_print: add choice to use dynamic debug in drm-debug
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/Makefile).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0006 drm_print: add choice to use dynamic debug in drm-debug
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] [PATCH v9 06/10] drm_print: add choice to use dynamic debug in drm-debug

[Jim Cromie]

drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names).  There are thousands of these callsites, each
categorized in this systematized way.

These callsites can be enabled at runtime by their category, each
controlled by a bit in drm.debug (/sys/modules/drm/parameter/debug).
In the current "basic" implementation, drm_debug_enabled() tests these
bits in __drm_debug each time an API[1] call is executed; while cheap
individually, the costs accumulate with uptime.

This patch uses dynamic-debug with (required) jump-label to patch
enabled calls onto their respective NOOP slots, avoiding all runtime
bit-checks of __drm_debug by drm_debug_enabled().

Dynamic debug has no concept of category, but we can emulate one by
replacing enum categories with a set of prefix-strings; "drm:core:",
"drm:kms:" "drm:driver:" etc, and prepend them (at compile time) to
the given formats.

Then we can use:
  `echo module drm format "^drm:core: " +p > control`

to enable the whole category with one query.

This conversion yields many new prdbg callsites:

  dyndbg: 207 debug prints in module drm_kms_helper
  dyndbg: 376 debug prints in module drm
  dyndbg: 1811 debug prints in module i915
  dyndbg: 3917 debug prints in module amdgpu

Each site costs 56 bytes of .data, which is a big increase for
drm modules, so CONFIG_DRM_USE_DYNAMIC_DEBUG makes it optional.

CONFIG_JUMP_LABEL is also required, to get the promised optimizations.

The "basic" -> "dyndbg" switchover is layered into the macro scheme

A. A "prefix" version of DRM_UT_ map, named DRM_DBG_CAT_

"basic":  DRM_DBG_CAT_  <===  DRM_UT_.  Identity map.
"dyndbg":
   #define DRM_DBG_CAT_KMS"drm:kms: "
   #define DRM_DBG_CAT_PRIME  "drm:prime: "
   #define DRM_DBG_CAT_ATOMIC "drm:atomic: "

DRM_UT_* are preserved, since theyre used elsewhere.  Since the
callback maintains its state in __drm_debug, drm_debug_enabled() will
stay synchronized, and continue to work.  We can address them
separately if they are called enough to be worth fixing.

B. drm_dev_dbg() & drm_debug() are interposed with macros

basic:forward to renamed fn, with args preserved
enabled:  redirect to pr_debug, dev_dbg, with CATEGORY format catenated

This is where drm_debug_enabled() is avoided.  The prefix is prepended
at compile-time, no category at runtime.

C. API[1] uses DRM_DBG_CAT_s

The API already uses B, now it uses A too, instead of DRM_UT_, to
get the correct token type for "basic" and "dyndbg" configs.

D. use DEFINE_DYNAMIC_DEBUG_CATEGORIES()

This defines the map using DRM_CAT_s, and creates the /sysfs
bitmap to control those categories.

CONFIG_DRM_USE_DYNAMIC_DEBUG is also used to adjust amdgpu, i915
makefiles to add -DDYNAMIC_DEBUG_MODULE; it includes the current
CONFIG_DYNAMIC_DEBUG_CORE and is enabled by the user.

LIMITATIONS:

dev_dbg(etal) effectively prepends twice, category then driver-name,
yielding format strings like so:

bash-5.1# grep amdgpu: /proc/dynamic_debug/control | grep drm: | cut -d= -f2-
_ "amdgpu: drm:core: fence driver on ring %s use gpu addr 0x%016llx\012"
_ "amdgpu: drm:kms: Cannot create framebuffer from imported dma_buf\012"

This means we cannot use anchored "^drm:kms: " to specify the
category, a small loss of precision.

Note that searching on "format ^amdgpu: " works, but this is less
valuable, because the same can be done with "module amdgpu".

NOTES:

Because the dyndbg callback is keeping state in __drm_debug, it
synchronizes with drm_debug_enabled() and its remaining users; the
switchover should be transparent.

Code Review is expected to catch the lack of correspondence between
bit=>prefix definitions (the selector) and the prefixes used in the
API[1] layer above pr_debug()

I've coded the categories with trailing spaces.  This excludes any
sub-categories which might get added later.  This convention protects
any "drm:atomic:fail:" callsites from getting stomped on by `echo 0 >
debug`.  Other categories could differ, but we need some default.

Dyndbg requires that the prefix be in the compiled-in format string;
run-time prefixing evades callsite selection by category.

pr_debug("%s: ...", __func__, ...) // not ideal

Unfortunately __func__ is not a macro, and cannot be catenated at
preprocess/compile time.

If you want that, you might consider +mfl flags instead;)

Signed-off-by: Jim Cromie 
---
v5:
. use DEFINE_DYNAMIC_DEBUG_CATEGORIES in drm_print.c
. s/DRM_DBG_CLASS_/DRM_DBG_CAT_/ - dont need another term
. default=y in Kconfig entry - per @DanVet
. move some commit-log prose to dyndbg commit
. add-prototyes to (param_get/set)_dyndbg
. more wrinkles found by 
. relocate ratelimit chunk from elsewhere
v6:
. add kernel doc
. fix cpp paste, drop '#'
v7:
. change __drm_debug to long, to fit with DEFINE_DYNAMIC_DEBUG_CATEGORIES
. add -DDYNAMIC_DEBUG_MODULE to ccflags if DRM_USE_DYNAMIC_DEBUG
v8:
. adapt to altered ^ insertion
. add mem cost numbe

[Intel-gfx] [PATCH v9 07/10] drm_print: instrument drm_debug_enabled

[Jim Cromie]

Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches.  Then add a pr_debug("todo: ...") into the "dyndbg"
branch.

Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabled() itself.

This gives us unique callsite info for the 8 remaining users of
drm_debug_enabled(), and lets us enable them individually to see how
much logging traffic they generate.  The oft-visited callsites can
then be reviewed for runtime cost and possible optimizations.

Heres what we get:

bash-5.1# modprobe drm
dyndbg: 384 debug prints in module drm
bash-5.1# grep todo: /proc/dynamic_debug/control
drivers/gpu/drm/drm_edid.c:1843 [drm]connector_bad_edid =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_print.c:309 [drm]___drm_dbg =p "todo: maybe avoid via 
dyndbg\012"
drivers/gpu/drm/drm_print.c:286 [drm]__drm_dev_dbg =p "todo: maybe avoid via 
dyndbg\012"
drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:787 
[drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid 
via dyndbg\012"
drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: 
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_atomic_uapi.c:1457 [drm]drm_mode_atomic_ioctl =_ "todo: 
maybe avoid via dyndbg\012"
drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via 
dyndbg\012"

At quick glance, edid won't qualify, drm_print might, drm_vblank is
strongest chance, maybe atomic-ioctl too.

Signed-off-by: Jim Cromie 
---
---
 include/drm/drm_print.h | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index cc853314f44a..36373a91c9e0 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -381,6 +381,11 @@ enum drm_debug_category {
 #define DRM_DBG_CAT_DP DRM_UT_DP
 #define DRM_DBG_CAT_DRMRES DRM_UT_DRMRES
 
+static inline bool drm_debug_enabled(enum drm_debug_category category)
+{
+   return unlikely(__drm_debug & category);
+}
+
 #else /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
 
 /* join prefix + format in cpp so dyndbg can see it */
@@ -414,12 +419,13 @@ enum drm_debug_category {
 #define DRM_DBG_CAT_DP "drm:dp: "
 #define DRM_DBG_CAT_DRMRES "drm:res: "
 
-#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
+#define drm_debug_enabled(category)\
+   ({  \
+   pr_debug("todo: maybe avoid via dyndbg\n"); \
+   unlikely(__drm_debug & (category)); \
+   })
 
-static inline bool drm_debug_enabled(enum drm_debug_category category)
-{
-   return unlikely(__drm_debug & category);
-}
+#endif /* CONFIG_DRM_USE_DYNAMIC_DEBUG */
 
 /*
  * struct device based logging
@@ -569,7 +575,6 @@ void __drm_dev_dbg(const struct device *dev, enum 
drm_debug_category category,
 #define drm_dbg_drmres(drm, fmt, ...)  \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_DBG_CAT_DRMRES, fmt, 
##__VA_ARGS__)
 
-
 /*
  * printk based logging
  *
-- 
2.31.1

[Intel-gfx] [PATCH v9 09/10] dyndbg: create DEFINE_DYNAMIC_DEBUG_TRACE_CATEGORIES

[Jim Cromie]

clone DEFINE_DYNAMIC_DEBUG_CATEGORIES interface to enable pr_debug
output to tracefs.

Extend DEFINE_DYNAMIC_DEBUG_CATEGORIES to work for tracing, by
renaming it (with _FLAGS suffix), adding _flags param, and using it
2x; in original and new names, with "p" and "T" flags respectively.

TODO: rethink this, consider combined trace/debug declaration.
good: single bitmap-spec for both trace,debug, no chance of divergence.
bad: arg-type & count checks are hard, and bitmap follows too!

to combine both, we need 4 args:
  sysfs_debug_name, __debug_var
  sysfs_trace_name, __trace_var // these may be NULL, IFF !CONFIG_TRACE ??
then a bitmap:
  [0] = { "category1" }, ...)

My BUILD_BUG-fu is insufficient to protect a naive macro.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 19 ++-
 lib/dynamic_debug.c   |  4 ++--
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 896848f546e6..f273ba82cbb0 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -254,11 +254,20 @@ struct dyndbg_bitdesc {
 
 struct dyndbg_bitmap_param {
unsigned long *bits;/* ref to shared state */
+   const char *flags;
struct dyndbg_bitdesc map[];/* indexed by bitpos */
 };
 
 #if defined(CONFIG_DYNAMIC_DEBUG) || \
(defined(CONFIG_DYNAMIC_DEBUG_CORE) && defined(DYNAMIC_DEBUG_MODULE))
+
+#define DEFINE_DYNAMIC_DEBUG_CATEGORIES_FLAGS(fsname, _var, _flags, desc, ...) 
\
+   MODULE_PARM_DESC(fsname, desc); \
+   static struct dyndbg_bitmap_param ddcats_##_var =   \
+   { .bits = &(_var), .flags = (_flags),   \
+ .map = { __VA_ARGS__, { .match = NULL }}};\
+   module_param_cb(fsname, ¶m_ops_dyndbg, &ddcats_##_var, 0644)
+
 /**
  * DEFINE_DYNAMIC_DEBUG_CATEGORIES() - bitmap control of categorized pr_debugs
  * @fsname: parameter basename under /sys
@@ -271,11 +280,11 @@ struct dyndbg_bitmap_param {
  * modules calling pr_debugs to control them in groups according to
  * those prefixes, and map them to bits 0-N of a sysfs control point.
  */
-#define DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, _var, desc, ...)   \
-   MODULE_PARM_DESC(fsname, desc); \
-   static struct dyndbg_bitmap_param ddcats_##_var =   \
-   { .bits = &(_var), .map = { __VA_ARGS__, { .match = NULL }}};   \
-   module_param_cb(fsname, ¶m_ops_dyndbg, &ddcats_##_var, 0644)
+#define DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, _var, desc, ...) \
+   DEFINE_DYNAMIC_DEBUG_CATEGORIES_FLAGS(fsname, _var, "p", desc, 
##__VA_ARGS__)
+
+#define DEFINE_DYNAMIC_DEBUG_TRACE_CATEGORIES(fsname, _var, desc, ...) \
+   DEFINE_DYNAMIC_DEBUG_CATEGORIES_FLAGS(fsname, _var, "T", desc, 
##__VA_ARGS__)
 
 extern const struct kernel_param_ops param_ops_dyndbg;
 
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index f19465b114cd..b4146178780f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -629,8 +629,8 @@ int param_set_dyndbg(const char *instr, const struct 
kernel_param *kp)
for (i = 0; map->match && i < BITS_PER_LONG; map++, i++) {
if (test_bit(i, &inbits) == test_bit(i, p->bits))
continue;
-   snprintf(query, FMT_QUERY_SIZE, "format '%s' %cp", map->match,
-test_bit(i, &inbits) ? '+' : '-');
+   snprintf(query, FMT_QUERY_SIZE, "format '%s' %c%s", map->match,
+test_bit(i, &inbits) ? '+' : '-', p->flags);
 
matches = ddebug_exec_queries(query, KP_MOD_NAME);
 
-- 
2.31.1

[Intel-gfx] [PATCH v9 10/10] drm: use DEFINE_DYNAMIC_DEBUG_TRACE_CATEGORIES bitmap to tracefs

[Jim Cromie]

Use new macro to create a sysfs control bitmap knob to control
print-to-trace in: /sys/module/drm/parameters/trace

todo: reconsider this api, ie a single macro expecting both debug &
trace terms (2 each), followed by a single description and the
bitmap-spec::

Good: declares bitmap once for both interfaces

Bad: arg-type/count handling (expecting 4 args) is ugly,
 especially preceding the bitmap-init var-args.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index ce662d0f339b..7b49fbc5e21d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -73,6 +73,25 @@ DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug, __drm_debug,
[7] = { DRM_DBG_CAT_LEASE },
[8] = { DRM_DBG_CAT_DP },
[9] = { DRM_DBG_CAT_DRMRES });
+
+#ifdef CONFIG_TRACING
+unsigned long __drm_trace;
+EXPORT_SYMBOL(__drm_trace);
+DEFINE_DYNAMIC_DEBUG_TRACE_CATEGORIES(trace, __drm_trace,
+ DRM_DEBUG_DESC,
+ [0] = { DRM_DBG_CAT_CORE },
+ [1] = { DRM_DBG_CAT_DRIVER },
+ [2] = { DRM_DBG_CAT_KMS },
+ [3] = { DRM_DBG_CAT_PRIME },
+ [4] = { DRM_DBG_CAT_ATOMIC },
+ [5] = { DRM_DBG_CAT_VBL },
+ [6] = { DRM_DBG_CAT_STATE },
+ [7] = { DRM_DBG_CAT_LEASE },
+ [8] = { DRM_DBG_CAT_DP },
+ [9] = { DRM_DBG_CAT_DRMRES });
+
+struct trace_array *trace_arr;
+#endif
 #endif
 
 void __drm_puts_coredump(struct drm_printer *p, const char *str)
-- 
2.31.1

[Intel-gfx] [PATCH v9 02/10] drm: fix doc grammar

[Jim Cromie]

allocates and initializes ...

Signed-off-by: Jim Cromie 
---
 include/drm/drm_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0cd95953cdf5..4b29261c4537 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -486,7 +486,7 @@ void *__devm_drm_dev_alloc(struct device *parent,
  * @type: the type of the struct which contains struct &drm_device
  * @member: the name of the &drm_device within @type.
  *
- * This allocates and initialize a new DRM device. No device registration is 
done.
+ * This allocates and initializes a new DRM device. No device registration is 
done.
  * Call drm_dev_register() to advertice the device to user space and register 
it
  * with other core subsystems. This should be done last in the device
  * initialization sequence to make sure userspace can't access an inconsistent
-- 
2.31.1

[Intel-gfx] [PATCH v9 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

[Jim Cromie]

Sean Paul proposed, in:
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs

His patchset's objective is to be able to independently steer some of
the drm.debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() into syslog & trace flavors, and enabling them
separately.  2 advantages were identified:

1- syslog is heavyweight, tracefs is much lighter
2- separate selection of enabled categories means less traffic

Dynamic-Debug can do 2nd exceedingly well:

A- all work is behind jump-label's NOOP, zero off cost.
B- exact site selectivity, precisely the useful traffic.
   can tailor enabled set interactively, at shell.

Since the tracefs interface is effective for drm (the threads suggest
so), adding that interface to dynamic-debug has real potential for
everyone including drm.

if CONFIG_TRACING:

Grab Sean's trace_init/cleanup code, use it to provide tracefs
available by default to all pr_debugs.  This will likely need some
further per-module treatment; perhaps something reflecting hierarchy
of module,file,function,line, maybe with a tuned flattening.

endif CONFIG_TRACING

Add a new +T flag to enable tracing, independent of +p, and add and
use 3 macros: dyndbg_site_is_enabled/logging/tracing(), to encapsulate
the flag checks.  Existing code treats T like other flags.

Add ddebug_validate_flags() as last step in ddebug_parse_flags().  Its
only job is to fail on +T for non-CONFIG_TRACING builds.  It only sees
the new flags, and cannot validate specific state transitions.  This
is fine, since we have no need for that; such a test would have to be
done in ddebug_change(), which actually updates the callsites.

ddebug_change() adjusts the static-key-enable/disable condition to use
_DPRINTK_ENABLED / abstraction macros.

dynamic_emit_prefix() now gates on _DPRINTK_ENABLED too, as an
optimization but mostly to allow decluttering of its users.

__dynamic_pr_debug() etal get minor changes:

 - call dynamic_emit_prefix() 1st, _enabled() optimizes.
 - if (T) call trace_array_printk
 - if (!p) go around original printk code.
   done to minimize diff,
   goto-ectomy + reindent later/separately
 - share vaf across p|T

WRT _dev, I skipped all the  specific dev_emit_prefix
additions for now.  tracefs is a fast customer with different needs,
its not clear that pretty device-ID-ish strings is useful tracefs
content (on ingest), or that couldn't be done more efficiently while
analysing or postprocesing the tracefs buffer.

SELFTEST: test_dynamic_debug.ko:

Uses the tracer facility to implement a kernel module selftest.

TODO:

Earlier core code had (tracerfn)() indirection, allowing a plugin
side-effector we could test the results of.

ATM all the tests which count +T'd callsite executions (and which
expect >0) are failing.

Now it needs a rethink to test from userspace, rather than the current
test-once at module-load.  It needs a parameters/testme button.

So remainder of this is a bit stale 

- A custom tracer counts the number of calls (of T-enabled pr_debugs),
- do_debugging(x) calls a set of categorized pr_debugs x times

- test registers the tracer on the module
  then iteratively:
  manipulates dyndbg states via query-cmds, mostly format ^prefix
  runs do_debugging()
  counts enabled callsite executions
  reports mismatches

- modprobe test_dynamic_debug use_bad_tracer=1
  attaches a bad/recursive tracer
  Bad Things (did) Happen.
  has thrown me interesting panics.
  cannot replicate atm.

RFC: (DONE)

The "tracer" interface probably needs work and a new name.  It is only
1/2 way towards a real tracefs interface; and the code I lifted from
Sean Paul in the next patch could be implemented in dynamic_debug.c
instead, and made available for all pr_debug users.

This would also eliminate need for dynamic_debug_(un)register_tracer(),
since dyndbg could just provide it when TRACING is on.

NOTES:

$> modprobe test_dynamic_debug dyndbg=+p

   it fails 3/29 tests. havent looked at why.

$> modprobe test_dynamic_debug use_bad_tracer=1

Earlier in dev, bad_tracer() exploded in recursion, I havent been able
to replicate that lately.

Signed-off-by: Jim Cromie 
---
v4: (rfc)
. fix printk (to syslog) needs if (+p), since +T also enables
. add prototypes for un/register_aux_print
. change iface names: s/aux_print/tracer/
. also s/trace_print/tracer/
. struct va_format *vaf - tighten further ?

v5: (rfc)
. fix "too many arguments to function", and name the args:
  int (*aux_print)(const char *fmt, char *prefix, char *label, void *);
   prefix : is a slot for dynamic_emit_prefix, or for custom buffer insert
   label  : for builtin-caller used by drm-trace-print
   void*  : vaf, add type constraint later.

v6: (rfc)
. more test in test module
. add mod arg to *register, following exec_queries pattern
. move code
. move kdoc to c from h

v7: (rfc)
. simplify tracer prototype (probably needs more tailoring)
. separate from dd-exec-queries
. drop struct _ddebug.tra

[Intel-gfx] [PATCH v9 01/10] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES macro and callbacks

[Jim Cromie]

DEFINE_DYNAMIC_DEBUG_CATEGORIES(fsname, var, bitmap_desc, @bit_descs)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a pr_debug "category".

Unlike drm, dyndbg has no coding of "category", but it can select a
set of pr_debugs with a substr match on their formats.  Since many
pr_debug users have systematized format prefixes, dyndbg can
en/disable those existing groupings as sets/categories.

Those categories can (already) be manipulated like so:

echo "format $category +p" >control

This macro merely maps the categories to bits of a sysfs interface, by
wiring the callbacks to it.

DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"i915/gvt bitmap desc",
/* map each bit to a format match string */
[0] = { "gvt:cmd:" },
[1] = { "gvt:core:" },
[2] = { "gvt:dpy:" },
[3] = { "gvt:el:" },
[4] = { "gvt:irq:" },
[5] = { "gvt:mm:" },
[6] = { "gvt:mmio:" },
[7] = { "gvt:render:" },
[8] = { "gvt:sched:" });

 - int param_set_dyndbg()
 - int param_get_dyndbg()
 - struct kernel_param_ops param_ops_dyndbg

Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
non-static and exported.

get/set use an augmented kernel_param; the arg refs a new struct
dyndbg_bitmap_param containing:

A- the map of "categories", an array of struct dyndbg_bitdescs,
   indexed by bitpos, defining the match against pr_debug formats.

B- a pointer to the user module's ulong holding the bits/state.
   By sharing state, we coordinate with code that still uses it
   directly.  This allows drm-debug api to be converted incrementally,
   while still using __drm_debug & drm_debug_enabled() in other parts.

param_set_dyndbg() compares new vs old bits, and only updates prdbgs
on changes.  This maximally preserves the underlying state, which may
have been customized via later `echo $cmd >control`.  So if a user
really wants to know that all prdbgs are set precisely, they must
pre-clear then set.

dynamic_debug.h:

Add DEFINE_DYNAMIC_DEBUG_CATEGORIES() described above, and a stub
throwing a BUILD_BUG (RFC) when used without DYNAMIC_DEBUG support.

Add structs dyndbg_bitdesc, dyndbg_bitmap_param to support the main
macro, and several helper macros wrapping the given categories with
^prefix and ' ' suffix.  This way the callback can be more broadly
used, by using the right helper macro.

Also externs the struct kernel_param param_ops_dyndbg symbol, as is
done in moduleparams.h for all the STANDARD params.

USAGE NOTES:

Using dyndbg to query on "format $str" requires that $str must be
present in the compiled-in format string.  Searching on "%s" does not
define a useful set of callsites.

Using DEFINE_DYNAMIC_DEBUG_CATEGORIES wo support gets a BUILD_BUG.
ISTM there is already action at a declarative distance, nobody needs
mystery as to why the /sysfs thingy didn't appear.

Dyndbg is agnostic wrt the categorization scheme used, in order to
play well with any prefix convention already in use in the codebase.
In fact, "prefix" is not strictly accurate without ^ anchor.

Ad-hoc categories and sub-categories are implicitly allowed, author
discipline and review is expected.

Hierarchical classes/categories are natural:

"^drm::"   is used in a later commit
"^drm:::" is a natural extension.
"^drm:atomic:fail:" has been proposed, sounds directly useful

RFC: in a real sense we abandon enum strictures here, and lose some
compiler help, on spelling errs for example.  Obviously "drm:" != "DRM:".

Some properties of a hierarchical category deserve explication:

Trailing spaces matter !

With 1..3-space ("drm: ", "drm:atomic: ", "drm:atomic:fail: "), the
":" doesn't terminate the search-space, the trailing space does.  So a
"drm:" search spec will match all DRM categories & subcategories, and
will not be useful in an interface where all categories are already
controlled together.  That said, "drm:atomic:" & "drm:atomic: " are
different, and both are useful in cases.

Ad-Hoc categories & sub-categories:

Ad-hoc categories are those format-prefixes already in use; both
amdgpu and i915 have numerous (120,~1800) pr_debugs, most of these use
a system, a small set (9,13) of prefixes, to categorize the output.
Dyndbg already works on these, this patch just allows adding a new
bitmap knob to control them.

Ad-hoc sub-categories are slightly trickier.
  since drm_dbg_atomic("fail: ...") is a macro:
pr_debug("drm:atomic:" " " format,...) // cpp-paste in a trailing space

We get "drm:atomic: fail:", with that undesirable embedded space;
obviously not ideal wrt clear and simple prefixes.

a possible fix: drm_dbg_atomic_("fail: ..."); // trailing _ for ad-hoc subcat

Summarizing:

 - "drm:kms: " & "drm:kms:" are different
 - "drm:kms"also different - includes drm:kms2:
 - "drm:kms:\t" also different - could be troublesome
 - "drm:kms:*"  doesn't work, no wildcard on format atm.

Order 

[Intel-gfx] [PATCH v9 03/10] amdgpu: use dyndbg.CATEGORIES to control existing pr_dbgs

[Jim Cromie]

logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching [:uppercase:]

Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a sysfs location which
maps from bits to these 13 sets of categorized pr_debugs to en/disable.

Makefile adds -DDYNAMIC_DEBUG_MODULE for CONFIG_DYNAMIC_DEBUG_CORE,
otherwise BUILD_BUG_ON triggers (obvious errors on subtle misuse is
better than mysterious ones).

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/Makefile   |  2 +
 .../gpu/drm/amd/display/dc/core/dc_debug.c| 44 ++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 8d0748184a14..26d974edd5c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -38,6 +38,8 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_DISPLAY_PATH)/amdgpu_dm \
-I$(FULL_AMD_PATH)/amdkfd
 
+ccflags-$(CONFIG_DYNAMIC_DEBUG_CORE) += -DYNAMIC_DEBUG_MODULE
+
 amdgpu-y := amdgpu_drv.o
 
 # add KMS driver
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
index 21be2a684393..f08d9cf6c4b3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_debug.c
@@ -36,8 +36,50 @@
 
 #include "resource.h"
 
-#define DC_LOGGER_INIT(logger)
+#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
+/* define a drm.debug style dyndbg pr-debug control point */
+#include 
+
+unsigned long __debug_dc;
+EXPORT_SYMBOL(__debug_dc);
+
+#define help_(_N, _cat)"\t  Bit-" #_N "\t" _cat "\n"
+
+#define DC_DYNDBG_BITMAP_DESC(name)\
+   "Control pr_debugs via /sys/module/amdgpu/parameters/" #name\
+   ", where each bit controls a debug category.\n" \
+   help_(0, "[SURFACE]:")  \
+   help_(1, "[CURSOR]:")   \
+   help_(2, "[PFLIP]:")\
+   help_(3, "[VBLANK]:")   \
+   help_(4, "[HW_LINK_TRAINING]:") \
+   help_(5, "[HW_AUDIO]:") \
+   help_(6, "[SCALER]:")   \
+   help_(7, "[BIOS]:") \
+   help_(8, "[BANDWIDTH_CALCS]:")  \
+   help_(9, "[DML]:")  \
+   help_(10, "[IF_TRACE]:")\
+   help_(11, "[GAMMA]:")   \
+   help_(12, "[SMU_MSG]:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_dc, __debug_dc,
+   DC_DYNDBG_BITMAP_DESC(debug_dc),
+   [0] = { "[CURSOR]:" },
+   [1] = { "[PFLIP]:" },
+   [2] = { "[VBLANK]:" },
+   [3] = { "[HW_LINK_TRAINING]:" },
+   [4] = { "[HW_AUDIO]:" },
+   [5] = { "[SCALER]:" },
+   [6] = { "[BIOS]:" },
+   [7] = { "[BANDWIDTH_CALCS]:" },
+   [8] = { "[DML]:" },
+   [9] = { "[IF_TRACE]:" },
+   [10] = { "[GAMMA]:" },
+   [11] = { "[SMU_MSG]:" });
+
+#endif
 
+#define DC_LOGGER_INIT(logger)
 
 #define SURFACE_TRACE(...) do {\
if (dc->debug.surface_trace) \
-- 
2.31.1

[Intel-gfx] [PATCH v9 04/10] i915/gvt: trim spaces from pr_debug "gvt: core:" prefixes

[Jim Cromie]

Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the extra quoting needed otherwise:

  $> echo format "^gvt: core:" +p >control

Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.

Consider a generic drm-debug example:

  # turn off ATOMIC reports
  echo format "^drm:atomic: " -p > control

  # turn off all ATOMIC:* reports, including any sub-categories
  echo format "^drm:atomic:" -p > control

  # turn on ATOMIC:FAIL: reports
  echo format "^drm:atomic:fail: " +p > control

Removing embedded spaces in the class-prefixes simplifies the
corresponding match-prefix.  This means that "quoted" match-prefixes
are only needed when the trailing space is desired, in order to
exclude explicitly sub-categorized pr-debugs; in this example,
"drm:atomic:fail:".

Signed-off-by: Jim Cromie 
---
v8:
. fix patchwork CI warning
---
 drivers/gpu/drm/i915/gvt/debug.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..bbecc279e077 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -36,30 +36,30 @@ do {
\
 } while (0)
 
 #define gvt_dbg_core(fmt, args...) \
-   pr_debug("gvt: core: "fmt, ##args)
+   pr_debug("gvt:core: " fmt, ##args)
 
 #define gvt_dbg_irq(fmt, args...) \
-   pr_debug("gvt: irq: "fmt, ##args)
+   pr_debug("gvt:irq: " fmt, ##args)
 
 #define gvt_dbg_mm(fmt, args...) \
-   pr_debug("gvt: mm: "fmt, ##args)
+   pr_debug("gvt:mm: " fmt, ##args)
 
 #define gvt_dbg_mmio(fmt, args...) \
-   pr_debug("gvt: mmio: "fmt, ##args)
+   pr_debug("gvt:mmio: " fmt, ##args)
 
 #define gvt_dbg_dpy(fmt, args...) \
-   pr_debug("gvt: dpy: "fmt, ##args)
+   pr_debug("gvt:dpy: " fmt, ##args)
 
 #define gvt_dbg_el(fmt, args...) \
-   pr_debug("gvt: el: "fmt, ##args)
+   pr_debug("gvt:el: " fmt, ##args)
 
 #define gvt_dbg_sched(fmt, args...) \
-   pr_debug("gvt: sched: "fmt, ##args)
+   pr_debug("gvt:sched: " fmt, ##args)
 
 #define gvt_dbg_render(fmt, args...) \
-   pr_debug("gvt: render: "fmt, ##args)
+   pr_debug("gvt:render: " fmt, ##args)
 
 #define gvt_dbg_cmd(fmt, args...) \
-   pr_debug("gvt: cmd: "fmt, ##args)
+   pr_debug("gvt:cmd: " fmt, ##args)
 
 #endif
-- 
2.31.1

[Intel-gfx] [PATCH v9 05/10] i915/gvt: use dyndbg.CATEGORIES for existing pr_debugs

[Jim Cromie]

The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM.  Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.

DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
[0] = { "gvt:cmd:" },
[1] = { "gvt:core:" },
[2] = { "gvt:dpy:" },
[3] = { "gvt:el:" },
[4] = { "gvt:irq:" },
[5] = { "gvt:mm:" },
[6] = { "gvt:mmio:" },
[7] = { "gvt:render:" },
[8] = { "gvt:sched:" });

If CONFIG_DYNAMIC_DEBUG_CORE=y, then gvt/Makefile adds
-DDYNAMIC_DEBUG_MODULE to cflags, which CONFIG_DYNAMIC_DEBUG=n
(CORE-only) builds need.  This is redone more comprehensively soon.

Signed-off-by: Jim Cromie 
---
v5:
. static decl of vector of bit->class descriptors - Emil.V
. relocate gvt-makefile chunk from elsewhere

v7:
. move ccflags addition up to i915/Makefile from i915/gvt

v8:
. relocate DDD_CAT decl code into intel_gvt.c - Tvrtko
  cflags back to i915/Makefile
. add -DDYNAMIC_DEBUG_MODULE to support DYNAMIC_DEBUG_CORE-only builds

heres unchanged? footprint:

bash-5.1# for m in i915 amdgpu nouveau; do modprobe $m; done
dyndbg:   1 debug prints in module drm
dyndbg:   2 debug prints in module ttm
dyndbg:   8 debug prints in module video
dyndbg: 167 debug prints in module i915
dyndbg: 2339 debug prints in module amdgpu
[drm] amdgpu kernel modesetting enabled.
amdgpu: CRAT table disabled by module option
amdgpu: Virtual CRAT table created for CPU
amdgpu: Topology: Add CPU node
dyndbg:   3 debug prints in module wmi
dyndbg:   3 debug prints in module nouveau
---
 drivers/gpu/drm/i915/Makefile|  2 ++
 drivers/gpu/drm/i915/intel_gvt.c | 34 
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 335ba9f43d8f..a313e8a539f6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -301,6 +301,8 @@ i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
 endif
 
+ccflags-$(CONFIG_DYNAMIC_DEBUG_CORE) += -DDYNAMIC_DEBUG_MODULE
+
 obj-$(CONFIG_DRM_I915) += i915.o
 obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
 
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 4e70c1a9ef2e..e53b41fa15e0 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -162,3 +162,37 @@ void intel_gvt_resume(struct drm_i915_private *dev_priv)
if (intel_gvt_active(dev_priv))
intel_gvt_pm_resume(dev_priv->gvt);
 }
+
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+
+unsigned long __gvt_debug;
+EXPORT_SYMBOL(__gvt_debug);
+
+#define help_(_N, _cat)"\t  Bit-" #_N ":\t" _cat "\n"
+
+#define I915_GVT_CATEGORIES(name) \
+   " Enable debug output via /sys/module/i915/parameters/" #name   \
+   ", where each bit enables a debug category.\n"  \
+   help_(0, "gvt:cmd:")\
+   help_(1, "gvt:core:")   \
+   help_(2, "gvt:dpy:")\
+   help_(3, "gvt:el:") \
+   help_(4, "gvt:irq:")\
+   help_(5, "gvt:mm:") \
+   help_(6, "gvt:mmio:")   \
+   help_(7, "gvt:render:") \
+   help_(8, "gvt:sched:")
+
+DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
+   I915_GVT_CATEGORIES(debug_gvt),
+   [0] = { "gvt:cmd:" },
+   [1] = { "gvt:core:" },
+   [2] = { "gvt:dpy:" },
+   [3] = { "gvt:el:" },
+   [4] = { "gvt:irq:" },
+   [5] = { "gvt:mm:" },
+   [6] = { "gvt:mmio:" },
+   [7] = { "gvt:render:" },
+   [8] = { "gvt:sched:" });
+
+#endif
-- 
2.31.1

[Intel-gfx] [PATCH v9 00/10] use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace

[Jim Cromie]

This patchset has 3 separate but related parts:

1. DEFINE_DYNAMIC_DEBUG_CATEGORIES [patch 1/10]

   Declares DRM.debug style bitmap, bits control pr_debugs by matching formats
   Adds callback to translate bits to $cmd > dynamic_debug/control
   This could obsolete EXPORT(dynamic_debug_exec_queries) not included.

   anticipated_usage:
   DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug, __drm_debug,
" bits control drm.debug categories ",
[0] = { DRM_DBG_CAT_CORE },
[1] = { DRM_DBG_CAT_DRIVER },
[2] = { DRM_DBG_CAT_KMS },
[3] = { DRM_DBG_CAT_PRIME }, ...);

2. use (1) to reimplement drm.debug [patches 3-7]::

   1st in amdgpu & i915 to control existing pr_debugs by their formats
   then in drm-print, for all drm.debug API users
   avoids drm_debug_enabled(), gives NOOP savings & new flexibility.
   changes drm.debug categories from enum to format-prefix-string
   alters log format to include the format-prefix-string
   Daniel Vetter liked this at -v3
   https://lore.kernel.org/lkml/YPbPvm%2FxcBlTK1wq@phenom.ffwll.local/
   Im sure Ive missed stuff.
   
3. separately, Sean Paul proposed drm.trace to mirror drm.debug to tracefs
   https://patchwork.freedesktop.org/series/78133/ ::

   He argues::
 tracefs is fast/lightweight compared to syslog
 independent selection means tailored traffic for both

ISTM he's correct. So it follows that its also good for dyndbg, where
its then available for all pr_debug users (if CONFIG_TRACING).

So basically, I borg'd his::
   [patch 14/14] drm/print: Add tracefs support to the drm logging helpers
   
Then I added a T flag, so anyone can enable it::

   # turn on all drm's pr_debug --> tracefs
   echo module drm +T > /proc/dynamic_debug/control

It appears to just work: (RFC)

The instance name is purposely crappy, to force a revisit later, maybe
"pr_debugs" (plural).  Per-module subdirs kinda fits the tracefs
pattern, but ./dyndbg-tracefs/$module/$file/$function/$line seems a
little like overkill.  RFC.

[root@gandalf dyndbg-tracefs]# pwd
/sys/kernel/tracing/instances/dyndbg-tracefs
[root@gandalf dyndbg-tracefs]# echo 1 > /sys/module/drm/parameters/trace
[root@gandalf dyndbg-tracefs]# head -n16 trace | sed -e 's/^#//'
 tracer: nop

 entries-in-buffer/entries-written: 405/405   #P:24

_-=> irqs-off
   / _=> need-resched
  | / _---=> hardirq/softirq
  || / _--=> preempt-depth
  ||| / _-=> migrate-disable
   / delay
   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
  | | |   | | |
   <...>-2254[000] .  7040.894352: __dynamic_pr_debug: 
drm:core: comm="gnome-shel:cs0" pid=2254, dev=0xe200, auth=1, AMDGPU_CS
   <...>-2207[015] .  7040.894654: __dynamic_pr_debug: 
drm:core: comm="gnome-shell" pid=2207, dev=0xe200, auth=1, DRM_IOCTL_MODE_ADDFB2
   <...>-2207[015] .  7040.995403: __dynamic_pr_debug: 
drm:core: comm="gnome-shell" pid=2207, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
   <...>-2207[015] .  7040.995413: __dynamic_pr_debug: 
drm:core: OBJ ID: 121 (2)

This is the pr-debug doing most of that logging: (from dynamic_debug/control)

  drivers/gpu/drm/drm_ioctl.c:866 [drm]drm_ioctl =T "drm:core: comm=\042%s\042 
pid=%d, dev=0x%lx, auth=%d, %s\012"

Turning on decoration flags changes the trace:

  echo module drm format drm:core: +mflt > /proc/dynamic_debug/control 

   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
  | | |   | | |
   <...>-2254[003] . 15980.936660: __dynamic_pr_debug: [2254] 
drm:drm_ioctl:866: drm:core: comm="gnome-shel:cs0" pid=2254, dev=0xe200, 
auth=1, AMDGPU_CS
   <...>-2207[015] . 15980.936966: __dynamic_pr_debug: [2207] 
drm:drm_ioctl:866: drm:core: comm="gnome-shell" pid=2207, dev=0xe200, auth=1, 
DRM_IOCTL_MODE_ADDFB2
   <...>-2207[015] . 15981.037727: __dynamic_pr_debug: [2207] 
drm:drm_ioctl:866: drm:core: comm="gnome-shell" pid=2207, dev=0xe200, auth=1, 
DRM_IOCTL_MODE_RMFB
   <...>-2207[015] . 15981.037739: __dynamic_pr_debug: [2207] 
drm:drm_mode_object_put:195: drm:core: OBJ ID: 124 (2)
   <...>-2207[015] . 15981.037742: __dynamic_pr_debug: [2207] 
drm:drm_mode_object_put:195: drm:core: OBJ ID: 124 (1)

The FUNCTION could stand tweaking (to match the callsite in the
control file, cited above), or perhaps replaced by the 'mfl'
decorations; the 't' flag is redundant for trace. Meh.

SELFTEST

A previous version of this patchset added test_dynamic_debug.ko, but
it relied upon code I ripped out when I made tracefs available by
default (without modules registering 1st).  So it fails 10

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/pmu: Add a name to the execlists stats

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists 
stats
URL   : https://patchwork.freedesktop.org/series/96324/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10792_full -> Patchwork_21455_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@all-pipes-forked-bo:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb7/igt@kms_cursor_leg...@all-pipes-forked-bo.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-tglb5/igt@kms_cursor_leg...@all-pipes-forked-bo.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_mm@all@insert_range:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#2485])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-skl4/igt@drm_mm@all@insert_range.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-skl3/igt@drm_mm@all@insert_range.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#198])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-skl6/igt@gem_ctx_isolation@preservation...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-skl4/igt@gem_ctx_isolation@preservation...@rcs0.html

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

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-kbl4/igt@gem_exec_fair@basic-none-s...@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_10792/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_suspend@basic-s3:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl3/igt@gem_exec_susp...@basic-s3.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-kbl1/igt@gem_exec_susp...@basic-s3.html

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

  * igt@gem_workarounds@suspend-resume:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#456])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb8/igt@gem_workarou...@suspend-resume.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/shard-tglb7/igt@gem_workarou...@suspend-resume.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-apl3/igt@i915_susp...@debugfs-reader.html
   [22]: 
https://intel-gfx-ci.01.org/tr

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adlp/fb: Remove CCS FB stride restrictions

[Patchwork]

== Series Details ==

Series: drm/i915/adlp/fb: Remove CCS FB stride restrictions
URL   : https://patchwork.freedesktop.org/series/96322/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792_full -> Patchwork_21454_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-iclb: NOTRUN -> [DMESG-WARN][1] ([i915#3002])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-iclb5/igt@gem_cre...@create-massive.html
- shard-snb:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-snb6/igt@gem_cre...@create-massive.html
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#3002])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-kbl6/igt@gem_cre...@create-massive.html
- shard-tglb: NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-tglb7/igt@gem_cre...@create-massive.html
- shard-glk:  NOTRUN -> [DMESG-WARN][5] ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-glk1/igt@gem_cre...@create-massive.html
- shard-skl:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-skl6/igt@gem_cre...@create-massive.html
- shard-apl:  NOTRUN -> [DMESG-WARN][7] ([i915#3002])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-apl8/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +2 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#3063])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb5/igt@gem_...@in-flight-contexts-1us.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html

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

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-kbl4/igt@gem_exec_fair@basic-none-s...@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_10792/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html

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

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2842]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-glk8/igt@gem_exec_fair@basic-p...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-snb:  NOTRUN -> [SKIP][19] ([fdo#109271]) +18 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-snb2/igt@gem_exec_par...@rsvd2-dirt.html
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109283])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-tglb1/igt@gem_exec_par...@rsvd2-dirt.html
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#109283])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-iclb7/igt@gem_exec_par...@rsvd2-dirt.html

  * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#4270])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-iclb1/igt@gem_...@dmabuf-shared-protected-dst-is-context-refcounted.html
- shard-tglb: NOTRUN -> [SKIP][23] ([i915#4270])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/shard-tglb6/igt@gem_...@dmabuf-sha

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/pmu: Add a name to the execlists stats

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists 
stats
URL   : https://patchwork.freedesktop.org/series/96324/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21455


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Additional (1): fi-ilk-650 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-icl-u2 bat-adlp-4 fi-ctg-p8600 
fi-elk-e7500 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][1] ([fdo#109271]) +35 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

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

  * igt@kms_chamelium@dp-hpd-fast:
- fi-ilk-650: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/fi-ilk-650/igt@kms_chamel...@dp-hpd-fast.html

  * igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> [FAIL][5] ([i915#2426] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/fi-bxt-dsi/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][6] ([i915#4290]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21455/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#4290]: https://gitlab.freedesktop.org/drm/intel/issues/4290


Build changes
-

  * Linux: CI_DRM_10792 -> Patchwork_21455

  CI-20190529: 20190529
  CI_DRM_10792: 299777ddcc06c9a0ea7b95a0823ccaca268d16b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21455: 8d0300f5d14fc7a068b618ba28b6eabfb45b294b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8d0300f5d14f drm/i915/pmu: Connect engine busyness stats from GuC to pmu
b27b1a409734 drm/i915/pmu: Add a name to the execlists stats

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Extend PSR2 support in transcoder B

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Extend PSR2 support in transcoder B
URL   : https://patchwork.freedesktop.org/series/96321/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10792_full -> Patchwork_21453_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_spin_batch@user-each:
- shard-skl:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-skl1/igt@gem_spin_ba...@user-each.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-skl2/igt@gem_spin_ba...@user-each.html

  * igt@kms_flip@dpms-vs-vblank-race@a-edp1:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb8/igt@kms_flip@dpms-vs-vblank-r...@a-edp1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-tglb8/igt@kms_flip@dpms-vs-vblank-r...@a-edp1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html

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

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl7/igt@gem_exec_fair@basic-n...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-kbl1/igt@gem_exec_fair@basic-n...@rcs0.html

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

  * igt@gem_exec_fair@basic-sync@rcs0:
- shard-kbl:  [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl4/igt@gem_exec_fair@basic-s...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-kbl4/igt@gem_exec_fair@basic-s...@rcs0.html

  * igt@gem_exec_whisper@basic-queues:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-glk9/igt@gem_exec_whis...@basic-queues.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-glk8/igt@gem_exec_whis...@basic-queues.html

  * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4270])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-iclb7/igt@gem_...@dmabuf-shared-protected-dst-is-context-refcounted.html

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

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#454])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-iclb5/igt@i915_pm...@dc6-psr.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-iclb8/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@media-rc6-accuracy:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109289] / [fdo#111719])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/shard-tglb3/igt@i915_pm_rc6_resid

Re: [Intel-gfx] [PATCH] drm/i915/display/tgl: Implement Wa_14013120569

[Tolakanahalli Pradeep, Madhumitha]

On Mon, 2021-07-05 at 13:28 +0300, Jani Nikula wrote:
> On Tue, 29 Jun 2021, "Souza, Jose"  wrote:
> > On Mon, 2021-06-28 at 16:50 -0700, Madhumitha Tolakanahalli Pradeep
> > wrote:
> > > PCH display HPD IRQ is not detected with default filter value.
> > > So, PP_CONTROL is manually reprogrammed.
> > > 
> > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > madhumitha.tolakanahalli.pradeep at intel.com>
> > > ---
> > >  .../gpu/drm/i915/display/intel_display_power.c   |  8 
> > >  drivers/gpu/drm/i915/display/intel_hotplug.c | 16
> > > 
> > >  2 files changed, 24 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 285380079aab..e44323cc76f5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -6385,8 +6385,16 @@ static void
> > > intel_power_domains_verify_state(struct drm_i915_private *i915)
> > >  
> > >  void intel_display_power_suspend_late(struct drm_i915_private
> > > *i915)
> > >  {
> > > +struct drm_i915_private *dev_priv = i915;
> > > +u32 val;
> > >   if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
> > >   IS_BROXTON(i915)) {
> > > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > > + /* Wa_14013120569:tgl */
> > > + if (IS_TIGERLAKE(i915)) {
> > > + val &= ~PANEL_POWER_ON;
> > > + intel_de_write(dev_priv, PP_CONTROL(0), val);
> > > + }
> > 
> > Code style is all wrong, please fix it and run "dim checkpatch" to
> > validate it before sending patches.
> > Also PP_CONTROL(0) don't point to the same register that the
> > workaround is talking about, between generations register address
> > change that might be
> > the case for this one.
> 
> In general, I've put a bunch of effort into moving most PPS stuff and
> PP_CONTROL reg access into intel_pps.c, not least because you must
> hold
> appropriate locks and power domain references to poke at this. You
> can't
> just mess with it nilly willy. I don't want these abstractions
> bypassed.
> 
> BR,
> Jani.

I see that intel_pps_get_registers(),  populates the regs-
>pp_ctrl  correctly. That is what I would want to access and set the
bits for this W/A. However as is I cannot call pps_get_registers() in
intel_dp or intel_display.c for the external connector  at
connect/disconnect time. Do you recommend making this function non
static and calling it for this W/A or is there a way I can access the
populated i915_reg_t pp_ctrl  to set the W/A?

Or are you wanting to  define another helper for enable/disable of this
W/A in intel_pps.c that would then call pps_init_registers or similar
function ?

- Madhumitha

> 
> > This satisfy the "before going into sleep to allow CS entry" but it
> > do not restore the workaround after waking up from suspend.
> > Also you could improve the code, you are reading the register even
> > for platforms that don't need the wa, also check intel_de_rmw() it
> > is better suited
> > to this case.
> > 
> > >   bxt_enable_dc9(i915);
> > >   /* Tweaked Wa_14010685332:icp,jsp,mcc */
> > >   if (INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> > > INTEL_PCH_TYPE(i915) <= PCH_MCC)
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > index 47c85ac97c87..8e3f84100daf 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > @@ -26,6 +26,7 @@
> > >  #include "i915_drv.h"
> > >  #include "intel_display_types.h"
> > >  #include "intel_hotplug.h"
> > > +#include "intel_de.h"
> > >  
> > >  /**
> > >   * DOC: Hotplug
> > > @@ -266,7 +267,9 @@ intel_encoder_hotplug(struct intel_encoder
> > > *encoder,
> > > struct intel_connector *connector)
> > >  {
> > >   struct drm_device *dev = connector->base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > >   enum drm_connector_status old_status;
> > > + u32 val;
> > >   u64 old_epoch_counter;
> > >   bool ret = false;
> > >  
> > > @@ -288,6 +291,19 @@ intel_encoder_hotplug(struct intel_encoder
> > > *encoder,
> > > drm_get_connector_status_name(connector-
> > > >base.status),
> > > old_epoch_counter,
> > > connector->base.epoch_counter);
> > > +
> > > + /* Wa_14013120569:tgl */
> > > + if (IS_TIGERLAKE(dev_priv)) {
> > > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > > + if (connector->base.status ==
> > > connector_status_connected) {
> > > + val |= PANEL_POWER_ON;
> > > + intel_de_write(dev_priv, PP_CONTROL(0),
> > > val);
> > > + }
> > > + else if (connector->base.status ==
> > > connector_status_disconnected) {

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/pmu: Add a name to the execlists stats

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/pmu: Add a name to the execlists 
stats
URL   : https://patchwork.freedesktop.org/series/96324/
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:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
-O:drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Add a name to the execlists stats

[Umesh Nerlige Ramappa]

In preparation for GuC pmu stats, add a name to the execlists stats
structure so that it can be differentiated from the GuC stats.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 14 +++---
 drivers/gpu/drm/i915/gt/intel_engine_stats.h | 33 +++--
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 52 +++-
 3 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index ff6753ccb129..2de396e34d83 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -363,7 +363,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
DRIVER_CAPS(i915)->has_logical_contexts = true;
 
ewma__engine_latency_init(&engine->latency);
-   seqcount_init(&engine->stats.lock);
+   seqcount_init(&engine->stats.execlists.lock);
 
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
 
@@ -1918,15 +1918,16 @@ void intel_engine_dump(struct intel_engine_cs *engine,
 static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now)
 {
-   ktime_t total = engine->stats.total;
+   struct intel_engine_execlists_stats *stats = &engine->stats.execlists;
+   ktime_t total = stats->total;
 
/*
 * If the engine is executing something at the moment
 * add it to the total.
 */
*now = ktime_get();
-   if (READ_ONCE(engine->stats.active))
-   total = ktime_add(total, ktime_sub(*now, engine->stats.start));
+   if (READ_ONCE(stats->active))
+   total = ktime_add(total, ktime_sub(*now, stats->start));
 
return total;
 }
@@ -1940,13 +1941,14 @@ static ktime_t __intel_engine_get_busy_time(struct 
intel_engine_cs *engine,
  */
 ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine, ktime_t 
*now)
 {
+   struct intel_engine_execlists_stats *stats = &engine->stats.execlists;
unsigned int seq;
ktime_t total;
 
do {
-   seq = read_seqcount_begin(&engine->stats.lock);
+   seq = read_seqcount_begin(&stats->lock);
total = __intel_engine_get_busy_time(engine, now);
-   } while (read_seqcount_retry(&engine->stats.lock, seq));
+   } while (read_seqcount_retry(&stats->lock, seq));
 
return total;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h 
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
index 24fbdd94351a..8e762d683e50 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -15,45 +15,46 @@
 
 static inline void intel_engine_context_in(struct intel_engine_cs *engine)
 {
+   struct intel_engine_execlists_stats *stats = &engine->stats.execlists;
unsigned long flags;
 
-   if (engine->stats.active) {
-   engine->stats.active++;
+   if (stats->active) {
+   stats->active++;
return;
}
 
/* The writer is serialised; but the pmu reader may be from hardirq */
local_irq_save(flags);
-   write_seqcount_begin(&engine->stats.lock);
+   write_seqcount_begin(&stats->lock);
 
-   engine->stats.start = ktime_get();
-   engine->stats.active++;
+   stats->start = ktime_get();
+   stats->active++;
 
-   write_seqcount_end(&engine->stats.lock);
+   write_seqcount_end(&stats->lock);
local_irq_restore(flags);
 
-   GEM_BUG_ON(!engine->stats.active);
+   GEM_BUG_ON(!stats->active);
 }
 
 static inline void intel_engine_context_out(struct intel_engine_cs *engine)
 {
+   struct intel_engine_execlists_stats *stats = &engine->stats.execlists;
unsigned long flags;
 
-   GEM_BUG_ON(!engine->stats.active);
-   if (engine->stats.active > 1) {
-   engine->stats.active--;
+   GEM_BUG_ON(!stats->active);
+   if (stats->active > 1) {
+   stats->active--;
return;
}
 
local_irq_save(flags);
-   write_seqcount_begin(&engine->stats.lock);
+   write_seqcount_begin(&stats->lock);
 
-   engine->stats.active--;
-   engine->stats.total =
-   ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
+   stats->active--;
+   stats->total = ktime_add(stats->total,
+ktime_sub(ktime_get(), stats->start));
 
-   write_seqcount_end(&engine->stats.lock);
+   write_seqcount_end(&stats->lock);
local_irq_restore(flags);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e0f773585c29..24fa7fb0e7de 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -257,6 +257,33 @

[Intel-gfx] [PATCH 2/2] drm/i915/pmu: Connect engine busyness stats from GuC to pmu

[Umesh Nerlige Ramappa]

With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:

- total busyness: total time that the context was running (total)
- id: id of the running context (id)
- start timestamp: timestamp when the context started running (start)

At the time (now) of sampling the engine busyness, if the id is valid
(!= ~0), and start is non-zero, then the context is considered to be
active and the engine busyness is calculated using the below equation

engine busyness = total + (now - start)

All times are obtained from the gt clock base. For inactive contexts,
engine busyness is just equal to the total.

The start and total values provided by GuC are 32 bits and wrap around
in a few minutes. Since perf pmu provides busyness as 64 bit
monotonically increasing values, there is a need for this implementation
to account for overflows and extend the time to 64 bits before returning
busyness to the user. In order to do that, a worker runs periodically at
frequency = 1/8th the time it takes for the timestamp to wrap. As an
example, that would be once in 27 seconds for a gt clock frequency of
19.2 MHz.

Note:
There might be an over-accounting of busyness due to the fact that GuC
may be updating the total and start values while kmd is reading them.
(i.e kmd may read the updated total and the stale start). In such a
case, user may see higher busyness value followed by smaller ones which
would eventually catch up to the higher value.

v2: (Tvrtko)
- Include details in commit message
- Move intel engine busyness function into execlist code
- Use union inside engine->stats
- Use natural type for ping delay jiffies
- Drop active_work condition checks
- Use for_each_engine if iterating all engines
- Drop seq locking, use spinlock at GuC level to update engine stats
- Document worker specific details

v3: (Tvrtko/Umesh)
- Demarcate GuC and execlist stat objects with comments
- Document known over-accounting issue in commit
- Provide a consistent view of GuC state
- Add hooks to gt park/unpark for GuC busyness
- Stop/start worker in gt park/unpark path
- Drop inline
- Move spinlock and worker inits to GuC initialization
- Drop helpers that are called only once

v4: (Tvrtko/Matt/Umesh)
- Drop addressed opens from commit message
- Get runtime pm in ping, remove from the park path
- Use cancel_delayed_work_sync in disable_submission path
- Update stats during reset prepare
- Skip ping if reset in progress
- Explicitly name execlists and GuC stats objects
- Since disable_submission is called from many places, move resetting
  stats to intel_guc_submission_reset_prepare

v5: (Tvrtko)
- Add a trylock helper that does not sleep and synchronize PMU event
  callbacks and worker with gt reset

v6: (CI BAT failures)
- DUTs using execlist submission failed to boot since __gt_unpark is
  called during i915 load. This ends up calling the GuC busyness unpark
  hook and results in kick-starting an uninitialized worker. Let
  park/unpark hooks check if GuC submission has been initialized.
- drop cant_sleep() from trylock helper since rcu_read_lock takes care
  of that.

v7: (CI) Fix igt@i915_selftest@live@gt_engines
- For GuC mode of submission the engine busyness is derived from gt time
  domain. Use gt time elapsed as reference in the selftest.
- Increase busyness calculation to 10ms duration to ensure batch runs
  longer and falls within the busyness tolerances in selftest.

v8:
- Use ktime_get in selftest as before
- intel_reset_trylock_no_wait results in a lockdep splat that is not
  trivial to fix since the PMU callback runs in irq context and the
  reset paths are tightly knit into the driver. The test that uncovers
  this is igt@perf_pmu@faulting-read. Drop intel_reset_trylock_no_wait,
  instead use the reset_count to synchronize with gt reset during pmu
  callback. For the ping, continue to use intel_reset_trylock since ping
  is not run in irq context.

- GuC PM timestamp does not tick when GuC is idle. This can potentially
  result in wrong busyness values when a context is active on the
  engine, but GuC is idle. Use the RING TIMESTAMP as GPU timestamp to
  process the GuC busyness stats. This works since both GuC timestamp and
  RING timestamp are synced with the same clock.

- The busyness stats may get updated after the batch starts running.
  This delay causes the busyness reported for 100us duration to fall
  below 95% in the selftest. The only option at this time is to wait for
  GuC busyness to change from idle to active before we sample busyness
  over a 100us period.

Signed-off-by: John Harrison 
Signed-off-by: Umesh Nerlige Ramappa 
Acked-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  28 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h  |  33 ++-
 .../drm/i915/gt/

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev10)

[Patchwork]

== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev10)
URL   : https://patchwork.freedesktop.org/series/95127/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792_full -> Patchwork_21452_full


Summary
---

  **WARNING**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180:
- shard-glk:  [FAIL][1] ([i915#1888]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-glk1/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-glk5/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-tglb1/igt@gem_exec_fair@basic-p...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][6] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-iclb: NOTRUN -> [SKIP][9] ([i915#4270])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-iclb4/igt@gem_...@dmabuf-shared-protected-dst-is-context-refcounted.html

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

  * igt@gem_userptr_blits@vma-merge:
- shard-kbl:  NOTRUN -> [FAIL][11] ([i915#3318])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-kbl7/igt@gem_userptr_bl...@vma-merge.html

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

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-iclb5/igt@i915_pm...@dc6-psr.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-iclb3/igt@i915_pm...@dc6-psr.html

  * igt@i915_pm_rc6_residency@media-rc6-accuracy:
- shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289] / [fdo#111719])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-tglb3/igt@i915_pm_rc6_reside...@media-rc6-accuracy.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/shard-kbl1/igt@i915_susp...@forcewake.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-kbl7/igt@i915_susp...@forcewake.html

  * igt@kms_big_fb@linear-16bpp-rotate-90:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271]) +97 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-apl4/igt@kms_big...@linear-16bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-kbl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/shard-kbl7/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-0-hflip.html

  * igt@kms_big_fb@y-tiled-max-h

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp/fb: Remove CCS FB stride restrictions

[Patchwork]

== Series Details ==

Series: drm/i915/adlp/fb: Remove CCS FB stride restrictions
URL   : https://patchwork.freedesktop.org/series/96322/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21454


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 35)
--

  Additional (2): fi-ilk-650 fi-pnv-d510 
  Missing(5): bat-dg1-6 bat-dg1-5 bat-adlp-4 fi-ctg-p8600 fi-elk-e7500 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][1] ([fdo#109271]) +35 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-ilk-650: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/fi-ilk-650/igt@kms_chamel...@dp-hpd-fast.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271]) +53 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][8] ([i915#4290]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21454/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4290]: https://gitlab.freedesktop.org/drm/intel/issues/4290


Build changes
-

  * IGT: IGT_6262 -> IGTPW_6353
  * Linux: CI_DRM_10792 -> Patchwork_21454

  CI-20190529: 20190529
  CI_DRM_10792: 299777ddcc06c9a0ea7b95a0823ccaca268d16b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_6353: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6353/index.html
  IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21454: b599bcdbbdaf8b03711af84b82fe8f19c12afb62 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b599bcdbbdaf drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides
02233c237439 drm/i915/adlp/fb: Remove restriction on semiplanar UV plane offset
c22064ad4251 drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride
afe502a5c79a drm/i915/adlp/fb: Fix remapping of linear CCS AUX surfaces
cc21aac93ca8 drm/i915/fb: Factor out functions to remap contiguous FB obj pages
a3c4b2242791 drm/i915/adlp/fb: Prevent the mapping of redundant trailing 
padding NULL pages
9cba4428b32d drm/i915/fb: Fix rounding error in subsampled plane size 
calculation

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adlp/fb: Remove CCS FB stride restrictions

[Patchwork]

== Series Details ==

Series: drm/i915/adlp/fb: Remove CCS FB stride restrictions
URL   : https://patchwork.freedesktop.org/series/96322/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9cba4428b32d drm/i915/fb: Fix rounding error in subsampled plane size 
calculation
a3c4b2242791 drm/i915/adlp/fb: Prevent the mapping of redundant trailing 
padding NULL pages
cc21aac93ca8 drm/i915/fb: Factor out functions to remap contiguous FB obj pages
afe502a5c79a drm/i915/adlp/fb: Fix remapping of linear CCS AUX surfaces
-:117: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'var' - possible 
side-effects?
#117: FILE: drivers/gpu/drm/i915/display/intel_fb.c:1312:
+#define assign_bfld_chk_ovf(i915, var, val) ({ \
+   (var) = (val); \
+   drm_WARN_ON(&(i915)->drm, (var) != (val)); \
+   (var); \
+})

-:117: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'val' - possible 
side-effects?
#117: FILE: drivers/gpu/drm/i915/display/intel_fb.c:1312:
+#define assign_bfld_chk_ovf(i915, var, val) ({ \
+   (var) = (val); \
+   drm_WARN_ON(&(i915)->drm, (var) != (val)); \
+   (var); \
+})

total: 0 errors, 0 warnings, 2 checks, 318 lines checked
c22064ad4251 drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride
02233c237439 drm/i915/adlp/fb: Remove restriction on semiplanar UV plane offset
b599bcdbbdaf drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp: Extend PSR2 support in transcoder B

[Patchwork]

== Series Details ==

Series: drm/i915/adlp: Extend PSR2 support in transcoder B
URL   : https://patchwork.freedesktop.org/series/96321/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21453


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Additional (1): fi-ilk-650 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-icl-u2 bat-adlp-4 fi-ctg-p8600 
fi-elk-e7500 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][1] ([fdo#109271]) +35 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-ilk-650: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/fi-ilk-650/igt@kms_chamel...@dp-hpd-fast.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][3] ([i915#1602] / [i915#2426] / 
[i915#4312])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][4] ([i915#4290]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21453/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4290]: https://gitlab.freedesktop.org/drm/intel/issues/4290
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312


Build changes
-

  * Linux: CI_DRM_10792 -> Patchwork_21453

  CI-20190529: 20190529
  CI_DRM_10792: 299777ddcc06c9a0ea7b95a0823ccaca268d16b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21453: 2e0a7d53c6fd2c3604e2db4d4cfed644d9f4b4bf @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2e0a7d53c6fd drm/i915/adlp: Extend PSR2 support in transcoder B

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev10)

[Patchwork]

== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev10)
URL   : https://patchwork.freedesktop.org/series/95127/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21452


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 34)
--

  Additional (1): fi-ilk-650 
  Missing(5): bat-dg1-6 bat-dg1-5 bat-adlp-4 fi-ctg-p8600 fi-elk-e7500 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][1] ([fdo#109271]) +35 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

  * igt@debugfs_test@read_all_entries:
- fi-kbl-soraka:  [PASS][2] -> [DMESG-WARN][3] ([i915#1982] / 
[i915#262])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-ilk-650: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/fi-ilk-650/igt@kms_chamel...@dp-hpd-fast.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][7] ([i915#4290]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21452/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#4290]: https://gitlab.freedesktop.org/drm/intel/issues/4290


Build changes
-

  * Linux: CI_DRM_10792 -> Patchwork_21452

  CI-20190529: 20190529
  CI_DRM_10792: 299777ddcc06c9a0ea7b95a0823ccaca268d16b8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6262: d1c793b26e31cc6ae3f9fa3239805a9bbcc749fb @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21452: c28caf36811dbd6c00b6e6ee75479eaa176b4bd2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c28caf36811d drm/i915: Clarify probing order in 
intel_dp_aux_init_backlight_funcs()
e87c0204c051 drm/dp, drm/i915: Add support for VESA backlights using PWM for 
brightness control
8bc9ebb1845f drm/dp: Disable unsupported features in 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER
7557ddeac4b1 drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux 
enable/brightness
2a532b418235 drm/i915: Add support for panels with VESA backlights with PWM 
enable/disable

== Logs ==

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

[Intel-gfx] [PATCH 7/7] drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides

[Imre Deak]

As opposed to other GEN12 platforms ADLP provides a way to program the
stride of CCS surfaces independently of the main surface stride (within
the corresponding limit of the preceding and succeeding power-of-two
values of the main surface stride). Using this HW feature we can remove
the POT stride restriction on CCS surfaces, making the ADLP CCS FB uAPI
(FB modifiers) identical to that of TGL.

The HW makes the CCS stride flexible programming possible by deriving
the stride from the value programmed to the PLANE_STRIDE register. After
that the HW rounds up this value to the next power-of-two value and uses
this for walking the pages of the main surface mapped to GTT/DPT.

To align with the above scheme, introduce a scanout_stride view
parameter which will be programmed to the PLANE_STRIDE register and use
the mapping_stride view param to store the POT aligned value of the
same. By requiring userspace to pass in FBs with a CCS stride that
aligns with the main surface stride (matching the requirement of all
GEN12 platforms), the scanout_stride will be the userspace main surface
stride and the mapping_stride will be the POT rounded value of the same.

Cc: Ville Syrjälä 
Cc: Juha-Pekka Heikkila 
Cc: Nanley G Chery 
Cc: Sameer Lattannavar 
Signed-off-by: Imre Deak 
---
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_fb.c   | 67 +++
 .../drm/i915/display/skl_universal_plane.c|  2 +-
 3 files changed, 26 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index cd8790617b417..c344e7771a092 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -116,6 +116,7 @@ struct intel_fb_view {
 *   pixels for 90/270 degree rotation
 */
unsigned int mapping_stride;
+   unsigned int scanout_stride;
} color_plane[4];
 };
 
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index cc350e20cbfe6..6da29231be72b 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -511,35 +511,12 @@ int skl_ccs_to_main_plane(const struct drm_framebuffer 
*fb, int ccs_plane)
return ccs_plane - fb->format->num_planes / 2;
 }
 
-static unsigned int gen12_aligned_scanout_stride(const struct 
intel_framebuffer *fb,
-int color_plane)
-{
-   struct drm_i915_private *i915 = to_i915(fb->base.dev);
-   unsigned int stride = fb->base.pitches[color_plane];
-
-   if (IS_ALDERLAKE_P(i915))
-   return roundup_pow_of_two(max(stride,
- 8u * 
intel_tile_width_bytes(&fb->base, color_plane)));
-
-   return stride;
-}
-
 static unsigned int gen12_ccs_aux_stride(struct intel_framebuffer *fb, int 
ccs_plane)
 {
-   struct drm_i915_private *i915 = to_i915(fb->base.dev);
int main_plane = skl_ccs_to_main_plane(&fb->base, ccs_plane);
unsigned int main_stride = fb->base.pitches[main_plane];
unsigned int main_tile_width = intel_tile_width_bytes(&fb->base, 
main_plane);
 
-   /*
-* On ADL-P the AUX stride must align with a power-of-two aligned main
-* surface stride. The stride of the allocated main surface object can
-* be less than this POT stride, which is then autopadded to the POT
-* size.
-*/
-   if (IS_ALDERLAKE_P(i915))
-   main_stride = gen12_aligned_scanout_stride(fb, main_plane);
-
return DIV_ROUND_UP(main_stride, 4 * main_tile_width) * 64;
 }
 
@@ -795,7 +772,6 @@ void intel_fb_plane_get_subsampling(int *hsub, int *vsub,
 
 static void intel_fb_plane_dims(const struct intel_framebuffer *fb, int 
color_plane, int *w, int *h)
 {
-   struct drm_i915_private *i915 = to_i915(fb->base.dev);
int main_plane = intel_fb_is_ccs_aux_plane(&fb->base, color_plane) ?
 skl_ccs_to_main_plane(&fb->base, color_plane) : 0;
unsigned int main_width = fb->base.width;
@@ -803,16 +779,6 @@ static void intel_fb_plane_dims(const struct 
intel_framebuffer *fb, int color_pl
int main_hsub, main_vsub;
int hsub, vsub;
 
-   /*
-* On ADL-P the CCS AUX surface layout always aligns with the
-* power-of-two aligned main surface stride. The main surface
-* stride in the allocated FB object may not be power-of-two
-* sized, in which case it is auto-padded to the POT size.
-*/
-   if (IS_ALDERLAKE_P(i915) && intel_fb_is_ccs_aux_plane(&fb->base, 
color_plane))
-   main_width = gen12_aligned_scanout_stride(fb, 0) /
-fb->base.format->cpp[0];
-
intel_fb_plane_get_subsampling(&main_hsub, &main_vsub, &fb->base, 
main_plane);
intel_fb_plane_ge

[Intel-gfx] [PATCH 5/7] drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride

[Imre Deak]

The next patch needs to distinguish between a view's mapping and scanout
stride. Rename the current stride parameter to mapping_stride with the
script below. mapping_stride will keep the same meaning as stride had
on all platforms so far, while the meaning of it will change on ADLP.

No functional changes.

@@
identifier intel_fb_view;
identifier i915_color_plane_view;
identifier color_plane;
expression e;
type T;
@@
struct intel_fb_view {
...
struct i915_color_plane_view {
...
- T stride;
+ T mapping_stride;
...
} color_plane[e];
...
};

@@
struct i915_color_plane_view pv;
@@
  pv.
-stride
+mapping_stride

@@
struct i915_color_plane_view *pvp;
@@
  pvp->
- stride
+ mapping_stride

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c |  4 +--
 drivers/gpu/drm/i915/display/intel_cursor.c   |  6 ++---
 drivers/gpu/drm/i915/display/intel_display.c  |  6 ++---
 .../drm/i915/display/intel_display_types.h|  2 +-
 drivers/gpu/drm/i915/display/intel_fb.c   | 25 ++-
 drivers/gpu/drm/i915/display/intel_fbc.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |  8 +++---
 .../drm/i915/display/skl_universal_plane.c|  4 +--
 8 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index a939accff7ee2..e1b52b27cb7c5 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -256,7 +256,7 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
u32 alignment = intel_surf_alignment(fb, 0);
int cpp = fb->format->cpp[0];
 
-   while ((src_x + src_w) * cpp > 
plane_state->view.color_plane[0].stride) {
+   while ((src_x + src_w) * cpp > 
plane_state->view.color_plane[0].mapping_stride) {
if (offset == 0) {
drm_dbg_kms(&dev_priv->drm,
"Unable to find suitable display 
surface offset due to X-tiling\n");
@@ -431,7 +431,7 @@ static void i9xx_update_plane(struct intel_plane *plane,
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
 
intel_de_write_fw(dev_priv, DSPSTRIDE(i9xx_plane),
- plane_state->view.color_plane[0].stride);
+ plane_state->view.color_plane[0].mapping_stride);
 
if (DISPLAY_VER(dev_priv) < 4) {
/*
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 6b08d8bca5cd4..5ab716398f444 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -190,7 +190,7 @@ static u32 i845_cursor_ctl(const struct intel_crtc_state 
*crtc_state,
 {
return CURSOR_ENABLE |
CURSOR_FORMAT_ARGB |
-   CURSOR_STRIDE(plane_state->view.color_plane[0].stride);
+   CURSOR_STRIDE(plane_state->view.color_plane[0].mapping_stride);
 }
 
 static bool i845_cursor_size_ok(const struct intel_plane_state *plane_state)
@@ -229,7 +229,7 @@ static int i845_check_cursor(struct intel_crtc_state 
*crtc_state,
}
 
drm_WARN_ON(&i915->drm, plane_state->uapi.visible &&
-   plane_state->view.color_plane[0].stride != fb->pitches[0]);
+   plane_state->view.color_plane[0].mapping_stride != 
fb->pitches[0]);
 
switch (fb->pitches[0]) {
case 256:
@@ -450,7 +450,7 @@ static int i9xx_check_cursor(struct intel_crtc_state 
*crtc_state,
}
 
drm_WARN_ON(&dev_priv->drm, plane_state->uapi.visible &&
-   plane_state->view.color_plane[0].stride != fb->pitches[0]);
+   plane_state->view.color_plane[0].mapping_stride != 
fb->pitches[0]);
 
if (fb->pitches[0] !=
drm_rect_width(&plane_state->uapi.dst) * fb->format->cpp[0]) {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8200969c9a046..b7718f2f63977 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -653,7 +653,7 @@ u32 intel_fb_xy_to_linear(int x, int y,
 {
const struct drm_framebuffer *fb = state->hw.fb;
unsigned int cpp = fb->format->cpp[color_plane];
-   unsigned int pitch = state->view.color_plane[color_plane].stride;
+   unsigned int pitch = 
state->view.color_plane[color_plane].mapping_stride;
 
return y * pitch + x * cpp;
 }
@@ -7751,8 +7751,8 @@ static int intel_atomic_check_async(struct 
intel_atomic_state *state)
return -EINVAL;
}
 
-   if (old_plane_state->view.color_plane[0].stride !=
-   new_plane_state->view.color_plane[0].stride) {
+   if (old_plane_state->view.color_plane[0].mapping_stride !=
+   new_plane_state->vi

[Intel-gfx] [PATCH 4/7] drm/i915/adlp/fb: Fix remapping of linear CCS AUX surfaces

[Imre Deak]

During remapping CCS FBs the CCS AUX surface mapped size and offset->x,y
coordinate calculations assumed a tiled layout. This works as long as
the CCS surface height is aligned to 64 lines (ensuring a 4k bytes CCS
surface tile layout).  However this alignment is not required by the HW
(and the driver doesn't enforces it either).

Add the remapping logic required to remap the pages of CCS surfaces
without the above alignment, assuming the natural linear layout of the
CCS surface (vs. tiled main surface layout).

Cc: Juha-Pekka Heikkila 
Cc: Ville Syrjälä 
Fixes: 3d1adc3d64cf ("drm/i915/adlp: Add support for remapping CCS FBs")
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c |   6 +-
 drivers/gpu/drm/i915/display/intel_fb.c  | 107 ++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c |  85 +++
 drivers/gpu/drm/i915/i915_vma_types.h|  19 +++-
 4 files changed, 164 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f9c6d5aab8bf3..8200969c9a046 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -614,7 +614,11 @@ unsigned int intel_remapped_info_size(const struct 
intel_remapped_info *rem_info
for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
unsigned int plane_size;
 
-   plane_size = rem_info->plane[i].dst_stride * 
rem_info->plane[i].height;
+   if (rem_info->plane[i].linear)
+   plane_size = rem_info->plane[i].size;
+   else
+   plane_size = rem_info->plane[i].dst_stride * 
rem_info->plane[i].height;
+
if (plane_size == 0)
continue;
 
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index c3fb7d7366f58..dde408902239f 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -847,6 +847,20 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
return new_offset;
 }
 
+static u32 intel_adjust_linear_offset(int *x, int *y,
+ unsigned int cpp,
+ unsigned int pitch,
+ u32 old_offset,
+ u32 new_offset)
+{
+   old_offset += *y * pitch + *x * cpp;
+
+   *y = (old_offset - new_offset) / pitch;
+   *x = ((old_offset - new_offset) - *y * pitch) / cpp;
+
+   return new_offset;
+}
+
 static u32 intel_adjust_aligned_offset(int *x, int *y,
   const struct drm_framebuffer *fb,
   int color_plane,
@@ -877,10 +891,8 @@ static u32 intel_adjust_aligned_offset(int *x, int *y,
 tile_size, pitch_tiles,
 old_offset, new_offset);
} else {
-   old_offset += *y * pitch + *x * cpp;
-
-   *y = (old_offset - new_offset) / pitch;
-   *x = ((old_offset - new_offset) - *y * pitch) / cpp;
+   intel_adjust_linear_offset(x, y, cpp, pitch,
+  old_offset, new_offset);
}
 
return new_offset;
@@ -1252,12 +1264,11 @@ plane_view_dst_stride_tiles(const struct 
intel_framebuffer *fb, int color_plane,
unsigned int pitch_tiles)
 {
if (intel_fb_needs_pot_stride_remap(fb)) {
-   unsigned int min_stride = intel_fb_is_ccs_aux_plane(&fb->base, 
color_plane) ? 2 : 8;
/*
 * ADL_P, the only platform needing a POT stride has a minimum
-* of 8 main surface and 2 CCS AUX stride tiles.
+* of 8 main surface tiles.
 */
-   return roundup_pow_of_two(max(pitch_tiles, min_stride));
+   return roundup_pow_of_two(max(pitch_tiles, 8u));
} else {
return pitch_tiles;
}
@@ -1279,11 +1290,31 @@ plane_view_height_tiles(const struct intel_framebuffer 
*fb, int color_plane,
return DIV_ROUND_UP(y + dims->height, dims->tile_height);
 }
 
+static unsigned int
+plane_view_linear_tiles(const struct intel_framebuffer *fb, int color_plane,
+   const struct fb_plane_view_dims *dims,
+   int x, int y)
+{
+   struct drm_i915_private *i915 = to_i915(fb->base.dev);
+   unsigned int size;
+
+   size = (y + dims->height) * fb->base.pitches[color_plane] +
+   x * fb->base.format->cpp[color_plane];
+
+   return DIV_ROUND_UP(size, intel_tile_size(i915));
+}
+
 #define assign_chk_ovf(i915, var, val) ({ \
drm_WARN_ON(&(i915)->drm, overflows_type(val, var)); \
(var) = (val); \
 })
 
+#define assign_bfld_chk_ovf(i915, var, val) ({ \
+   (var) = (val); \
+

[Intel-gfx] [PATCH 2/7] drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding NULL pages

[Imre Deak]

So far the remapped view size in GTT/DPT was padded to the next aligned
offset unnecessarily after the last color plane with an unaligned size.
Remove the unnecessary padding.

Cc: Juha-Pekka Heikkila 
Fixes: 3d1adc3d64cf ("drm/i915/adlp: Add support for remapping CCS FBs")
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 -
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2b97c87971773..f9c6d5aab8bf3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -612,9 +612,16 @@ unsigned int intel_remapped_info_size(const struct 
intel_remapped_info *rem_info
int i;
 
for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
+   unsigned int plane_size;
+
+   plane_size = rem_info->plane[i].dst_stride * 
rem_info->plane[i].height;
+   if (plane_size == 0)
+   continue;
+
if (rem_info->plane_alignment)
size = ALIGN(size, rem_info->plane_alignment);
-   size += rem_info->plane[i].dst_stride * 
rem_info->plane[i].height;
+
+   size += plane_size;
}
 
return size;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index f17383e76eb71..57c97554393b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1396,6 +1396,9 @@ remap_pages(struct drm_i915_gem_object *obj,
 {
unsigned int row;
 
+   if (!width || !height)
+   return sg;
+
if (alignment_pad) {
st->nents++;
 
-- 
2.27.0

[Intel-gfx] [PATCH 6/7] drm/i915/adlp/fb: Remove restriction on semiplanar UV plane offset

[Imre Deak]

Since the surfaces of tiled FBs on ADLP are remapped it's pointless to
require an alignment in the allocated object. The necessary tile-row
alignment (to be programmed to the surface start register) will be
ensured later when flipping to the FB.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index b0900376b984d..cc350e20cbfe6 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1012,6 +1012,7 @@ static int intel_fb_offset_to_xy(int *x, int *y,
u32 alignment;
 
if (DISPLAY_VER(i915) >= 12 &&
+   !intel_fb_needs_pot_stride_remap(to_intel_framebuffer(fb)) &&
is_semiplanar_uv_plane(fb, color_plane))
alignment = intel_tile_row_size(fb, color_plane);
else if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
-- 
2.27.0

[Intel-gfx] [PATCH 3/7] drm/i915/fb: Factor out functions to remap contiguous FB obj pages

[Imre Deak]

Factor out functions needed to map contiguous FB obj pages to a GTT/DPT
VMA view in the next patch.

No functional changes.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 110 +++
 1 file changed, 60 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 57c97554393b9..a30366d4965b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1387,6 +1387,25 @@ intel_rotate_pages(struct intel_rotation_info *rot_info,
return ERR_PTR(ret);
 }
 
+static struct scatterlist *
+add_padding_pages(unsigned int count,
+ struct sg_table *st, struct scatterlist *sg)
+{
+   st->nents++;
+
+   /*
+* The DE ignores the PTEs for the padding tiles, the sg entry
+* here is just a convenience to indicate how many padding PTEs
+* to insert at this spot.
+*/
+   sg_set_page(sg, NULL, count * 4096, 0);
+   sg_dma_address(sg) = 0;
+   sg_dma_len(sg) = count * 4096;
+   sg = sg_next(sg);
+
+   return sg;
+}
+
 static struct scatterlist *
 remap_pages(struct drm_i915_gem_object *obj,
unsigned int offset, unsigned int alignment_pad,
@@ -1399,19 +1418,8 @@ remap_pages(struct drm_i915_gem_object *obj,
if (!width || !height)
return sg;
 
-   if (alignment_pad) {
-   st->nents++;
-
-   /*
-* The DE ignores the PTEs for the padding tiles, the sg entry
-* here is just a convenience to indicate how many padding PTEs
-* to insert at this spot.
-*/
-   sg_set_page(sg, NULL, alignment_pad * 4096, 0);
-   sg_dma_address(sg) = 0;
-   sg_dma_len(sg) = alignment_pad * 4096;
-   sg = sg_next(sg);
-   }
+   if (alignment_pad)
+   sg = add_padding_pages(alignment_pad, st, sg);
 
for (row = 0; row < height; row++) {
unsigned int left = width * I915_GTT_PAGE_SIZE;
@@ -1448,22 +1456,45 @@ remap_pages(struct drm_i915_gem_object *obj,
if (!left)
continue;
 
-   st->nents++;
-
-   /*
-* The DE ignores the PTEs for the padding tiles, the sg entry
-* here is just a conenience to indicate how many padding PTEs
-* to insert at this spot.
-*/
-   sg_set_page(sg, NULL, left, 0);
-   sg_dma_address(sg) = 0;
-   sg_dma_len(sg) = left;
-   sg = sg_next(sg);
+   sg = add_padding_pages(left >> PAGE_SHIFT, st, sg);
}
 
return sg;
 }
 
+static struct scatterlist *
+remap_contiguous_pages(struct drm_i915_gem_object *obj,
+  unsigned int obj_offset,
+  unsigned int count,
+  struct sg_table *st, struct scatterlist *sg)
+{
+   struct scatterlist *iter;
+   unsigned int offset;
+
+   iter = i915_gem_object_get_sg_dma(obj, obj_offset, &offset);
+   GEM_BUG_ON(!iter);
+
+   do {
+   unsigned int len;
+
+   len = min(sg_dma_len(iter) - (offset << PAGE_SHIFT),
+ count << PAGE_SHIFT);
+   sg_set_page(sg, NULL, len, 0);
+   sg_dma_address(sg) =
+   sg_dma_address(iter) + (offset << PAGE_SHIFT);
+   sg_dma_len(sg) = len;
+
+   st->nents++;
+   count -= len >> PAGE_SHIFT;
+   if (count == 0)
+   return sg;
+
+   sg = __sg_next(sg);
+   iter = __sg_next(iter);
+   offset = 0;
+   } while (1);
+}
+
 static noinline struct sg_table *
 intel_remap_pages(struct intel_remapped_info *rem_info,
  struct drm_i915_gem_object *obj)
@@ -1524,9 +1555,8 @@ intel_partial_pages(const struct i915_ggtt_view *view,
struct drm_i915_gem_object *obj)
 {
struct sg_table *st;
-   struct scatterlist *sg, *iter;
+   struct scatterlist *sg;
unsigned int count = view->partial.size;
-   unsigned int offset;
int ret = -ENOMEM;
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
@@ -1537,34 +1567,14 @@ intel_partial_pages(const struct i915_ggtt_view *view,
if (ret)
goto err_sg_alloc;
 
-   iter = i915_gem_object_get_sg_dma(obj, view->partial.offset, &offset);
-   GEM_BUG_ON(!iter);
-
-   sg = st->sgl;
st->nents = 0;
-   do {
-   unsigned int len;
 
-   len = min(sg_dma_len(iter) - (offset << PAGE_SHIFT),
- count << PAGE_SHIFT);
-   sg_set_page(sg, NULL, len, 0);
-   sg_dma_address(sg) =
-   sg_dma_address(iter) + (offset << PAGE_SHIFT);
-   sg_dma_len(sg) = len;
+  

[Intel-gfx] [PATCH 0/7] drm/i915/adlp/fb: Remove CCS FB stride restrictions

[Imre Deak]

This patchset removes the CCS FB stride restrictions on ADLP. This makes
the uAPI for these FBs (via CCS modifiers) match the TGL one.

It also fixes a few issues I noticed during testing.

I tested the patchset along with [1] (required due to the ADLP uAPI
change) on SKL/TGL/ADLP.

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

Test-with: 20211026212620.2718277-1-imre.d...@intel.com

Cc: Nanley G Chery 
Cc: Sameer Lattannavar 
Cc: Juha-Pekka Heikkila 
Cc: Ville Syrjälä 

Imre Deak (7):
  drm/i915/fb: Fix rounding error in subsampled plane size calculation
  drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding
NULL pages
  drm/i915/fb: Factor out functions to remap contiguous FB obj pages
  drm/i915/adlp/fb: Fix remapping of linear CCS AUX surfaces
  drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride
  drm/i915/adlp/fb: Remove restriction on semiplanar UV plane offset
  drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides

 drivers/gpu/drm/i915/display/i9xx_plane.c |   4 +-
 drivers/gpu/drm/i915/display/intel_cursor.c   |   6 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  19 +-
 .../drm/i915/display/intel_display_types.h|   3 +-
 drivers/gpu/drm/i915/display/intel_fb.c   | 196 +++--
 drivers/gpu/drm/i915/display/intel_fbc.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |   8 +-
 .../drm/i915/display/skl_universal_plane.c|   4 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 272 +++---
 drivers/gpu/drm/i915/i915_vma_types.h |  19 +-
 10 files changed, 324 insertions(+), 209 deletions(-)

-- 
2.27.0

[Intel-gfx] [PATCH 1/7] drm/i915/fb: Fix rounding error in subsampled plane size calculation

[Imre Deak]

For NV12 FBs with odd main surface tile-row height the CCS surface
height was incorrectly calculated 1 less than the actual value. Fix this
by rounding up the result of divison. For consistency do the same for
the CCS surface width calculation.

Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression")
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 9ce1d273dc7e1..c3fb7d7366f58 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -816,8 +816,8 @@ static void intel_fb_plane_dims(const struct 
intel_framebuffer *fb, int color_pl
intel_fb_plane_get_subsampling(&main_hsub, &main_vsub, &fb->base, 
main_plane);
intel_fb_plane_get_subsampling(&hsub, &vsub, &fb->base, color_plane);
 
-   *w = main_width / main_hsub / hsub;
-   *h = main_height / main_vsub / vsub;
+   *w = DIV_ROUND_UP(main_width, main_hsub * hsub);
+   *h = DIV_ROUND_UP(main_height, main_vsub * vsub);
 }
 
 static u32 intel_adjust_tile_offset(int *x, int *y,
-- 
2.27.0

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev10)

[Patchwork]

== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev10)
URL   : https://patchwork.freedesktop.org/series/95127/
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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev10)

[Patchwork]

== Series Details ==

Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers 
(rev10)
URL   : https://patchwork.freedesktop.org/series/95127/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2a532b418235 drm/i915: Add support for panels with VESA backlights with PWM 
enable/disable
7557ddeac4b1 drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux 
enable/brightness
8bc9ebb1845f drm/dp: Disable unsupported features in 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER
e87c0204c051 drm/dp, drm/i915: Add support for VESA backlights using PWM for 
brightness control
-:228: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#228: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:309:
+
panel->backlight.pwm_level_max);

total: 0 errors, 1 warnings, 0 checks, 255 lines checked
c28caf36811d drm/i915: Clarify probing order in 
intel_dp_aux_init_backlight_funcs()

[Intel-gfx] [PATCH] drm/i915/adlp: Extend PSR2 support in transcoder B

[José Roberto de Souza]

PSR2 is supported in transcoder A and B on Alderlake-P.

BSpec: 49185
Cc: Mika Kahola 
Cc: Jouni Hogander 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index d35db50ef967a..710b911b065b9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -588,7 +588,9 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 static bool
 transcoder_has_psr2(struct drm_i915_private *dev_priv, enum transcoder trans)
 {
-   if (DISPLAY_VER(dev_priv) >= 12)
+   if (IS_ALDERLAKE_P(dev_priv))
+   return trans <= TRANSCODER_B;
+   else if (DISPLAY_VER(dev_priv) >= 12)
return trans == TRANSCODER_A;
else
return trans == TRANSCODER_EDP;
-- 
2.33.1

Re: [Intel-gfx] [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

[Inki Dae]

Hi,

21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi
> 
> Signed-off-by: Claudio Suarez 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 7655142a4651..a563d6386abe 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -893,12 +893,14 @@ static int hdmi_get_modes(struct drm_connector 
> *connector)
>   if (!edid)
>   return -ENODEV;
>  
> - hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
> + /* This updates connector->display_info */
> + drm_connector_update_edid_property(connector, edid);
> +
> + hdata->dvi_mode = !connector->display_info.is_hdmi;

Thanks for correcting this. Yeah, we should use drm_display_info.is_hdmi parsed 
from EDID.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725

Signed-off-by: Inki Dae 

Thanks,
Inki Dae

>   DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
> (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
> edid->width_cm, edid->height_cm);
>  
> - drm_connector_update_edid_property(connector, edid);
>   cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
>  
>   ret = drm_add_edid_modes(connector, edid);
> 

[Intel-gfx] [PATCH v4 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

[Lyude Paul]

Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.

So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~

Signed-off-by: Lyude Paul 
Acked-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 96fe3eaba44a..8b9c925c4c16 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -456,11 +456,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *connector)
}
 
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority 
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this 
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will 
always use the VESA
+* interface. This means that there's quite a number of panels out 
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia 
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise 
support for both
+* interfaces, the VESA backlight interface will stop working once 
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to 
detect Intel's
+* backlight interface at all. This means that the only sensible way 
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
 */
if (try_intel_interface && 
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight 
controls\n");
-- 
2.31.1

[Intel-gfx] [PATCH v4 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

[Lyude Paul]

Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.

Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.

v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps

Signed-off-by: Lyude Paul 
Reviewed-by: Doug Anderson 
Cc: Rajeev Nandan 
Cc: Satadru Pramanik 
---
 drivers/gpu/drm/drm_dp_helper.c   | 76 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 44 ---
 include/drm/drm_dp_helper.h   |  7 +-
 3 files changed, 91 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8f2032a955cf..b91b092e10f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3290,6 +3290,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux, 
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
 
+   /* The panel uses the PWM for controlling brightness levels */
+   if (!bl->aux_set)
+   return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3316,7 +3320,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
int ret;
u8 buf;
 
-   /* The panel uses something other then DPCD for enabling its backlight 
*/
+   /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
 
@@ -3351,11 +3355,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
  * restoring any important backlight state such as the given backlight level, 
the brightness byte
  * count, backlight frequency, etc.
  *
- * Note that certain panels, while supporting brightness level controls over 
DPCD, may not support
- * having their backlights enabled via the standard 
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
- * &drm_edp_backlight_info.aux_enable will be set to %false, this function 
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must 
perform the required
- * implementation specific step for enabling the backlight after calling this 
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD, 
but instead require
+ * that the driver handle enabling/disabling the panel through 
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, &drm_edp_backlight_info.aux_enable 
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle 
powering the panel on using
+ * the EDP_BL_PWR GPIO.
  *
  * Returns: %0 on success, negative error code on failure.
  */
@@ -3363,7 +3367,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
 const u16 level)
 {
int ret;
-   u8 dpcd_buf, new_dpcd_buf;
+   u8 dpcd_buf, new_dpcd_buf, new_mode;
 
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER, 
&dpcd_buf);
if (ret != 1) {
@@ -3376,9 +3380,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
   DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
-   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+   if (bl->aux_set)
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   else
+   new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
+
+   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   new_dpcd_buf |= new_mode;
 
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT, 
bl->pwmgen_bit_count);
@@ -3425,12 +3434,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
  * @aux: The DP AUX channel to use
  * @bl: Backlight capability info from drm_edp_backlight_init()
  *
- * This function handles disabling DPCD backlight controls on a panel over 
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despite 
having their brightness
- * va

[Intel-gfx] [PATCH v4 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

[Lyude Paul]

Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
 
-   if (drm_edp_backlight_supported(edp_dpcd)) {
+   /* TODO: Add support for hybrid PWM/DPCD panels */
+   if (drm_edp_backlight_supported(edp_dpcd) &&
+   (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on 
%s\n",
 nv_conn->base.name);
 
-- 
2.31.1

[Intel-gfx] [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

[Lyude Paul]

As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.

So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.

Signed-off-by: Lyude Paul 
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM 
helpers")
---
 drivers/gpu/drm/drm_dp_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ada0a1ff262d..8f2032a955cf 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3372,7 +3372,9 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
return ret < 0 ? ret : -EIO;
}
 
-   new_dpcd_buf = dpcd_buf;
+   /* Disable any backlight functionality we don't support that might be 
on */
+   new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
+  DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
 
if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
@@ -3394,6 +3396,8 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux, 
const struct drm_edp_backli
aux->name, ret);
else
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   } else {
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
}
 
if (new_dpcd_buf != dpcd_buf) {
-- 
2.31.1

[Intel-gfx] [PATCH v4 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

[Lyude Paul]

This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.

For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.

v4:
* Make sure that we call intel_backlight_level_to_pwm() in
  intel_dp_aux_vesa_enable_backlight() - vsyrjala

Signed-off-by: Lyude Paul 
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM 
enable/disable")
Cc:  # v5.12+
---
 .../drm/i915/display/intel_dp_aux_backlight.c | 27 ++-
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 569d17b4d00f..f05b71c01b8e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,13 @@ intel_dp_aux_vesa_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   u32 pwm_level = intel_backlight_invert_pwm_level(connector,
+
panel->backlight.pwm_level_max);
+
+   panel->backlight.pwm_funcs->enable(crtc_state, conn_state, 
pwm_level);
+   }
+
drm_edp_backlight_enable(&intel_dp->aux, 
&panel->backlight.edp.vesa.info, level);
 }
 
@@ -304,6 +311,10 @@ static void intel_dp_aux_vesa_disable_backlight(const 
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
 
drm_edp_backlight_disable(&intel_dp->aux, 
&panel->backlight.edp.vesa.info);
+
+   if (!panel->backlight.edp.vesa.info.aux_enable)
+   panel->backlight.pwm_funcs->disable(old_conn_state,
+   
intel_backlight_invert_pwm_level(connector, 0));
 }
 
 static int intel_dp_aux_vesa_setup_backlight(struct intel_connector 
*connector, enum pipe pipe)
@@ -321,6 +332,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct 
intel_connector *connector,
if (ret < 0)
return ret;
 
+   if (!panel->backlight.edp.vesa.info.aux_enable) {
+   ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+   if (ret < 0) {
+   drm_err(&i915->drm,
+   "Failed to setup PWM backlight controls for eDP 
backlight: %d\n",
+   ret);
+   return ret;
+   }
+   }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +360,7 @@ intel_dp_aux_supports_vesa_backlight(struct 
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
 
-   /* TODO: We currently only support AUX only backlight configurations, 
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time, 
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
-   if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
-   drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+   if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
-- 
2.31.1

[Intel-gfx] [PATCH v4 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

[Lyude Paul]

When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us disabling DPCD backlight support on such machines. This
works fine, unless you have a machine that actually needs this
functionality for backlight controls to work at all. Additionally, we
will need to support PWM for when we start adding support for VESA's
product (as in the product of multiplication) control mode for better
brightness ranges.

So - let's finally finish up implementing basic support for these types
of backlights to solve these problems in our DP helpers, along with
implementing support for this in i915. And since digging into this issue
solved the last questions we really had about probing backlights in i915
for the most part, let's update some of the comments around that as
well!

Changes (v3):
* Add likely fix for weird backlight scaling issues on samus-fi-bdw in intel's
  CI, which pointed out we've been leaving some (currently) unsupported
  backlight features on by mistake which certainly have the potential to cause
  problems.
  UPDATE: this didn't fix the problem, but this changed the symptoms was
  definitely still a bug either way.
Changes (v2):
* Fixup docs
* Add patch to stop us from breaking nouveau

Lyude Paul (5):
  drm/i915: Add support for panels with VESA backlights with PWM
enable/disable
  drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux
enable/brightness
  drm/dp: Disable unsupported features in
DP_EDP_BACKLIGHT_MODE_SET_REGISTER
  drm/dp, drm/i915: Add support for VESA backlights using PWM for
brightness control
  drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 .../drm/i915/display/intel_dp_aux_backlight.c | 81 ++
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |  5 +-
 include/drm/drm_dp_helper.h   |  7 +-
 4 files changed, 129 insertions(+), 46 deletions(-)

-- 
2.31.1

Re: [Intel-gfx] [PATCH 0/4] drm/i915: (near)atomic gamma LUT updates via vblank workers

[Lyude Paul]

Hey! I'll try to review this tomorrow or the day after if you're still
interested in me doing so :)

On Thu, 2021-10-21 at 01:33 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Finally got around to refreshing my vblank worker gamma LUT series.
> Since I started this (ahem, some years ago) Lyude took over the
> actual vblank worker implementation, mostly rewrote it I think,
> and landed it for use in nouveau. So now I'm just left with the
> easy task of using it for i915 gamma LUT updates. And so here
> we are.
> 
> CC: Lyude Paul 
> 
> Ville Syrjälä (4):
>   drm/i915: Move function prototypes to the correct header
>   drm/i915: Do vrr push before sampling the freame counter
>   drm/i915: Use vblank workers for gamma updates
>   drm/i915: Use unlocked register accesses for LUT loads
> 
>  drivers/gpu/drm/i915/display/intel_color.c    | 128 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c |  82 ++-
>  drivers/gpu/drm/i915/display/intel_crtc.h |   7 +
>  drivers/gpu/drm/i915/display/intel_display.c  |   9 +-
>  .../drm/i915/display/intel_display_types.h    |   8 ++
>  drivers/gpu/drm/i915/display/intel_dsb.c  |   4 +-
>  drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
>  drivers/gpu/drm/i915/display/intel_sprite.h   |   4 -
>  drivers/gpu/drm/i915/i915_trace.h |  42 ++
>  9 files changed, 203 insertions(+), 83 deletions(-)
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Weak parallel submission support for execlists

[John Harrison]

On 10/20/2021 14:47, Matthew Brost wrote:

A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for the existing (hopefully soon deprecated) bonding interface.

We perma-pin these execlists contexts to align with GuC implementation.

v2:
  (John Harrison)
   - Drop siblings array as num_siblings must be 1

Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 10 +++--
  drivers/gpu/drm/i915/gt/intel_context.c   |  4 +-
  .../drm/i915/gt/intel_execlists_submission.c  | 44 ++-
  drivers/gpu/drm/i915/gt/intel_lrc.c   |  2 +
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  2 -
  5 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb33d0322960..35e87a7d0ea9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,10 +570,6 @@ set_proto_ctx_engines_parallel_submit(struct 
i915_user_extension __user *base,
struct intel_engine_cs **siblings = NULL;
intel_engine_mask_t prev_mask;
  
-	/* FIXME: This is NIY for execlists */

-   if (!(intel_uc_uses_guc_submission(&i915->gt.uc)))
-   return -ENODEV;
-
if (get_user(slot, &ext->engine_index))
return -EFAULT;
  
@@ -583,6 +579,12 @@ set_proto_ctx_engines_parallel_submit(struct i915_user_extension __user *base,

if (get_user(num_siblings, &ext->num_siblings))
return -EFAULT;
  
+	if (!intel_uc_uses_guc_submission(&i915->gt.uc) && num_siblings != 1) {

+   drm_dbg(&i915->drm, "Only 1 sibling (%d) supported in non-GuC 
mode\n",
+   num_siblings);
+   return -EINVAL;
+   }
+
if (slot >= set->num_engines) {
drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
slot, set->num_engines);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5634d14052bc..1bec92e1d8e6 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -79,7 +79,8 @@ static int intel_context_active_acquire(struct intel_context 
*ce)
  
  	__i915_active_acquire(&ce->active);
  
-	if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))

+   if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine) ||
+   intel_context_is_parallel(ce))
return 0;
  
  	/* Preallocate tracking nodes */

@@ -563,7 +564,6 @@ void intel_context_bind_parent_child(struct intel_context 
*parent,
 * Callers responsibility to validate that this function is used
 * correctly but we use GEM_BUG_ON here ensure that they do.
 */
-   GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
GEM_BUG_ON(intel_context_is_pinned(parent));
GEM_BUG_ON(intel_context_is_child(parent));
GEM_BUG_ON(intel_context_is_pinned(child));
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index bedb80057046..2865b422300d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -927,8 +927,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
  
  static bool ctx_single_port_submission(const struct intel_context *ce)

  {
-   return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
-   intel_context_force_single_submission(ce));
+   return intel_context_force_single_submission(ce);

I think this is actually going to break GVT.

Not so much this change here but the whole use of single submission 
outside of GVT. It looks like the GVT driver overloads the single 
submission flag to tag requests that it owns. If we start using that 
flag elsewhere when GVT is active, I think that will cause much 
confusion within the GVT code.


The correct fix would be to create a new flag just for GVT usage 
alongside the single submission one. GVT would then set both but only 
check for its own private flag. The parallel code would obviously only 
set the existing single submission flag.




  }
  
  static bool can_merge_ctx(const struct intel_context *prev,

@@ -2598,6 +2597,46 @@ static void execlists_context_cancel_request(struct 
intel_context *ce,
  current->comm);
  }
  
+static struct intel_context *

+execlists_create_parallel(struct intel_engine_cs **engines,
+ unsigned int num_siblings,
+ unsigned int width)
+{
+   struct intel_context *parent = NULL, *ce, *err;
+   int i;
+
+   

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fb: Simplify modifier handling more

[Patchwork]

== Series Details ==

Series: drm/i915/fb: Simplify modifier handling more
URL   : https://patchwork.freedesktop.org/series/96308/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21451


Summary
---

  **FAILURE**

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

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

Participating hosts (38 -> 36)
--

  Additional (2): fi-ilk-650 fi-pnv-d510 
  Missing(4): fi-ctg-p8600 bat-adlp-4 bat-dg1-6 bat-dg1-5 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-pnv-d510:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-pnv-d510/igt@core_hotunp...@unbind-rebind.html

  
 Suppressed 

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

  * {igt@gem_exec_create@basic@smem}:
- fi-bsw-nick:[PASS][2] -> [DMESG-WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-bsw-nick/igt@gem_exec_create@ba...@smem.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-bsw-nick/igt@gem_exec_create@ba...@smem.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][4] ([fdo#109271]) +35 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

  * igt@debugfs_test@read_all_entries:
- fi-kbl-soraka:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982] / 
[i915#262])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][7] -> [INCOMPLETE][8] ([i915#2940])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-ilk-650: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-ilk-650/igt@kms_chamel...@dp-hpd-fast.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][10] ([fdo#109271]) +53 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][11] ([i915#4312])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-bsw-nick/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#1436] / 
[i915#3428] / [i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-bsw-n3050/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [DMESG-WARN][13] ([i915#4269]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
- {fi-hsw-gt1}:   [DMESG-WARN][15] ([i915#4290]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10792/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21451/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#4269]: 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

[John Harrison]

On 10/21/2021 23:23, Thomas Hellström wrote:

On 10/21/21 22:37, Matthew Brost wrote:

On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:

Hi, Matthew,

On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:

The hangcheck selftest blocks per engine resets by setting magic bits
in
the reset flags. This is incorrect for GuC submission because if the
GuC
fails to reset an engine we would like to do a full GT reset. Do no
set
these magic bits when using GuC submission.

Side note this lockless algorithm with magic bits to block resets
really
should be ripped out.


Lockless algorithm aside, from a quick look at the code in
intel_reset.c it appears to me like the interface that falls back to a
full GT reset is intel_gt_handle_error() whereas intel_engine_reset()
is explicitly intended to not do that, so is there a discrepancy
between GuC and non-GuC here?


With GuC submission when an engine reset fails, we get an engine reset
failure notification which triggers a full GT reset
(intel_guc_engine_failure_process_msg in intel_guc_submission.c). That
reset is blocking by setting these magic bits. Clearing the bits in this
function doesn't seem to unblock that reset either, the driver tries to
unload with a worker blocked, and results in the blow up. Something with
this lockless algorithm could be wrong as clear of the bit should
unlblock the reset but it is doesn't. We can look into that but in the
meantime we need to fix this test to be able to fail gracefully and not
crash CI.


Yeah, for that lockless algorithm if needed, we might want to use a 
ww_mutex per engine or something,
but point was that AFAICT at least one of the tests that set those 
flags explicitly tested the functionality that no other engines than 
the intended one was reset when the intel_engine_reset() function was 
used, and then if GuC submission doesn't honor that, wouldn't a better 
approach be to make a code comment around intel_engine_reset() to 
explain the differences and disable that particular test for GuC?. 
Also wouldn't we for example we see a duplicated full GT reset with 
GuC if intel_engine_reset() fails as part of the 
intel_gt_handle_error() function?

Re-reading this thread, I think there is a misunderstanding.

The selftests themselves have already been updated to support GuC based 
engine resets. That is done by submitting a hanging context and letting 
the GuC detect the hang and issue a reset. There is no mechanism 
available for i915 to directly issue or request an engine based reset 
(because i915 does not know what is running on any given engine at any 
given time, being disconnected from the scheduler).


So the tests are already correctly testing per engine resets and do not 
go anywhere near either intel_engine_reset() or intel_gt_handle_error() 
when GuC submission is used. The problem is what happens if the engine 
reset fails (which supposedly can only happen with broken hardware). In 
that scenario, there is an asynchronous message from GuC to i915 to 
notify us of the failure. The KMD receives that notification and then 
(eventually) calls intel_gt_handle_error() to issue a full GT reset. 
However, that is blocked because the selftest is not expecting it and 
has vetoed the possibility. A fix is required to allow that full GT 
reset to proceed and recover the hardware. At that point, the selftest 
should indeed fail because the reset was larger than expected. That 
should be handled by the fact the selftest issued work to other engines 
beside the target and expects those requests to complete successfully. 
In the case of the escalated GT reset, all those requests will be killed 
off as well. Thus the test will correctly fail.


John.




I guess we could live with the hangcheck test being disabled for guc 
submission until this is sorted out?


/Thomas




Matt


/Thomas



Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 7e2d99dd012d..90a03c60c80c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt
*gt, bool active)
 reset_engine_count = i915_reset_engine_count(global,
engine);
   st_engine_heartbeat_disable(engine);
-   set_bit(I915_RESET_ENGINE + id, >->reset.flags);
+   if (!using_guc)
+   set_bit(I915_RESET_ENGINE + id, >-

reset.flags);

 count = 0;
 do {
 struct i915_request *rq = NULL;
@@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt
*gt, bool active)
 if (err)
 break;
 } while (time_before(jiffies, end_time));
-   clear_bit(I

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

[John Harrison]

On 10/11/2021 16:47, Matthew Brost wrote:

The hangcheck selftest blocks per engine resets by setting magic bits in
the reset flags. This is incorrect for GuC submission because if the GuC
fails to reset an engine we would like to do a full GT reset. Do no set
these magic bits when using GuC submission.

Side note this lockless algorithm with magic bits to block resets really
should be ripped out.
As a first step, I am seeing a pointless BUILD_BUG but no BUILD_BUG at 
all for what really needs to be verified. Specifically, in 
intel_gt_handle_error, inside the engine reset loop, there is:
    BUILD_BUG_ON(I915_RESET_MODESET >= 
I915_RESET_ENGINE);


Given that the above two values are explicit #defines of '1' and '2'. 
I'm not seeing any value to this assert. On the other hand, what I am 
not seeing anywhere is an assert that 'I915_RESET_ENGINE + max_engine_id 
< I915_WEDGED_ON_INIT'. That being the thing that would actually go 
horribly wrong if the engine count increased too far. Seems like there 
should be one of those in intel_engines_init_mmio, using 
ARRAY_SIZE(intel_engines) as the max id.



It looks like 'busy-reset' and 'reset-idle' parts of 'igt_ctx_sseu' in 
gem/selftests/i915_gem_context.c also mess around with these flags and 
then try to issue a manual engine reset. Presumably those tests are also 
going to have issues with GuC submission.


The workarounds, mocs and reset selftests also do strange things. Those 
ones did get updated to support GuC submission by not attempting manual 
engine resets but using the GuC based hang detection instead. However, 
it seems like they would also suffer the same deadlock scenario if the 
GuC based reset were to fail.


I'm wondering if the better fix is to remove the use of the 
I915_RESET_ENGINE flags completely when using GuC submission. So far as 
I can tell, they are only used (outside of selftest hackery) in 
intel_gt_handle_error to guard against multiple concurrent resets within 
i915. Guarding against multiple concurrent resets in GuC is the GuC's 
job. That leaves GuC based engine reset concurrent with i915 based full 
GT reset. But that is fine because the full GT reset toasts all engines 
AND the GuC. So it doesn't matter what GuC might or might not have been 
doing at the time. The only other issue is multiple concurrent full GT 
resets, but that is protected against by I915_RESET_BACKOFF.


So my thought is to add an 'if(!guc_submission)' wrapper around the set 
and clear of the reset flags immediately before/after the call to 
intel_gt_reset_global().


Fixing it there means the selftests can do what they like with the flags 
without causing problems for GuC submission. It also means being one 
step closer to removing the dodgy lockless locking completely, at least 
when using GuC submission.


John.




Signed-off-by: Matthew Brost 
---
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 7e2d99dd012d..90a03c60c80c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -734,7 +734,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool 
active)
reset_engine_count = i915_reset_engine_count(global, engine);
  
  		st_engine_heartbeat_disable(engine);

-   set_bit(I915_RESET_ENGINE + id, >->reset.flags);
+   if (!using_guc)
+   set_bit(I915_RESET_ENGINE + id, >->reset.flags);
count = 0;
do {
struct i915_request *rq = NULL;
@@ -824,7 +825,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool 
active)
if (err)
break;
} while (time_before(jiffies, end_time));
-   clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
+   if (!using_guc)
+   clear_bit(I915_RESET_ENGINE + id, >->reset.flags);
st_engine_heartbeat_enable(engine);
pr_info("%s: Completed %lu %s resets\n",
engine->name, count, active ? "active" : "idle");
@@ -1042,7 +1044,8 @@ static int __igt_reset_engines(struct intel_gt *gt,
yield(); /* start all threads before we begin */
  
  		st_engine_heartbeat_disable_no_pm(engine);

-   set_bit(I915_RESET_ENGINE + id, >->reset.flags);
+   if (!using_guc)
+   set_bit(I915_RESET_ENGINE + id, >->reset.flags);
do {
struct i915_request *rq = NULL;
struct intel_selftest_saved_policy saved;
@@ -1165,7 +1168,8 @@ static int __igt_reset_engines(struct intel_gt *gt,
if (err)
break;
} while (time_before(jiffies, end_time)

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

On 2021-10-12 16:58, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Tuesday, October 12, 2021 4:01 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; 
>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>> shashank.sha...@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue,  7 Sep 2021 03:08:43 +0530
>> Uma Shankar  wrote:
>>

snip

>>> +
>>> +
>>> +This patch series adds properties for plane color features. It adds 
>>> +properties for degamma used to linearize data and CSC used for 
>>> +gamut conversion. It also includes Gamma support used to again 
>>> +non-linearize data as per panel supported color space. These can be 
>>> +utilize by user space to convert planes from one format to another, 
>>> +one color space to another etc.
>>
>> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
> 
> This is great to hear that we are aligned wrt how the pipeline should work.
> 
> Thanks Pekka for taking time out and providing the feedback.
> 
> @harry.wentl...@amd.com We can work together and build our design to 
> accommodate
> both Intel and AMD's hardware needs. This will also make things generic 
> enough for any
> other hardware vendor as well.
> 

Definitely. I think we're on the right path. Personally I would like to
arrive at a solid KMS definition for this by the time Weston guys
get to the HDR enablement with SW composition so we can start looking
at KMS offloading for HDR planes as next step.

Harry

> Thanks & Regards,
> Uma Shankar
> 
>>> +
>>> +Userspace can take smart blending decisions and utilize these 
>>> +hardware supported plane color features to get accurate color 
>>> +profile. The same can help in consistent color quality from source 
>>> +to panel taking advantage of advanced color features in hardware.
>>> +
>>> +These patches add the property interfaces and enable helper functions.
>>> +This series adds Intel's XE_LPD hw specific plane gamma feature. We 
>>> +can build up and add other platform/hardware specific 
>>> +implementation on top of this series.
>>> +
>>> +Credits: Special mention and credits to Ville Syrjala for coming up 
>>> +with a design for this feature and inputs. This series is based on 
>>> +his original design and idea.
>>
>>
>> Thanks,
>> pq

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Disable all planes before modesetting any pipes

[Souza, Jose]

On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's disable planes on all pipes affected by the modeset before
> we start doing the actual modeset. This means we have less
> random planes enabled during the modeset, and it also mirrors
> what we already do when enabling pipes on skl+ since we enable
> planes on all pipes as the very last step. As a bonus we also
> nuke a bunch og bigjoiner special casing.
> 
> I've occasionally pondered about going even furher here and
> doing the pre_plane_update() stuff for all pipes first, then
> actually disabling the planes, and finally running the rest
> of the modeset sequence. This would potentially allow
> parallelizing all the extra vblank waits across multiple pipes,
> and would make the plane disable even more atomic. But let's
> go one step a time here.
> 

Reviewed-by: José Roberto de Souza 

> Cc: José Roberto de Souza 
> Reviewed-by: Manasi Navare 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3d2a1cba78c1..1d920ba83521 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8251,18 +8251,13 @@ static void intel_old_crtc_state_disables(struct 
> intel_atomic_state *state,
>  
>   drm_WARN_ON(&dev_priv->drm, old_crtc_state->bigjoiner_slave);
>  
> - intel_crtc_disable_planes(state, crtc);
> -
>   /*
>* We still need special handling for disabling bigjoiner master
>* and slaves since for slave we do not have encoder or plls
>* so we dont need to disable those.
>*/
> - if (old_crtc_state->bigjoiner) {
> - intel_crtc_disable_planes(state,
> -   
> old_crtc_state->bigjoiner_linked_crtc);
> + if (old_crtc_state->bigjoiner)
>   old_crtc_state->bigjoiner_linked_crtc->active = false;
> - }
>  
>   /*
>* We need to disable pipe CRC before disabling the pipe,
> @@ -8288,6 +8283,18 @@ static void intel_commit_modeset_disables(struct 
> intel_atomic_state *state)
>   u32 handled = 0;
>   int i;
>  
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (!intel_crtc_needs_modeset(new_crtc_state))
> + continue;
> +
> + if (!old_crtc_state->hw.active)
> + continue;
> +
> + intel_pre_plane_update(state, crtc);
> + intel_crtc_disable_planes(state, crtc);
> + }
> +
>   /* Only disable port sync and MST slaves */
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>   new_crtc_state, i) {
> @@ -8306,7 +8313,6 @@ static void intel_commit_modeset_disables(struct 
> intel_atomic_state *state)
>   !intel_dp_mst_is_slave_trans(old_crtc_state))
>   continue;
>  
> - intel_pre_plane_update(state, crtc);
>   intel_old_crtc_state_disables(state, old_crtc_state,
> new_crtc_state, crtc);
>   handled |= BIT(crtc->pipe);
> @@ -8320,14 +8326,6 @@ static void intel_commit_modeset_disables(struct 
> intel_atomic_state *state)
>   old_crtc_state->bigjoiner_slave)
>   continue;
>  
> - intel_pre_plane_update(state, crtc);
> - if (old_crtc_state->bigjoiner) {
> - struct intel_crtc *slave =
> - old_crtc_state->bigjoiner_linked_crtc;
> -
> - intel_pre_plane_update(state, slave);
> - }
> -
>   if (old_crtc_state->hw.active)
>   intel_old_crtc_state_disables(state, old_crtc_state,
> new_crtc_state, crtc);

Re: [Intel-gfx] [PATCH v2 2/9] Revert "drm/i915/display: Disable audio, DRRS and PSR before planes"

[Souza, Jose]

On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Disabling planes in the middle of the modeset seuqnece does not make
> sense since userspace can anyway disable planes before the modeset
> even starts. So when the modeset seuqence starts the set of enabled
> planes is entirely arbitrary. Trying to sprinkle the plane disabling
> into the modeset sequence just means more randomness and potential
> for hard to reproduce bugs.
> 
> So it makes most sense to just disable all planes first so that the
> rest of the modeset sequence remains identical regardless of which
> planes happen to be enabled by userspace at the time.
> 
> This reverts commit 84030adb9e27d202a66022488bf0349a8bd45213.

With the 'drm/i915/psr: Disable PSR before modesets turn off all planes' it is 
now okay to revert this.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 30 +++
>  drivers/gpu/drm/i915/display/intel_display.c  | 24 ---
>  .../drm/i915/display/intel_display_types.h|  4 ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 14 ++---
>  4 files changed, 13 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ab52eab346fe..6c11992496f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3061,6 +3061,12 @@ static void intel_disable_ddi_dp(struct 
> intel_atomic_state *state,
>  
>   intel_dp->link_trained = false;
>  
> + if (old_crtc_state->has_audio)
> + intel_audio_codec_disable(encoder,
> +   old_crtc_state, old_conn_state);
> +
> + intel_drrs_disable(intel_dp, old_crtc_state);
> + intel_psr_disable(intel_dp, old_crtc_state);
>   intel_edp_backlight_off(old_conn_state);
>   /* Disable the decompression in DP Sink */
>   intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
> @@ -3078,6 +3084,10 @@ static void intel_disable_ddi_hdmi(struct 
> intel_atomic_state *state,
>   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>   struct drm_connector *connector = old_conn_state->connector;
>  
> + if (old_crtc_state->has_audio)
> + intel_audio_codec_disable(encoder,
> +   old_crtc_state, old_conn_state);
> +
>   if (!intel_hdmi_handle_sink_scrambling(encoder, connector,
>  false, false))
>   drm_dbg_kms(&i915->drm,
> @@ -3085,25 +3095,6 @@ static void intel_disable_ddi_hdmi(struct 
> intel_atomic_state *state,
>   connector->base.id, connector->name);
>  }
>  
> -static void intel_pre_disable_ddi(struct intel_atomic_state *state,
> -   struct intel_encoder *encoder,
> -   const struct intel_crtc_state *old_crtc_state,
> -   const struct drm_connector_state 
> *old_conn_state)
> -{
> - struct intel_dp *intel_dp;
> -
> - if (old_crtc_state->has_audio)
> - intel_audio_codec_disable(encoder, old_crtc_state,
> -   old_conn_state);
> -
> - if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
> - return;
> -
> - intel_dp = enc_to_intel_dp(encoder);
> - intel_drrs_disable(intel_dp, old_crtc_state);
> - intel_psr_disable(intel_dp, old_crtc_state);
> -}
> -
>  static void intel_disable_ddi(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> const struct intel_crtc_state *old_crtc_state,
> @@ -4437,7 +4428,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   encoder->enable = intel_enable_ddi;
>   encoder->pre_pll_enable = intel_ddi_pre_pll_enable;
>   encoder->pre_enable = intel_ddi_pre_enable;
> - encoder->pre_disable = intel_pre_disable_ddi;
>   encoder->disable = intel_disable_ddi;
>   encoder->post_disable = intel_ddi_post_disable;
>   encoder->update_pipe = intel_ddi_update_pipe;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5201d6cdd5db..3d2a1cba78c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1693,28 +1693,6 @@ static void intel_encoders_enable(struct 
> intel_atomic_state *state,
>   }
>  }
>  
> -static void intel_encoders_pre_disable(struct intel_atomic_state *state,
> -struct intel_crtc *crtc)
> -{
> - const struct intel_crtc_state *old_crtc_state =
> - intel_atomic_get_old_crtc_state(state, crtc);
> - const struct drm_connector_state *old_conn_state;
> - struct dr

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

On 2021-10-14 15:44, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Wednesday, October 13, 2021 2:01 PM
>> To: Shankar, Uma 
>> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- 
>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>> shashank.sha...@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 12 Oct 2021 20:58:27 +
>> "Shankar, Uma"  wrote:
>>
 -Original Message-
 From: Pekka Paalanen 
 Sent: Tuesday, October 12, 2021 4:01 PM
 To: Shankar, Uma 
 Cc: intel-gfx@lists.freedesktop.org; 
 dri-de...@lists.freedesktop.org; harry.wentl...@amd.com; 
 ville.syrj...@linux.intel.com; brian.star...@arm.com; 
 sebast...@sebastianwick.net; shashank.sha...@amd.com
 Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware 
 Pipeline

 On Tue,  7 Sep 2021 03:08:43 +0530 Uma Shankar 
  wrote:

> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls out the 
> details or interfaces created and the intended purpose.
>
> Credits: Ville Syrjälä 
> Signed-off-by: Uma Shankar 
> ---
>  Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> +++
>  1 file changed, 167 insertions(+)  create mode 100644 
> Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index ..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==
> +Display Color Pipeline: Proposed DRM Properties
>>
>> ...
>>
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.

 As you want to produce light-linear values, you use EOTF or inverse OETF.

 The term OETF has a built-in assumption that that happens in a camera:
 it takes in light and produces and electrical signal. Lately I 
 have personally started talking about non-linear encoding of color 
 values, since EOTF is often associated with displays if nothing 
 else is said (taking
>> in an electrical signal and producing light).

 So this would be decoding the color values into light-linear color 
 values. That is what an EOTF does, yes, but I feel there is a 
 nuanced difference. A piece of equipment implements an EOTF by 
 turning an electrical signal into light, hence EOTF often refers 
 to specific equipment. You could talk about content EOTF to denote 
 content value encoding, as opposed to output or display EOTF, but 
 that might be confusing if you look at e.g. the diagrams in
 BT.2100: is it the EOTF
>> or is it the inverse OETF? Is the (inverse?) OOTF included?

 So I try to side-step those questions by talking about encoding.
>>>
>>> The idea here is that frame buffer presented to display plane engine 
>>> will be non-
>> linear.
>>> So output of a media decode should result in content with EOTF applied.
>>
>> Hi,
>>
>> sure, but the question is: which EOTF. There can be many different 
>> things called "EOTF" in a single pipeline, and then it's up to the 
>> document writer to make the difference between them. Comparing two 
>> documents with different conventions causes a lot of confusion in my 
>> personal experience, so it is good to define the concepts more carefully.
> 
> Hi Pekka,
> I think you have given some nice inputs to really deep dive and document here.
> Will update this with the right expectations wrt what transfer functions to 
> be used at various stages in the operation pipeline.
> 
>>> So output of a media decode should result in content with EOTF applied.
>>
>> I suspect you have it backwards. Media decode produces electrical
>> (non-linear) pixel color values. If EOTF was applied, they would be 
>> linear instead (and require more memory to achieve the same visual 
>> precision).
>>
>> If you want to put it this way, you could say "with inverse EOTF 
>> applied", but that might be slightly confusing because it is already 
>> baked in to the video, it's not something a media decoder has to 
>> specifically apply, I think. However, the (inverse) EOTF in this case is the 
>> content EOTF, not the display EOTF.
>>
>> If content and display EOTF differ, then one must apply first content 
>> EOTF and then inverse display EOTF to get values that are correctly 
>> encoded for the display. (This is necessary but not sufficient in
>> general.)

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

[Mark Yacoub]

new patch: https://patchwork.freedesktop.org/series/96314/

On Tue, Oct 26, 2021 at 3:24 PM Mark Yacoub  wrote:
>
> On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel  wrote:
> >
> > Dear Mark,
> >
> >
> > Thank you for your patch.
> >
> > On 13.10.21 20:12, Mark Yacoub wrote:
> > > From: Mark Yacoub 
> > >
> > > [Why]
> > > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > > or Degamma props in the new CRTC state, allowing any invalid size to
> > > be passed on.
> > > 2. Each driver has its own LUT size, which could also be different for
> > > legacy users.
> >
> > How can the problem be reproduced?
> It was caught using igt@kms_color@pipe-A-invalid-gamma-lut-sizes.
> it validates that drivers will only LUTs of their expected size not
> any random (smaller or larger) number.
> >
> > > [How]
> > > 1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
> > > assigned by the driver when it's initializing its color and CTM
> > > management.
> > > 2. Create drm_atomic_helper_check_crtc which is called by
> > > drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
> > > they match the sizes in the new CRTC state.
> > > 3. Rename older lut checks that test for the color channels to indicate
> > > it's a channel check. It's not included in drm_atomic_helper_check_crtc
> > > as it's hardware specific and is to be called by the driver.
> > > 4. As the LUT size check now happens in drm_atomic_helper_check, remove
> > > the lut check in intel_color.c
> > >
> > > Fixes: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
> >
> > If I am not mistaken, the Fixes tag is used for commits I believe. Maybe
> > use Resolves or something similar?
> fixed!
> >
> > > Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)
> >
> > Please add a space before the (.
my apologies i missed this. I'll update it if another version is
needed or if the committer can do it for me when they apply it.
> >
> > How did you test this?
> smoke test on both MTK and TGL devices along with running
> igt@kms_color on both devices.
> >
> > > v1:
> > > 1. Fix typos
> > > 2. Remove the LUT size check from intel driver
> > > 3. Rename old LUT check to indicate it's a channel change
> > >
> > > Signed-off-by: Mark Yacoub 
> > > ---
> > >   drivers/gpu/drm/drm_atomic_helper.c| 60 ++
> > >   drivers/gpu/drm/drm_color_mgmt.c   | 14 ++---
> > >   drivers/gpu/drm/i915/display/intel_color.c | 14 ++---
> > >   include/drm/drm_atomic_helper.h|  1 +
> > >   include/drm/drm_color_mgmt.h   |  7 +--
> > >   include/drm/drm_crtc.h | 11 
> > >   6 files changed, 89 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index bc3487964fb5e..5feb2ad0209c3 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -929,6 +929,62 @@ drm_atomic_helper_check_planes(struct drm_device 
> > > *dev,
> > >   }
> > >   EXPORT_SYMBOL(drm_atomic_helper_check_planes);
> > >
> > > +/**
> > > + * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
> > > + * @state: the driver state object
> > > + *
> > > + * Check the CRTC state object such as the Gamma/Degamma LUT sizes if 
> > > the new
> > > + * state holds them.
> > > + *
> > > + * RETURNS:
> > > + * Zero for success or -errno
> > > + */
> > > +int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
> > > +{
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *new_crtc_state;
> > > + int i;
> > > +
> > > + for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> > > + if (new_crtc_state->color_mgmt_changed &&
> > > + new_crtc_state->gamma_lut) {
> > > + uint64_t supported_lut_size = crtc->gamma_lut_size;
> > > + uint32_t supported_legacy_lut_size = 
> > > crtc->gamma_size;
> > > + uint32_t new_state_lut_size =
> > > + 
> > > drm_color_lut_size(new_crtc_state->gamma_lut);
> > > +
> > > + if (new_state_lut_size != supported_lut_size &&
> > > + new_state_lut_size != 
> > > supported_legacy_lut_size) {
> > > + drm_dbg_state(
> > > + state->dev,
> > > + "Invalid Gamma LUT size. Should be 
> > > %u (or %u for legacy) but got %u.\n",
> > > + supported_lut_size,
> > > + supported_legacy_lut_size,
> > > + new_state_lut_size);
> > > + return -EINVAL;
> > > + }
> > > + }
> > > +
> > > + if (new_crtc_state->color_mgmt_changed &&
> > > + new_crtc_state->dega

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

[Mark Yacoub]

On Mon, Oct 25, 2021 at 9:26 PM Sean Paul  wrote:
>
> On Wed, Oct 13, 2021 at 02:12:20PM -0400, Mark Yacoub wrote:
> > From: Mark Yacoub 
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in the new CRTC state, allowing any invalid size to
> > be passed on.
> > 2. Each driver has its own LUT size, which could also be different for
> > legacy users.
> >
> > [How]
> > 1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
> > assigned by the driver when it's initializing its color and CTM
> > management.
> > 2. Create drm_atomic_helper_check_crtc which is called by
> > drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
> > they match the sizes in the new CRTC state.
> > 3. Rename older lut checks that test for the color channels to indicate
> > it's a channel check. It's not included in drm_atomic_helper_check_crtc
> > as it's hardware specific and is to be called by the driver.
> > 4. As the LUT size check now happens in drm_atomic_helper_check, remove
> > the lut check in intel_color.c
>
> I'd probably split the rename out from the crtc check since they're only
> tangentially related.
done.
>
> >
> > Fixes: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
> > Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)
> >
> > v1:
> > 1. Fix typos
> > 2. Remove the LUT size check from intel driver
> > 3. Rename old LUT check to indicate it's a channel change
> >
> > Signed-off-by: Mark Yacoub 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c| 60 ++
> >  drivers/gpu/drm/drm_color_mgmt.c   | 14 ++---
> >  drivers/gpu/drm/i915/display/intel_color.c | 14 ++---
> >  include/drm/drm_atomic_helper.h|  1 +
> >  include/drm/drm_color_mgmt.h   |  7 +--
> >  include/drm/drm_crtc.h | 11 
> >  6 files changed, 89 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index bc3487964fb5e..5feb2ad0209c3 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -929,6 +929,62 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_check_planes);
> >
> > +/**
> > + * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
> > + * @state: the driver state object
> > + *
> > + * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the 
> > new
> > + * state holds them.
> > + *
> > + * RETURNS:
> > + * Zero for success or -errno
> > + */
> > +int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *new_crtc_state;
> > + int i;
> > +
> > + for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->color_mgmt_changed &&
> > + new_crtc_state->gamma_lut) {
> > + uint64_t supported_lut_size = crtc->gamma_lut_size;
> > + uint32_t supported_legacy_lut_size = crtc->gamma_size;
> > + uint32_t new_state_lut_size =
> > + drm_color_lut_size(new_crtc_state->gamma_lut);
> > +
> > + if (new_state_lut_size != supported_lut_size &&
> > + new_state_lut_size != supported_legacy_lut_size) {
> > + drm_dbg_state(
> > + state->dev,
> > + "Invalid Gamma LUT size. Should be %u 
> > (or %u for legacy) but got %u.\n",
> > + supported_lut_size,
> > + supported_legacy_lut_size,
> > + new_state_lut_size);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + if (new_crtc_state->color_mgmt_changed &&
> > + new_crtc_state->degamma_lut) {
> > + uint32_t new_state_lut_size =
> > + 
> > drm_color_lut_size(new_crtc_state->degamma_lut);
> > + uint64_t supported_lut_size = crtc->degamma_lut_size;
> > +
> > + if (new_state_lut_size != supported_lut_size) {
> > + drm_dbg_state(
> > + state->dev,
> > + "Invalid Degamma LUT size. Should be 
> > %u but got %u.\n",
> > + supported_lut_size, 
> > new_state_lut_size);
> > + return -EINVAL;
> > + }
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_check_crtcs);
> > +
> >  /**
> >   * drm_atomic_helper_check - validate state object
> >   * @dev: DRM device
> > @@ -

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

[Mark Yacoub]

On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel  wrote:
>
> Dear Mark,
>
>
> Thank you for your patch.
>
> On 13.10.21 20:12, Mark Yacoub wrote:
> > From: Mark Yacoub 
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in the new CRTC state, allowing any invalid size to
> > be passed on.
> > 2. Each driver has its own LUT size, which could also be different for
> > legacy users.
>
> How can the problem be reproduced?
It was caught using igt@kms_color@pipe-A-invalid-gamma-lut-sizes.
it validates that drivers will only LUTs of their expected size not
any random (smaller or larger) number.
>
> > [How]
> > 1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
> > assigned by the driver when it's initializing its color and CTM
> > management.
> > 2. Create drm_atomic_helper_check_crtc which is called by
> > drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
> > they match the sizes in the new CRTC state.
> > 3. Rename older lut checks that test for the color channels to indicate
> > it's a channel check. It's not included in drm_atomic_helper_check_crtc
> > as it's hardware specific and is to be called by the driver.
> > 4. As the LUT size check now happens in drm_atomic_helper_check, remove
> > the lut check in intel_color.c
> >
> > Fixes: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
>
> If I am not mistaken, the Fixes tag is used for commits I believe. Maybe
> use Resolves or something similar?
fixed!
>
> > Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)
>
> Please add a space before the (.
>
> How did you test this?
smoke test on both MTK and TGL devices along with running
igt@kms_color on both devices.
>
> > v1:
> > 1. Fix typos
> > 2. Remove the LUT size check from intel driver
> > 3. Rename old LUT check to indicate it's a channel change
> >
> > Signed-off-by: Mark Yacoub 
> > ---
> >   drivers/gpu/drm/drm_atomic_helper.c| 60 ++
> >   drivers/gpu/drm/drm_color_mgmt.c   | 14 ++---
> >   drivers/gpu/drm/i915/display/intel_color.c | 14 ++---
> >   include/drm/drm_atomic_helper.h|  1 +
> >   include/drm/drm_color_mgmt.h   |  7 +--
> >   include/drm/drm_crtc.h | 11 
> >   6 files changed, 89 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index bc3487964fb5e..5feb2ad0209c3 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -929,6 +929,62 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
> >   }
> >   EXPORT_SYMBOL(drm_atomic_helper_check_planes);
> >
> > +/**
> > + * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
> > + * @state: the driver state object
> > + *
> > + * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the 
> > new
> > + * state holds them.
> > + *
> > + * RETURNS:
> > + * Zero for success or -errno
> > + */
> > +int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *new_crtc_state;
> > + int i;
> > +
> > + for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> > + if (new_crtc_state->color_mgmt_changed &&
> > + new_crtc_state->gamma_lut) {
> > + uint64_t supported_lut_size = crtc->gamma_lut_size;
> > + uint32_t supported_legacy_lut_size = crtc->gamma_size;
> > + uint32_t new_state_lut_size =
> > + drm_color_lut_size(new_crtc_state->gamma_lut);
> > +
> > + if (new_state_lut_size != supported_lut_size &&
> > + new_state_lut_size != supported_legacy_lut_size) {
> > + drm_dbg_state(
> > + state->dev,
> > + "Invalid Gamma LUT size. Should be %u 
> > (or %u for legacy) but got %u.\n",
> > + supported_lut_size,
> > + supported_legacy_lut_size,
> > + new_state_lut_size);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + if (new_crtc_state->color_mgmt_changed &&
> > + new_crtc_state->degamma_lut) {
> > + uint32_t new_state_lut_size =
> > + 
> > drm_color_lut_size(new_crtc_state->degamma_lut);
> > + uint64_t supported_lut_size = crtc->degamma_lut_size;
> > +
> > + if (new_state_lut_size != supported_lut_size) {
> > + drm_dbg_state(
> > + state->dev,
> > + "Invalid Degamma LUT size. Should be 

[Intel-gfx] [PATCH v3 2/3] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

[Mark Yacoub]

From: Mark Yacoub 

[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.

[How]
1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
assigned by the driver when it's initializing its color and CTM
management.
2. Create drm_atomic_helper_check_crtc which is called by
drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
they match the sizes in the new CRTC state.
3. As the LUT size check now happens in drm_atomic_helper_check, remove
the lut check in intel_color.c

Resolves: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)

v2:
1. Remove the rename to a parent commit.
2. Create a drm drm_check_lut_size instead of intel only function.

v1:
1. Fix typos
2. Remove the LUT size check from intel driver
3. Rename old LUT check to indicate it's a channel change

Signed-off-by: Mark Yacoub 
---
 drivers/gpu/drm/drm_atomic_helper.c| 56 ++
 drivers/gpu/drm/drm_color_mgmt.c   |  2 +
 drivers/gpu/drm/i915/display/intel_color.c | 39 ---
 include/drm/drm_atomic_helper.h|  1 +
 include/drm/drm_color_mgmt.h   | 13 +
 include/drm/drm_crtc.h | 11 +
 6 files changed, 102 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5e..c565b3516cce9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -929,6 +929,58 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_helper_check_planes);
 
+/**
+ * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
+ * @state: the driver state object
+ *
+ * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the new
+ * state holds them.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *new_crtc_state;
+   int i;
+
+   for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
+   if (new_crtc_state->color_mgmt_changed &&
+   new_crtc_state->gamma_lut) {
+   if (drm_check_lut_size(new_crtc_state->gamma_lut,
+  crtc->gamma_lut_size) ||
+   drm_check_lut_size(new_crtc_state->gamma_lut,
+  crtc->gamma_size)) {
+   drm_dbg_state(
+   state->dev,
+   "Invalid Gamma LUT size. Should be %u 
(or %u for legacy) but got %u.\n",
+   crtc->gamma_lut_size, crtc->gamma_size,
+   drm_color_lut_size(
+   new_crtc_state->gamma_lut));
+   return -EINVAL;
+   }
+   }
+
+   if (new_crtc_state->color_mgmt_changed &&
+   new_crtc_state->degamma_lut) {
+   if (drm_check_lut_size(new_crtc_state->degamma_lut,
+  crtc->degamma_lut_size)) {
+   drm_dbg_state(
+   state->dev,
+   "Invalid DeGamma LUT size. Should be %u 
but got %u.\n",
+   crtc->degamma_lut_size,
+   drm_color_lut_size(
+   new_crtc_state->degamma_lut));
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_crtcs);
+
 /**
  * drm_atomic_helper_check - validate state object
  * @dev: DRM device
@@ -974,6 +1026,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
 
+   ret = drm_atomic_helper_check_crtcs(state);
+   if (ret)
+   return ret;
+
if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(dev, 
state);
 
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 6f4e04746d90f..6bb59645a75bc 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -166,6 +166,7 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
struct drm_mode_config *config = &dev->mode_config;
 
if (degamma_lut_size) {
+   crtc->degamma_lut_size = degamma_lut_size;
drm_object_attach_property(&crtc->

[Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

[Mark Yacoub]

From: Mark Yacoub 

[Why]
This function and enum do not do generic checking on the luts but they
test color channels in the LUTs.
Keeping the name explicit as more generic LUT checks will follow.

Tested on Eldrid ChromeOS (TGL).

Signed-off-by: Mark Yacoub 
---
 drivers/gpu/drm/drm_color_mgmt.c   | 12 ++--
 drivers/gpu/drm/i915/display/intel_color.c | 10 +-
 include/drm/drm_color_mgmt.h   |  7 ---
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6c..6f4e04746d90f 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -585,17 +585,17 @@ int drm_plane_create_color_properties(struct drm_plane 
*plane,
 EXPORT_SYMBOL(drm_plane_create_color_properties);
 
 /**
- * drm_color_lut_check - check validity of lookup table
+ * drm_color_lut_channels_check - check validity of the channels in the lookup 
table
  * @lut: property blob containing LUT to check
  * @tests: bitmask of tests to run
  *
- * Helper to check whether a userspace-provided lookup table is valid and
- * satisfies hardware requirements.  Drivers pass a bitmask indicating which of
- * the tests in &drm_color_lut_tests should be performed.
+ * Helper to check whether each color channel of userspace-provided lookup 
table is valid and
+ * satisfies hardware requirements. Drivers pass a bitmask indicating which of 
in
+ * &drm_color_lut_channels_tests should be performed.
  *
  * Returns 0 on success, -EINVAL on failure.
  */
-int drm_color_lut_check(const struct drm_property_blob *lut, u32 tests)
+int drm_color_lut_channels_check(const struct drm_property_blob *lut, u32 
tests)
 {
const struct drm_color_lut *entry;
int i;
@@ -625,4 +625,4 @@ int drm_color_lut_check(const struct drm_property_blob 
*lut, u32 tests)
 
return 0;
 }
-EXPORT_SYMBOL(drm_color_lut_check);
+EXPORT_SYMBOL(drm_color_lut_channels_check);
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index dab892d2251ba..4bb1bc76c4de9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1285,7 +1285,7 @@ static int check_luts(const struct intel_crtc_state 
*crtc_state)
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
const struct drm_property_blob *degamma_lut = 
crtc_state->hw.degamma_lut;
int gamma_length, degamma_length;
-   u32 gamma_tests, degamma_tests;
+   u32 gamma_channels_tests, degamma_channels_tests;
 
/* Always allow legacy gamma LUT with no further checking. */
if (crtc_state_is_legacy_gamma(crtc_state))
@@ -1300,15 +1300,15 @@ static int check_luts(const struct intel_crtc_state 
*crtc_state)
 
degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
-   degamma_tests = INTEL_INFO(dev_priv)->color.degamma_lut_tests;
-   gamma_tests = INTEL_INFO(dev_priv)->color.gamma_lut_tests;
+   degamma_channels_tests = INTEL_INFO(dev_priv)->color.degamma_lut_tests;
+   gamma_channels_tests = INTEL_INFO(dev_priv)->color.gamma_lut_tests;
 
if (check_lut_size(degamma_lut, degamma_length) ||
check_lut_size(gamma_lut, gamma_length))
return -EINVAL;
 
-   if (drm_color_lut_check(degamma_lut, degamma_tests) ||
-   drm_color_lut_check(gamma_lut, gamma_tests))
+   if (drm_color_lut_channels_check(degamma_lut, degamma_channels_tests) ||
+   drm_color_lut_channels_check(gamma_lut, gamma_channels_tests))
return -EINVAL;
 
return 0;
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 81c298488b0c8..cb1bf361ad3e3 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -94,12 +94,12 @@ int drm_plane_create_color_properties(struct drm_plane 
*plane,
  enum drm_color_range default_range);
 
 /**
- * enum drm_color_lut_tests - hw-specific LUT tests to perform
+ * enum drm_color_lut_channels_tests - hw-specific LUT tests to perform
  *
  * The drm_color_lut_check() function takes a bitmask of the values here to
  * determine which tests to apply to a userspace-provided LUT.
  */
-enum drm_color_lut_tests {
+enum drm_color_lut_channels_tests {
/**
 * @DRM_COLOR_LUT_EQUAL_CHANNELS:
 *
@@ -119,5 +119,6 @@ enum drm_color_lut_tests {
DRM_COLOR_LUT_NON_DECREASING = BIT(1),
 };
 
-int drm_color_lut_check(const struct drm_property_blob *lut, u32 tests);
+int drm_color_lut_channels_check(const struct drm_property_blob *lut,
+u32 tests);
 #endif
-- 
2.33.0.1079.g6e70778dc9-goog

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

Thanks, Uma, for the updated patches. I'm finally finding
time to go through them.

On 2021-10-15 03:42, Pekka Paalanen wrote:
> On Thu, 14 Oct 2021 19:44:25 +
> "Shankar, Uma"  wrote:
> 
>>> -Original Message-
>>> From: Pekka Paalanen 
>>> Sent: Wednesday, October 13, 2021 2:01 PM
>>> To: Shankar, Uma 
>>> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- 
>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>>> shashank.sha...@amd.com
>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>>
>>> On Tue, 12 Oct 2021 20:58:27 +
>>> "Shankar, Uma"  wrote:
>>>   
> -Original Message-
> From: Pekka Paalanen 
> Sent: Tuesday, October 12, 2021 4:01 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; harry.wentl...@amd.com; 
> ville.syrj...@linux.intel.com; brian.star...@arm.com; 
> sebast...@sebastianwick.net; shashank.sha...@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware 
> Pipeline
>
> On Tue,  7 Sep 2021 03:08:43 +0530 Uma Shankar 
>  wrote:
>  
>> This is a RFC proposal for plane color hardware blocks.
>> It exposes the property interface to userspace and calls out the 
>> details or interfaces created and the intended purpose.
>>
>> Credits: Ville Syrjälä 
>> Signed-off-by: Uma Shankar 
>> ---
>>  Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>> +++
>>  1 file changed, 167 insertions(+)  create mode 100644 
>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>
>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>> new file mode 100644
>> index ..0d1ca858783b
>> --- /dev/null
>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>> @@ -0,0 +1,167 @@
>> +==
>> +Display Color Pipeline: Proposed DRM Properties  
> 
> ...
> 
>>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and 
>>> the OOTF", although I find those diagrams somewhat confusing still. It 
>>> does not seem to clearly account for transmission non-linear encoding being 
>>> different from the display EOTF.
>>>
>>> Different documents use OOTF to refer to different things. Then there 
>>> is also the fundamental difference between PQ and HLG systems, where 
>>> OOTF is by definition in different places of the 
>>> camera-transmission-display pipeline.  
>>
>> Agree this is a bit confusing, I admit I was much more confused than what 
>> you were for sure.
>> Will do some research to get my understanding in place. Thanks for all the 
>> inputs.
> 
> I'm sure I was at least equally confused or even more at the start. I
> have just had a year of casual reading, discussions, and a W3C workshop
> attendance to improve my understanding. :-)
> 
> Now I know enough to be dangerous.
> 
> ...
> 
>> +
>> +UAPI Name: PLANE_DEGAMMA_MODE
>> +Description: Enum property with values as blob_id's which 
>> +advertizes
>> the  
>
> Is enum with blob id values even a thing?  

 Yeah we could have. This is a dynamic enum created with blobs. Each 
 entry contains the data structure to extract the full color 
 capabilities of the hardware. It’s a very interesting play with 
 blobs (@ville.syrj...@linux.intel.com brainchild)  
>>>
>>> Yes, I think I can imagine how that works. The blobs are created 
>>> immutable, unable to change once the plane has been advertised to 
>>> userspace, because their IDs are used as enum values. But that is ok, 
>>> because the blob describes capabilities that cannot change during the 
>>> device's lifetime... or can they? What if you would want to extend the 
>>> blob format, do you need a KMS client cap to change the format which 
>>> would be impossible because you can't change an enum definition after it 
>>> has been installed so you cannot swap the blob to a new one?
>>>
>>> This also relies on enums being identified by their string names, 
>>> because the numerical value is not a constant but a blob ID and gets 
>>> determined when the immutable blob is created.
>>>
>>> Did I understand correctly?  
>>
>> Yes that’s right. We are not expecting these structures to change as
>> they represent the platforms capabilities.
> 
> Until there comes a new platform whose capabilities you cannot quite
> describe with the existing structure. What's the plan to deal with that?
> A new enum value, like LUT2 instead of LUT? I suppose that works.
> 

See my comment on the coverletter. It would be great if we could come
up with a PWL definition that's generic enough to work on all HW
that uses PWL and not require compositors to learn a new LUT2
type in the future.

>>
>>> As a userspace developer, I can totally work 

Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features

[Harry Wentland]

On 2021-10-12 17:01, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Tuesday, October 12, 2021 5:25 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com;
>> sebast...@sebastianwick.net; shashank.sha...@amd.com
>> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>>
>> On Tue,  7 Sep 2021 03:08:42 +0530
>> Uma Shankar  wrote:
>>
>>> This is how a typical display color hardware pipeline looks like:
>>>  +---+
>>>  |RAM|
>>>  |  +--++-++-+   |
>>>  |  | FB 1 ||  FB 2   || FB N|   |
>>>  |  +--++-++-+   |
>>>  +---+
>>>|  Plane Color Hardware Block |
>>> ++
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | DeGamma |   | Degamma   |   | Degamma  | |
>>>  | +---+-+   +---+---+   +---+--+ |
>>>  | | |   ||
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | |Plane A  |   | Plane B   |   | Plane N  | |
>>>  | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  | +---v-+   +v--+   +v-+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | Gamma   |   | Gamma |   | Gamma| |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  ++
>>> +--v--v---v---|
>>> ||   ||
>>> ||   Pipe Blender||
>>> +++
>>> |||
>>> |+---v--+ |
>>> ||  Pipe DeGamma| |
>>> ||  | |
>>> |+---+--+ |
>>> ||Pipe Color  |
>>> |+---v--+ Hardware|
>>> ||  Pipe CSC/CTM| |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> |+---v--+ |
>>> ||  Pipe Gamma  | |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> +-+
>>>  |
>>>  v
>>>Pipe Output
>>>
>>> This patch series adds properties for plane color features. It adds
>>> properties for degamma used to linearize data and CSC used for gamut
>>> conversion. It also includes Gamma support used to again non-linearize
>>> data as per panel supported color space. These can be utilize by user
>>> space to convert planes from one format to another, one color space to
>>> another etc.
>>>
>>> Userspace can take smart blending decisions and utilize these hardware
>>> supported plane color features to get accurate color profile. The same
>>> can help in consistent color quality from source to panel taking
>>> advantage of advanced color features in hardware.
>>>
>>> These patches add the property interfaces and enable helper functions.
>>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> can build up and add other platform/hardware specific implementation
>>> on top of this series.
>>>
>>> Credits: Special mention and credits to Ville Syrjala for coming up
>>> with a design for this feature and inputs. This series is based on his
>>> original design and idea.
>>>
>>> Note: Userspace support for this new UAPI will be done on Chrome in
>>> alignment with weston and general opensource community.
>>> Discussion ongoing with Harry Wentland, Pekka and community on color
>>> pipeline and UAPI design. Harry's RFC below:
>>> https://patchwork.freedesktop.org/series/89506/ We need to converge on 
>>> a common UAPI interface which caters to all the
>>> modern color hardware pipelines.
>>>
>>> ToDo: State readout for this feature will be added next.
>>>
>>> v2: Added UAPI description and added change in the rfc section of
>>> kernel Documentation folder
>>
>> Hi,
>>
>> thank you for this. I do believe the KMS UAPI should expose what hardware 
>> can do
>> (prescribed operations) rather than how they would be often used (to realize 
>> a
>> conversion from one space description to another). This proposal fits quite 
>> nicely
>> with what I have 

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

[Jani Nikula]

On Tue, 26 Oct 2021, Satadru Pramanik  wrote:
> That appears to do the trick.

Thanks for confirming.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 3/3] drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

[Jani Nikula]

On Tue, 26 Oct 2021, Imre Deak  wrote:
> By using the modifier plane capability flags to encode the modifiers'
> CCS type and tiling attributes, it becomes simpler to the check for
> any of these capabilities when providing the list of supported
> modifiers.
>
> This also allows distinguishing modifiers on future platforms where
> platforms with the same display version support different modifiers. An
> example is DG2 and ADLP, both being D13, where DG2 supports only F and X
> tiling, while ADLP supports only Y and X tiling. With the
> PLANE_HAS_TILING_* plane caps added in this patch we can provide the
> correct modifiers for each platform.
>
> Cc: Juha-Pekka Heikkila 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/i9xx_plane.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_fb.c   | 80 +--
>  drivers/gpu/drm/i915/display/intel_fb.h   | 11 ++-
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
>  .../drm/i915/display/skl_universal_plane.c|  7 +-
>  5 files changed, 53 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
> b/drivers/gpu/drm/i915/display/i9xx_plane.c
> index a939accff7ee2..fdb857df8b0be 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> @@ -860,7 +860,7 @@ intel_primary_plane_create(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   plane->disable_flip_done = ilk_primary_disable_flip_done;
>   }
>  
> - modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING);
> + modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING_X);
>  
>   if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv))
>   ret = drm_universal_plane_init(&dev_priv->drm, &plane->base,
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 6b68f69940f0b..6339669d86df5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -120,29 +120,25 @@ struct intel_modifier_desc {
>   .formats = format_list, \
>   .format_count = ARRAY_SIZE(format_list)
>  
> - u8 tiling;
> - u8 is_linear:1;
> + u8 plane_caps;
>  
>   struct {
> -#define INTEL_CCS_RC BIT(0)
> -#define INTEL_CCS_RC_CC  BIT(1)
> -#define INTEL_CCS_MC BIT(2)
> -
> -#define INTEL_CCS_ANY(INTEL_CCS_RC | INTEL_CCS_RC_CC | 
> INTEL_CCS_MC)
> - u8 type:3;
>   u8 cc_planes:3;
>   u8 packed_aux_planes:4;
>   u8 planar_aux_planes:4;
>   } ccs;
>  };
>  
> +#define PLANE_HAS_CCS_ANY(PLANE_HAS_CCS_RC | PLANE_HAS_CCS_RC_CC | 
> PLANE_HAS_CCS_MC)
> +#define PLANE_HAS_TILING_ANY (PLANE_HAS_TILING_X | PLANE_HAS_TILING_Y | 
> PLANE_HAS_TILING_Yf)

_MASK seems like the customary suffix for things that are masks.

> +#define PLANE_HAS_TILING_NONE0
> +
>  static const struct intel_modifier_desc intel_modifiers[] = {
>   {
>   .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
>   .display_ver = { 12, 13 },
> - .tiling = I915_TILING_Y,
> + .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_MC,
>  
> - .ccs.type = INTEL_CCS_MC,
>   .ccs.packed_aux_planes = BIT(1),
>   .ccs.planar_aux_planes = BIT(2) | BIT(3),
>  
> @@ -150,18 +146,16 @@ static const struct intel_modifier_desc 
> intel_modifiers[] = {
>   }, {
>   .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
>   .display_ver = { 12, 13 },
> - .tiling = I915_TILING_Y,
> + .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC,
>  
> - .ccs.type = INTEL_CCS_RC,
>   .ccs.packed_aux_planes = BIT(1),
>  
>   FORMAT_OVERRIDE(gen12_ccs_formats),
>   }, {
>   .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC,
>   .display_ver = { 12, 13 },
> - .tiling = I915_TILING_Y,
> + .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC_CC,
>  
> - .ccs.type = INTEL_CCS_RC_CC,
>   .ccs.cc_planes = BIT(2),
>   .ccs.packed_aux_planes = BIT(1),
>  
> @@ -169,39 +163,34 @@ static const struct intel_modifier_desc 
> intel_modifiers[] = {
>   }, {
>   .modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
>   .display_ver = { 9, 11 },
> - .tiling = I915_TILING_NONE,
> + .plane_caps = PLANE_HAS_TILING_Yf | PLANE_HAS_CCS_RC,
>  
> - .ccs.type = INTEL_CCS_RC,
>   .ccs.packed_aux_planes = BIT(1),
>  
>   FORMAT_OVERRIDE(skl_ccs_formats),
>   }, {
>   .modifier = I915_FORMAT_MOD_Y_TILED_CCS,
>   .display_ver = { 9, 11 },
> - .tiling = I915_TILING_Y,
> + .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC,
>  
> - 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Initial introduction of vma resources

[kernel test robot]

Hi "Thomas,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next airlied/drm-next v5.15-rc7 next-20211026]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/Prepare-error-capture-for-asynchronous-migration/20211026-150944
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-defconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/6c17f33fae142e4401d64d5399eb28e3c68f13a1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Thomas-Hellstr-m/Prepare-error-capture-for-asynchronous-migration/20211026-150944
git checkout 6c17f33fae142e4401d64d5399eb28e3c68f13a1
# save the attached .config to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_vma.c:1519: warning: expecting prototype for 
>> i915_vma_resource_hold(). Prototype was for i915_vma_resource_unhold() 
>> instead


vim +1519 drivers/gpu/drm/i915/i915_vma.c

  1508  
  1509  /**
  1510   * i915_vma_resource_hold - Unhold the signaling of the vma resource 
unbind
  1511   * fence.
  1512   * @vma_res: The vma resource.
  1513   * @lockdep_cookie: The lockdep cookie returned from 
i915_vma_resource_hold.
  1514   *
  1515   * The function may leave a dma_fence critical section.
  1516   */
  1517  void i915_vma_resource_unhold(struct i915_vma_resource *vma_res,
  1518bool lockdep_cookie)
> 1519  {
  1520  dma_fence_end_signalling(lockdep_cookie);
  1521  
  1522  if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
  1523  unsigned long irq_flags;
  1524  
  1525  /* Inefficient open-coded might_lock_irqsave() */
  1526  spin_lock_irqsave(&vma_res->lock, irq_flags);
  1527  spin_unlock_irqrestore(&vma_res->lock, irq_flags);
  1528  }
  1529  
  1530  __i915_vma_resource_unhold(vma_res);
  1531  }
  1532  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)

[Souza, Jose]

On Wed, 2021-10-06 at 06:49 +, Patchwork wrote:

> Patch Details
> Series:   drm/i915/display: Wait PSR2 get out of deep sleep to update 
> pipe (rev3)
> URL:  https://patchwork.freedesktop.org/series/95309/
> State:failure
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/index.html
> CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21259_full
> 
> Summary
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_21259_full absolutely need to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21259_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_21259_full:
> 
> IGT changes
> 
> Possible regressions
> 
> igt@i915_pm_dc@dc9-dpms:
> shard-iclb: PASS -> FAIL

Not related.

Patch pushed, thanks for the review GG.

> Known issues
> 
> Here are the changes found in Patchwork_21259_full that come from known 
> issues:
> 
> IGT changes
> 
> Issues hit
> 
> igt@feature_discovery@display-2x:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#1839])
> igt@gem_ctx_persistence@legacy-engines-mixed-process:
> 
> shard-snb: NOTRUN -> SKIP ([fdo#109271] / [i915#1099]) +1 similar issue
> igt@gem_eio@unwedge-stress:
> 
> shard-iclb: PASS -> TIMEOUT ([i915#2369] / [i915#2481] / [i915#3070])
> igt@gem_exec_fair@basic-deadline:
> 
> shard-apl: NOTRUN -> FAIL ([i915#2846])
> igt@gem_exec_fair@basic-flow@rcs0:
> 
> shard-tglb: PASS -> FAIL ([i915#2842])
> igt@gem_exec_fair@basic-none-share@rcs0:
> 
> shard-iclb: PASS -> FAIL ([i915#2842])
> igt@gem_exec_fair@basic-none@vcs0:
> 
> shard-apl: PASS -> FAIL ([i915#2842])
> igt@gem_exec_fair@basic-none@vcs1:
> 
> shard-kbl: PASS -> FAIL ([i915#2842])
> igt@gem_exec_fair@basic-pace-share@rcs0:
> 
> shard-tglb: NOTRUN -> FAIL ([i915#2842])
> igt@gem_exec_fair@basic-pace@vcs1:
> 
> shard-iclb: NOTRUN -> FAIL ([i915#2842])
> igt@gem_workarounds@suspend-resume-context:
> 
> shard-apl: PASS -> DMESG-WARN ([i915#180]) +1 similar issue
> igt@gem_workarounds@suspend-resume-fd:
> 
> shard-kbl: NOTRUN -> DMESG-WARN ([i915#180])
> igt@gen3_render_tiledy_blits:
> 
> shard-tglb: NOTRUN -> SKIP ([fdo#109289]) +1 similar issue
> igt@gen9_exec_parse@bb-secure:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#2856]) +1 similar issue
> igt@i915_pm_lpsp@screens-disabled:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#1902])
> igt@i915_pm_rc6_residency@media-rc6-accuracy:
> 
> shard-tglb: NOTRUN -> SKIP ([fdo#109289] / [fdo#111719])
> igt@i915_pm_rpm@pc8-residency:
> 
> shard-tglb: NOTRUN -> SKIP ([fdo#109506] / [i915#2411])
> igt@i915_selftest@mock@requests:
> 
> shard-skl: PASS -> INCOMPLETE ([i915#198])
> igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-hflip:
> 
> shard-apl: NOTRUN -> SKIP ([fdo#109271] / [i915#3777]) +1 similar issue
> igt@kms_big_fb@yf-tiled-addfb:
> 
> shard-tglb: NOTRUN -> SKIP ([fdo#111615]) +2 similar issues
> igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
> 
> shard-kbl: NOTRUN -> SKIP ([fdo#109271] / [i915#3777])
> igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
> 
> shard-apl: NOTRUN -> SKIP ([fdo#109271]) +208 similar issues
> igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
> 
> shard-apl: NOTRUN -> SKIP ([fdo#109271] / [i915#3886]) +10 similar issues
> igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
> 
> shard-kbl: NOTRUN -> SKIP ([fdo#109271] / [i915#3886]) +10 similar issues
> igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#3689] / [i915#3886]) +4 similar issues
> igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs:
> 
> shard-snb: NOTRUN -> SKIP ([fdo#109271]) +144 similar issues
> igt@kms_ccs@pipe-d-missing-ccs-buffer-yf_tiled_ccs:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#3689]) +3 similar issues
> igt@kms_cdclk@plane-scaling:
> 
> shard-tglb: NOTRUN -> SKIP ([i915#3742])
> igt@kms_chamelium@hdmi-hpd-enable-disable-mode:
> 
> shard-kbl: NOTRUN -> SKIP ([fdo#109271] / [fdo#111827]) +13 similar issues
> igt@kms_color@pipe-c-ctm-0-5:
> 
> shard-skl: PASS -> DMESG-WARN ([i915#1982])
> igt@kms_color_chamelium@pipe-b-ctm-max:
> 
> shard-snb: NOTRUN -> SKIP ([fdo#109271] / [fdo#111827]) +6 similar issues
> igt@kms_color_chamelium@pipe-c-ctm-max:
> 
> shard-apl: NOTRUN -> SKIP ([fdo#109271] / [fdo#111827]) +18 similar issues
> igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
> 
> shard-tglb: NOTRUN -> SKIP ([fdo#109284] / [fdo#111827]) +6 similar issues
> igt@kms_content_protection@atomic-dpms:
> 
> shard-apl: NOTRUN -> TIMEOUT ([i915#1319])
> igt@kms_content_protection@srm:
> 
> shard-kbl: NOTRUN -> TIMEOUT ([i915#1319])
> igt@kms_cursor_crc@pipe-a-cursor-suspend:
> 
> shard-tglb: PASS -> INCOMPLETE ([i915#2828] / [i915#456])
> igt@kms_cursor_crc@pipe-d-cursor-32x10-offscreen:
> 
> shard-tglb: NOTRUN ->

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/selftest: Disable irq to calc eng timestamp

[Patchwork]

== Series Details ==

Series: i915/selftest: Disable irq to calc eng timestamp
URL   : https://patchwork.freedesktop.org/series/96301/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21450_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-snb4/igt@gem_...@in-flight-contexts-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-snb7/igt@gem_...@in-flight-contexts-10ms.html

  * igt@i915_module_load@reload-with-fault-injection:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-iclb1/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-iclb7/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-kbl1/igt@i915_susp...@sysfs-reader.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-kbl3/igt@i915_susp...@sysfs-reader.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_eio@unwedge-stress:
- shard-skl:  [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-skl10/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-skl8/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / 
[i915#2481] / [i915#3070])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-iclb3/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-iclb7/igt@gem_...@unwedge-stress.html

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

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109313])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-tglb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

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

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-skl9/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#4270])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/shard-tglb6/igt@gem_...@c

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

[Jani Nikula]

On Tue, 26 Oct 2021, Ville Syrjälä  wrote:
> On Tue, Oct 26, 2021 at 12:34:07PM +0300, Jani Nikula wrote:
>> The intermediate value 100 * 10 * 9671 overflows 32 bits, so force
>> promotion to a bigger type.
>> 
>> >From the logs:
>> 
>> [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available 
>> -580783288
>> 
>> v2: Use mul_u32_u32() (Ville)
>> 
>> Fixes: 48efd014f0ea ("drm/i915/dp: add max data rate calculation for UHBR 
>> rates")
>> Cc: Manasi Navare 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

Thanks, pushed.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index f5dc2126d140..537c689a1528 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -352,7 +352,7 @@ intel_dp_max_data_rate(int max_link_rate, int max_lanes)
>>   */
>>  int max_link_rate_kbps = max_link_rate * 10;
>>  
>> -max_link_rate_kbps = DIV_ROUND_CLOSEST_ULL(max_link_rate_kbps * 
>> 9671, 1);
>> +max_link_rate_kbps = 
>> DIV_ROUND_CLOSEST_ULL(mul_u32_u32(max_link_rate_kbps, 9671), 1);
>>  max_link_rate = max_link_rate_kbps / 8;
>>  }
>>  
>> -- 
>> 2.30.2

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

[Satadru Pramanik]

That appears to do the trick.

Ubuntu's 5.15.0-051500rc6drmtip20211026-generic kernel boots successfully.

Thanks,
Satadru

On Tue, Oct 26, 2021 at 12:41 PM Jani Nikula 
wrote:

> On Tue, 26 Oct 2021, Satadru Pramanik  wrote:
> > I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu
> kernel
> > on successfully. I installed the 5.15-rc5 kernel
> >  (the
> > 5.15-rc4 didn't build) and the system wouldn't boot, erroring out with
> the
> > error below. I also see the same issues using the ubuntu mainline build
> of
> > 5.15-rc6 and 5.15-rc7.
>
> Thanks for the report, should be fixed by commit
>
> 4ec5ffc341ce ("drm/i915/dp: Skip the HW readout of DPCD on disabled
> encoders")
>
> in drm-intel-next and should hopefully make it to v5.15 final.
>
> BR,
> Jani.
>
>
> >
> > This is copied from a picture I took of the error screen where the boot
> > halts:
> >
> > [ 2.554921] RDX:  RSI: 560e0c741670 RDI:
> > 0015
> > [ 2.554925] RBP: 0002 ROB:  R09:
> > 
> > [ 2.554928] R10: 0015 R11: 0246 R12:
> > 560e0c741670
> > [ 2.554931] R13: 560e0c74b980 R14:  R15:
> > 560e0c7362c0
> > [ 2.554936] Modules linked in: hid_appleir (+) hid_apple i915(+)
> > 12c_algo_bitm hid_generic.drm_kms_helper syscopyarea sysfillrect wl (POE)
> > sysimgblt uas crc e_pclmul fb_sys_fops firewire_ohci usb_storage cec
> usbhid
> > firewire_core hid crc tu_t rc_core cfg80211 ahci 12c_1801 libahci
> i2c_smbus
> > tg3 1pc_ich drm apple_gm video apple_bl
> > [ 2.554967] [ end trace a9fec12cca81a98e ]---
> > [ 2.554970] RIP: 0010: intel_dp_sync_state+oxeo/oxfo, [1915]
> > [ 2.555098] Code: 85 69 ff ff ff 48 8b 9f 70 01:00 00 80 bb 83 01 00 00
> 00
> > of
> > 85 64 ff ff ff 48 8d bb 70 01 00 00 e8 f5 cb ff ff e9 53 ff ff ff <0f> ob
> > 66 66
> > 2e of if 84 00 00 00 00 00 0f 1f 00 of 1f 44 00 00 55
> > [ 2.555104] RSP: 0018:ae12c06ef898 EFLAGS: 00010282
> > [ 2.555108] RAX:  RBX: 99b099034000
> > ROX: 99b097bc03e0
> > [ 2.555112] RDX:  RSI:  RDI:
> > 99b0990341b6
> > [ 2.555115] RBP: ae12c06ef8b8 R08: ff92 R09:
> > c0c9cb2c
> > [ 2.555119] R10: 0008 R11: 99b099034e08 R12:
> > 
> > [ 2.555122] R13:  R14: 0004 R15:
> > 99b099034000
> > [ 2.555125] FS: 7fd7808a08c0 () GS:99b1c7c8 ()
> > knlGS:0
> > 000
> > [ 2.555130] CS: 0010 DS:  ES:  CRO: 80050033
> > [ 2.555133] CR2: 560e0c7395b8 CR3: 000100d02000 CR4:
> > 06e0
> > [ 2.555244] Console: switching to colour frame buffer device 210x65
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

[Jani Nikula]

On Tue, 26 Oct 2021, Satadru Pramanik  wrote:
> I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu kernel
> on successfully. I installed the 5.15-rc5 kernel
>  (the
> 5.15-rc4 didn't build) and the system wouldn't boot, erroring out with the
> error below. I also see the same issues using the ubuntu mainline build of
> 5.15-rc6 and 5.15-rc7.

Thanks for the report, should be fixed by commit

4ec5ffc341ce ("drm/i915/dp: Skip the HW readout of DPCD on disabled encoders")

in drm-intel-next and should hopefully make it to v5.15 final.

BR,
Jani.


>
> This is copied from a picture I took of the error screen where the boot
> halts:
>
> [ 2.554921] RDX:  RSI: 560e0c741670 RDI:
> 0015
> [ 2.554925] RBP: 0002 ROB:  R09:
> 
> [ 2.554928] R10: 0015 R11: 0246 R12:
> 560e0c741670
> [ 2.554931] R13: 560e0c74b980 R14:  R15:
> 560e0c7362c0
> [ 2.554936] Modules linked in: hid_appleir (+) hid_apple i915(+)
> 12c_algo_bitm hid_generic.drm_kms_helper syscopyarea sysfillrect wl (POE)
> sysimgblt uas crc e_pclmul fb_sys_fops firewire_ohci usb_storage cec usbhid
> firewire_core hid crc tu_t rc_core cfg80211 ahci 12c_1801 libahci i2c_smbus
> tg3 1pc_ich drm apple_gm video apple_bl
> [ 2.554967] [ end trace a9fec12cca81a98e ]---
> [ 2.554970] RIP: 0010: intel_dp_sync_state+oxeo/oxfo, [1915]
> [ 2.555098] Code: 85 69 ff ff ff 48 8b 9f 70 01:00 00 80 bb 83 01 00 00 00
> of
> 85 64 ff ff ff 48 8d bb 70 01 00 00 e8 f5 cb ff ff e9 53 ff ff ff <0f> ob
> 66 66
> 2e of if 84 00 00 00 00 00 0f 1f 00 of 1f 44 00 00 55
> [ 2.555104] RSP: 0018:ae12c06ef898 EFLAGS: 00010282
> [ 2.555108] RAX:  RBX: 99b099034000
> ROX: 99b097bc03e0
> [ 2.555112] RDX:  RSI:  RDI:
> 99b0990341b6
> [ 2.555115] RBP: ae12c06ef8b8 R08: ff92 R09:
> c0c9cb2c
> [ 2.555119] R10: 0008 R11: 99b099034e08 R12:
> 
> [ 2.555122] R13:  R14: 0004 R15:
> 99b099034000
> [ 2.555125] FS: 7fd7808a08c0 () GS:99b1c7c8 ()
> knlGS:0
> 000
> [ 2.555130] CS: 0010 DS:  ES:  CRO: 80050033
> [ 2.555133] CR2: 560e0c7395b8 CR3: 000100d02000 CR4:
> 06e0
> [ 2.555244] Console: switching to colour frame buffer device 210x65

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

[Satadru Pramanik]

I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu kernel
on successfully. I installed the 5.15-rc5 kernel
 (the
5.15-rc4 didn't build) and the system wouldn't boot, erroring out with the
error below. I also see the same issues using the ubuntu mainline build of
5.15-rc6 and 5.15-rc7.

This is copied from a picture I took of the error screen where the boot
halts:

[ 2.554921] RDX:  RSI: 560e0c741670 RDI:
0015
[ 2.554925] RBP: 0002 ROB:  R09:

[ 2.554928] R10: 0015 R11: 0246 R12:
560e0c741670
[ 2.554931] R13: 560e0c74b980 R14:  R15:
560e0c7362c0
[ 2.554936] Modules linked in: hid_appleir (+) hid_apple i915(+)
12c_algo_bitm hid_generic.drm_kms_helper syscopyarea sysfillrect wl (POE)
sysimgblt uas crc e_pclmul fb_sys_fops firewire_ohci usb_storage cec usbhid
firewire_core hid crc tu_t rc_core cfg80211 ahci 12c_1801 libahci i2c_smbus
tg3 1pc_ich drm apple_gm video apple_bl
[ 2.554967] [ end trace a9fec12cca81a98e ]---
[ 2.554970] RIP: 0010: intel_dp_sync_state+oxeo/oxfo, [1915]
[ 2.555098] Code: 85 69 ff ff ff 48 8b 9f 70 01:00 00 80 bb 83 01 00 00 00
of
85 64 ff ff ff 48 8d bb 70 01 00 00 e8 f5 cb ff ff e9 53 ff ff ff <0f> ob
66 66
2e of if 84 00 00 00 00 00 0f 1f 00 of 1f 44 00 00 55
[ 2.555104] RSP: 0018:ae12c06ef898 EFLAGS: 00010282
[ 2.555108] RAX:  RBX: 99b099034000
ROX: 99b097bc03e0
[ 2.555112] RDX:  RSI:  RDI:
99b0990341b6
[ 2.555115] RBP: ae12c06ef8b8 R08: ff92 R09:
c0c9cb2c
[ 2.555119] R10: 0008 R11: 99b099034e08 R12:

[ 2.555122] R13:  R14: 0004 R15:
99b099034000
[ 2.555125] FS: 7fd7808a08c0 () GS:99b1c7c8 ()
knlGS:0
000
[ 2.555130] CS: 0010 DS:  ES:  CRO: 80050033
[ 2.555133] CR2: 560e0c7395b8 CR3: 000100d02000 CR4:
06e0
[ 2.555244] Console: switching to colour frame buffer device 210x65

[Intel-gfx] [PATCH 2/3] drm/i915/fb: Don't store bitmasks in the intel_plane_caps enum

[Imre Deak]

Variables of enum types can contain only the values listed at the enums
definition, so don't store bitmasks in intel_plane_caps enum variables.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_fb.c| 4 ++--
 drivers/gpu/drm/i915/display/intel_fb.h| 2 +-
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 9ce1d273dc7e1..6b68f69940f0b 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -309,7 +309,7 @@ static bool check_modifier_display_ver_range(const struct 
intel_modifier_desc *m
 }
 
 static bool plane_has_modifier(struct drm_i915_private *i915,
-  enum intel_plane_caps plane_caps,
+  u8 plane_caps,
   const struct intel_modifier_desc *md)
 {
if (!IS_DISPLAY_VER(i915, md->display_ver.from, md->display_ver.until))
@@ -340,7 +340,7 @@ static bool plane_has_modifier(struct drm_i915_private 
*i915,
  * The caller must free the returned buffer.
  */
 u64 *intel_fb_plane_get_modifiers(struct drm_i915_private *i915,
- enum intel_plane_caps plane_caps)
+ u8 plane_caps)
 {
u64 *list, *p;
int count = 1;  /* +1 for invalid modifier terminator */
diff --git a/drivers/gpu/drm/i915/display/intel_fb.h 
b/drivers/gpu/drm/i915/display/intel_fb.h
index 042ad81f86082..19f46144474d8 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.h
+++ b/drivers/gpu/drm/i915/display/intel_fb.h
@@ -35,7 +35,7 @@ bool intel_fb_is_ccs_aux_plane(const struct drm_framebuffer 
*fb, int color_plane
 int intel_fb_rc_ccs_cc_plane(const struct drm_framebuffer *fb);
 
 u64 *intel_fb_plane_get_modifiers(struct drm_i915_private *i915,
- enum intel_plane_caps plane_caps);
+ u8 plane_caps);
 bool intel_fb_plane_supports_modifier(struct intel_plane *plane, u64 modifier);
 
 const struct drm_format_info *
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 8fa0ae89e5b3d..317108e009bba 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2023,7 +2023,7 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
const struct drm_plane_funcs *plane_funcs;
struct intel_plane *plane;
enum drm_plane_type plane_type;
-   enum intel_plane_caps plane_caps;
+   u8 plane_caps;
unsigned int supported_rotations;
unsigned int supported_csc;
const u64 *modifiers;
-- 
2.27.0

[Intel-gfx] [PATCH 0/3] drm/i915/fb: Simplify modifier handling more

[Imre Deak]

To simplify the handling of modifiers on DG2 and future platforms it
makes sense to fold the modifier tiling and CCS type attributes to the
plane capabilities mask. This patchset does that, also including fixing
two minor issues.

Cc: Juha-Pekka Heikkila 

Imre Deak (3):
  drm/i915/fb: Don't report MC CCS plane capability on GEN<12
  drm/i915/fb: Don't store bitmasks in the intel_plane_caps enum
  drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

 drivers/gpu/drm/i915/display/i9xx_plane.c |  2 +-
 drivers/gpu/drm/i915/display/intel_fb.c   | 84 +--
 drivers/gpu/drm/i915/display/intel_fb.h   | 13 +--
 drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
 .../drm/i915/display/skl_universal_plane.c| 12 ++-
 5 files changed, 60 insertions(+), 53 deletions(-)

-- 
2.27.0

[Intel-gfx] [PATCH 3/3] drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

[Imre Deak]

By using the modifier plane capability flags to encode the modifiers'
CCS type and tiling attributes, it becomes simpler to the check for
any of these capabilities when providing the list of supported
modifiers.

This also allows distinguishing modifiers on future platforms where
platforms with the same display version support different modifiers. An
example is DG2 and ADLP, both being D13, where DG2 supports only F and X
tiling, while ADLP supports only Y and X tiling. With the
PLANE_HAS_TILING_* plane caps added in this patch we can provide the
correct modifiers for each platform.

Cc: Juha-Pekka Heikkila 
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c |  2 +-
 drivers/gpu/drm/i915/display/intel_fb.c   | 80 +--
 drivers/gpu/drm/i915/display/intel_fb.h   | 11 ++-
 drivers/gpu/drm/i915/display/intel_sprite.c   |  2 +-
 .../drm/i915/display/skl_universal_plane.c|  7 +-
 5 files changed, 53 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index a939accff7ee2..fdb857df8b0be 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -860,7 +860,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
plane->disable_flip_done = ilk_primary_disable_flip_done;
}
 
-   modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING);
+   modifiers = intel_fb_plane_get_modifiers(dev_priv, PLANE_HAS_TILING_X);
 
if (DISPLAY_VER(dev_priv) >= 5 || IS_G4X(dev_priv))
ret = drm_universal_plane_init(&dev_priv->drm, &plane->base,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 6b68f69940f0b..6339669d86df5 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -120,29 +120,25 @@ struct intel_modifier_desc {
.formats = format_list, \
.format_count = ARRAY_SIZE(format_list)
 
-   u8 tiling;
-   u8 is_linear:1;
+   u8 plane_caps;
 
struct {
-#define INTEL_CCS_RC   BIT(0)
-#define INTEL_CCS_RC_CCBIT(1)
-#define INTEL_CCS_MC   BIT(2)
-
-#define INTEL_CCS_ANY  (INTEL_CCS_RC | INTEL_CCS_RC_CC | INTEL_CCS_MC)
-   u8 type:3;
u8 cc_planes:3;
u8 packed_aux_planes:4;
u8 planar_aux_planes:4;
} ccs;
 };
 
+#define PLANE_HAS_CCS_ANY  (PLANE_HAS_CCS_RC | PLANE_HAS_CCS_RC_CC | 
PLANE_HAS_CCS_MC)
+#define PLANE_HAS_TILING_ANY   (PLANE_HAS_TILING_X | PLANE_HAS_TILING_Y | 
PLANE_HAS_TILING_Yf)
+#define PLANE_HAS_TILING_NONE  0
+
 static const struct intel_modifier_desc intel_modifiers[] = {
{
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
.display_ver = { 12, 13 },
-   .tiling = I915_TILING_Y,
+   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_MC,
 
-   .ccs.type = INTEL_CCS_MC,
.ccs.packed_aux_planes = BIT(1),
.ccs.planar_aux_planes = BIT(2) | BIT(3),
 
@@ -150,18 +146,16 @@ static const struct intel_modifier_desc intel_modifiers[] 
= {
}, {
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
.display_ver = { 12, 13 },
-   .tiling = I915_TILING_Y,
+   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC,
 
-   .ccs.type = INTEL_CCS_RC,
.ccs.packed_aux_planes = BIT(1),
 
FORMAT_OVERRIDE(gen12_ccs_formats),
}, {
.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC,
.display_ver = { 12, 13 },
-   .tiling = I915_TILING_Y,
+   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC_CC,
 
-   .ccs.type = INTEL_CCS_RC_CC,
.ccs.cc_planes = BIT(2),
.ccs.packed_aux_planes = BIT(1),
 
@@ -169,39 +163,34 @@ static const struct intel_modifier_desc intel_modifiers[] 
= {
}, {
.modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
.display_ver = { 9, 11 },
-   .tiling = I915_TILING_NONE,
+   .plane_caps = PLANE_HAS_TILING_Yf | PLANE_HAS_CCS_RC,
 
-   .ccs.type = INTEL_CCS_RC,
.ccs.packed_aux_planes = BIT(1),
 
FORMAT_OVERRIDE(skl_ccs_formats),
}, {
.modifier = I915_FORMAT_MOD_Y_TILED_CCS,
.display_ver = { 9, 11 },
-   .tiling = I915_TILING_Y,
+   .plane_caps = PLANE_HAS_TILING_Y | PLANE_HAS_CCS_RC,
 
-   .ccs.type = INTEL_CCS_RC,
.ccs.packed_aux_planes = BIT(1),
 
FORMAT_OVERRIDE(skl_ccs_formats),
}, {
.modifier = I915_FORMAT_MOD_Yf_TILED,
.display_ver = { 9, 11 },
- 

[Intel-gfx] [PATCH 1/3] drm/i915/fb: Don't report MC CCS plane capability on GEN<12

[Imre Deak]

Remove the MC CCS plane capability on GEN<12, since it's not present
there. This didn't cause a problem, since the display version check
filtered out the MC CCS modifiers before GEN12.

Cc: Juha-Pekka Heikkila 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 69fd56de83a7a..8fa0ae89e5b3d 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2001,6 +2001,9 @@ static bool skl_plane_has_rc_ccs(struct drm_i915_private 
*i915,
 static bool gen12_plane_has_mc_ccs(struct drm_i915_private *i915,
   enum plane_id plane_id)
 {
+   if (DISPLAY_VER(i915) < 12)
+   return false;
+
/* Wa_14010477008:tgl[a0..c0],rkl[all],dg1[all] */
if (IS_DG1(i915) || IS_ROCKETLAKE(i915) ||
IS_TGL_DISPLAY_STEP(i915, STEP_A0, STEP_D0))
-- 
2.27.0

[Intel-gfx] ✓ Fi.CI.IGT: success for Remove check for ComboPHY I/O voltage for DP source rate (rev2)

[Patchwork]

== Series Details ==

Series: Remove check for ComboPHY I/O voltage for DP source rate (rev2)
URL   : https://patchwork.freedesktop.org/series/96293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21449_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb1/igt@feature_discov...@chamelium.html

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

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-kbl3/igt@gem_ctx_isolation@preservation...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-kbl6/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][5] ([fdo#109271]) +165 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-skl2/igt@gem_ctx_persistence@legacy-engines-h...@blt.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_21449/shard-tglb1/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_10789/shard-iclb3/igt@gem_...@unwedge-stress.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-iclb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk2/igt@gem_exec_fair@basic-p...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-glk5/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-tglb: NOTRUN -> [SKIP][13] ([fdo#109313])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-tglb5/igt@gem_huc_c...@huc-copy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb7/igt@gem_huc_c...@huc-copy.html
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-kbl7/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-skl:  NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-skl2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#4270])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb6/igt@gem_...@create-valid-protected-context.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@readonly-pwrite-unsync:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#3297])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb1/igt@gem_userptr_bl...@readonly-pwrite-unsync.html

  * igt@gem_userptr_blits@vma-merge:
- shard-tglb: NOTRUN -> [FAIL][22] ([i915#3318])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/shard-tglb1/igt@gem_userptr_b

Re: [Intel-gfx] [PATCH v2 13/17] drm/i915/dg2: Tile 4 plane format support

[Ramalingam C]

On 2021-10-21 at 17:27:08 +0300, Lisovskiy, Stanislav wrote:
> On Thu, Oct 21, 2021 at 07:56:23PM +0530, Ramalingam C wrote:
> > From: Stanislav Lisovskiy 
> > 
> > TileF(Tile4 in bspec) format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
> > 
> > v2: - Fixed wrong case condition(Jani Nikula)
> > - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)
> > 
> > v3: - s/I915_TILING_F/TILING_4/g
> > - s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
> > - Removed unneeded fencing code
> > 
> > Cc: Imre Deak 
> > Cc: Matt Roper 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Stanislav Lisovskiy 
> > Signed-off-by: Matt Roper 
> > Signed-off-by: Juha-Pekka Heikkilä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
> >  drivers/gpu/drm/i915/display/intel_fb.c   |  7 
> >  drivers/gpu/drm/i915/display/intel_fbc.c  |  1 +
> >  .../drm/i915/display/intel_plane_initial.c|  1 +
> >  .../drm/i915/display/skl_universal_plane.c| 36 ++-
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  drivers/gpu/drm/i915/i915_pci.c   |  1 +
> >  drivers/gpu/drm/i915/i915_reg.h   |  1 +
> >  drivers/gpu/drm/i915/intel_device_info.h  |  1 +
> >  drivers/gpu/drm/i915/intel_pm.c   |  1 +
> >  include/uapi/drm/drm_fourcc.h |  8 +
> >  11 files changed, 50 insertions(+), 9 deletions(-)
> 
> Was I supposed to change TILE_F/TILE_4 everywhere first,
> as per your comment?
Stan, if you think that is the right think to do, please go ahead!

Ram
> 
> Stan
> 
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index ce5d6633029a..9b678839bf2b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8877,6 +8877,7 @@ static int intel_atomic_check_async(struct 
> > intel_atomic_state *state)
> > case I915_FORMAT_MOD_X_TILED:
> > case I915_FORMAT_MOD_Y_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > +   case I915_FORMAT_MOD_4_TILED:
> > break;
> > default:
> > drm_dbg_kms(&i915->drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index fa1f375e696b..e19739fef825 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -127,6 +127,12 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> > *fb, int color_plane)
> > return 128;
> > else
> > return 512;
> > +   case I915_FORMAT_MOD_4_TILED:
> > +   /*
> > +* Each 4K tile consists of 64B(8*8) subtiles, with
> > +* same shape as Y Tile(i.e 4*16B OWords)
> > +*/
> > +   return 128;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > if (is_ccs_plane(fb, color_plane))
> > return 128;
> > @@ -305,6 +311,7 @@ unsigned int intel_surf_alignment(const struct 
> > drm_framebuffer *fb,
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > case I915_FORMAT_MOD_Yf_TILED_CCS:
> > case I915_FORMAT_MOD_Y_TILED:
> > +   case I915_FORMAT_MOD_4_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > return 1 * 1024 * 1024;
> > default:
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 1f66de77a6b1..f079a771f802 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -747,6 +747,7 @@ static bool tiling_is_valid(struct drm_i915_private 
> > *dev_priv,
> > case DRM_FORMAT_MOD_LINEAR:
> > case I915_FORMAT_MOD_Y_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > +   case I915_FORMAT_MOD_4_TILED:
> > return DISPLAY_VER(dev_priv) >= 9;
> > case I915_FORMAT_MOD_X_TILED:
> > return true;
> > diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
> > b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > index dcd698a02da2..d80855ee9b96 100644
> > --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> > @@ -125,6 +125,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
> > case DRM_FORMAT_MOD_LINEAR:
> > case I915_FORMAT_MOD_X_TILED:
> > case I915_FORMAT_MOD_Y_TILED:
> > +   case I915_FORMAT_MOD_4_TILED:
> > break;
> > default:
> > drm_dbg(&dev_priv->drm,
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 7444b88829ea..0eb4509f7f7a 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -

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

[Matthew Brost]

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

Sorry for the double reply - missed this one in the first.

I changed my plans / mind after I send the original email. I only sent a
patch which includes guc_id when LOW_LEVEL_TRACEPOINTS is enabled. That
is the bear minimum I live with. Without it any time there is a problem
results in hacking the kernel. I can't do that. This is a good
compromise.

Matt

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

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

[Matthew Brost]

On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote:
> Quoting Matthew Brost (2021-10-25 18:15:09)
> > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote:
> > > Quoting Matthew Brost (2021-10-22 19:42:19)
> > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote:
> > > > > Hi Matt & John,
> > > > > 
> > > > > Can you please queue patches with the right Fixes: references to 
> > > > > convert
> > > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS
> > > > > protection for now. Please do so before next Wednesday so we get it
> > > > > queued in drm-intel-next-fixes.
> > > > > 
> > > > 
> > > > Don't we already do that? I checked i915_trace.h and every tracepoint I
> > > > added (intel_context class, i915_request_guc_submit) is protected by
> > > > LOW_LEVEL_TRACEPOINTS.
> > > > 
> > > > The only thing I changed outside of that protection is adding the guc_id
> > > > field to existing i915_request class tracepoints.
> > > 
> > > It's the first search hit for "guc" inside the i915_trace.h file :)
> > > 
> > > > Without the guc_id in
> > > > those tracepoints these are basically useless with GuC submission. We
> > > > could revert that if it is a huge deal but as I said then they are
> > > > useless...
> > > 
> > > Let's eliminate it for now and restore the tracepoint exactly as it was.
> > > 
> > 
> > Don't really agree - let's render tracepoints to be useless? Are
> > tracepoints ABI? I googled this and couldn't really find a definie
> > answer. If tracepoints are ABI, then OK I can revert this change but
> > still this is a poor technical decision (tracepoints should not be ABI).
> 
> Thats a very heated discussion in general. But the fact is that if
> tracepoint changes have caused regressions to applications, they have
> been forced to be remain untouched. You are free to raise the discussion
> with Linus/LKML if you feel that should not be the case. So the end
> result is that tracepoints are effectively in limbo, not ABI unless some
> application uses them like ABI.
> 

Not trying to start or fight a holy war. If the current rules are don't
change tracepoints, we won't. Patch posted, let's stay focused, get an
RB, and move on.

Matt

> Feel free to search the intel-gfx/lkml for "tracepoints" keyword and look
> for threads with many replies. It's not that I would not agree, it's more
> that I'm not in the mood for repeating that discussion over and over again
> and always land in the same spot.
> 
> So for now, we don't add anything new to tracepoints we can't guarantee
> to always be there untouched. Similarly, we don't guarantee any of them
> to remain stable. So we try to be compatible with the limbo.
> 
> I'm long overdue waiting for some stable consumer to step up for the
> tracepoints, so we can then start discussion what would actually be the
> best way of getting that information out for them. In ~5 years that has
> not happened.
> 
> > > If there is an immediate need, we should instead have an auxilary 
> > > tracepoint
> > > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the
> > > information of the basic tracepoint.
> > > 
> > 
> > Regardless of what I said above, I'll post 2 patches. The 1st just
> > remove the GuC, the 2nd modify the tracepoint to include guc_id if
> > LOW_LEVEL_TRACEPOINTS is defined.
> 
> Thanks. Let's get a patch merged which simply drops the guc_id for now
> to unblock things.
> 
> For the second, an auxilary tracepoint will be preferred instead of
> mutating the existing one (regardless of the LOW_LEVEL_TRACEPOINTS).
> 
> I only noticed a patch that mutates the tracepoints, can you
> double-check sending the first patch?
> 
> Regards, Joonas
> 
> > 
> > > For the longer term solution we should align towards the dma fence
> > > tracepoints. When those are combined with the OA information, one should
> > > be able to get a good understanding of both the software and hardware
> > > scheduling decisions.
> > > 
> > 
> > Not sure about this either. I use these tracepoins to correlate things
> > to the GuC log. Between the 2, if you know what you are doing you
> > basically can figure out everything that is happening. Fields in the
> > trace translate directly to fields in the GuC log. Some of these fields
> > are backend specific, not sure how these could be pushed the dma fence
> > tracepoints. For what it is worth, without these tracepoints we'd likely
> > still have a bunch of bugs in the GuC firmware. I understand these
> > points, several other i915 developers do, and several of the GuC
> > firmware developers do too.
> > 
> > Matt
> > 
> > > Regards, Joonas
> > > 
> > > > 
> > > > Matt
> > > > 
> > > > > There's the orthogonal track to discuss what would be the stable set 
> > > > > of
> > > > > tracepoints we could expose. However, before that discussion is 
> > > > > closed,
> > > > > let's keep a rather strict line to avoid potential maintenance burned.
> > > > > 
> > > > > We can then

Re: [Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

[Ramalingam C]

On 2021-10-25 at 14:20:02 +0300, Juha-Pekka Heikkila wrote:
> On 21.10.2021 17.35, Ville Syrjälä wrote:
> > On Thu, Oct 21, 2021 at 07:56:24PM +0530, Ramalingam C wrote:
> > > From: Matt Roper 
> > > 
> > > DG2 unifies render compression and media compression into a single
> > > format for the first time.  The programming and buffer layout is
> > > supposed to match compression on older gen12 platforms, but the
> > > actual compression algorithm is different from any previous platform; as
> > > such, we need a new framebuffer modifier to represent buffers in this
> > > format, but otherwise we can re-use the existing gen12 compression driver
> > > logic.
> > > 
> > > DG2 clear color render compression uses Tile4 layout. Therefore, we need
> > > to define a new format modifier for uAPI to support clear color rendering.
> > > 
> > > Signed-off-by: Matt Roper 
> > > Signed-off-by: Mika Kahola  (v2)
> > > Signed-off-by: Juha-Pekka Heikkilä 
> > > Signed-off-by: Ramalingam C 
> > > cc: Simon Ser 
> > > Cc: Pekka Paalanen 
> > > ---
> > >   drivers/gpu/drm/i915/display/intel_display.c  |  3 ++
> > >   .../drm/i915/display/intel_display_types.h| 10 +++-
> > >   drivers/gpu/drm/i915/display/intel_fb.c   |  7 +++
> > >   .../drm/i915/display/skl_universal_plane.c| 49 +--
> > >   include/uapi/drm/drm_fourcc.h | 30 
> > >   5 files changed, 94 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 9b678839bf2b..2949fe9f5b9f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -1013,6 +1013,9 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 
> > > *cmd)
> > > cmd->pixel_format);
> > >   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > >   case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> > > + case I915_FORMAT_MOD_F_TILED_DG2_RC_CCS:
> > > + case I915_FORMAT_MOD_F_TILED_DG2_MC_CCS:
> > > + case I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC:
> > >   return lookup_format_info(gen12_ccs_formats,
> > > ARRAY_SIZE(gen12_ccs_formats),
> > > cmd->pixel_format);
> > 
> > That seems not right. Flat CCS is invisible to the user so the format
> > info should not include a CCS plane.
> > 
> 
> I had cleaned out those rc and mc ccs from here long time ago, I wonder
> where did they come back from? On my development tree they're not there.
> Also I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC is here in totally wrong place,
> it should have its own gen12_flat_ccs_cc_formats table.

Oops, there was another piece missed from this upstreaming effort. I
will push that too...

Ram
> 
> /Juha-Pekka

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmabuf: include asm/smp.h for cache operations

[Patchwork]

== Series Details ==

Series: drm/i915/dmabuf: include asm/smp.h for cache operations
URL   : https://patchwork.freedesktop.org/series/96300/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21448_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_spin_batch@spin-each:
- shard-apl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-apl6/igt@gem_spin_ba...@spin-each.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-apl2/igt@gem_spin_ba...@spin-each.html

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-kbl1/igt@i915_susp...@sysfs-reader.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-kbl3/igt@i915_susp...@sysfs-reader.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-tglb2/igt@feature_discov...@chamelium.html

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

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][7] ([fdo#109271]) +162 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-skl8/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

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

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#3070])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-iclb6/igt@gem_...@in-flight-contexts-10ms.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-iclb1/igt@gem_...@in-flight-contexts-10ms.html

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

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][14] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-kbl1/igt@gem_exec_fair@basic-none-...@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_10789/shard-glk8/igt@gem_exec_fair@basic-n...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-glk6/igt@gem_exec_fair@basic-n...@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_21448/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_fence@basic-wait-all:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk8/igt@gem_exec_fe...@basic-wait-all.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/shard-glk2/igt@gem_exec_fe...@basic-wait-all

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/selftest: Disable irq to calc eng timestamp

[Patchwork]

== Series Details ==

Series: i915/selftest: Disable irq to calc eng timestamp
URL   : https://patchwork.freedesktop.org/series/96301/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21450


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 34)
--

  Additional (1): fi-skl-guc 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan fi-icl-u2 bat-adlp-4 
fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +28 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#4269])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-ivb-3770:NOTRUN -> [FAIL][12] ([i915#2426] / [i915#4312])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-ivb-3770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [INCOMPLETE][13] ([i915#146]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][15] ([i915#2940]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][17] ([i915#2940]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][19] ([i915#4290]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
- fi-cfl-8109u:   [FAIL][21] ([i915#2546]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21450/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

  
  {name}: This element is suppressed. Thi

[Intel-gfx] ✓ Fi.CI.BAT: success for Remove check for ComboPHY I/O voltage for DP source rate (rev2)

[Patchwork]

== Series Details ==

Series: Remove check for ComboPHY I/O voltage for DP source rate (rev2)
URL   : https://patchwork.freedesktop.org/series/96293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21449


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 35)
--

  Additional (1): fi-skl-guc 
  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-kbl-soraka/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][8] -> [INCOMPLETE][9] ([i915#3921])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][12] ([fdo#109271]) +28 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109u:   [PASS][13] -> [FAIL][14] ([i915#4165]) +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][15] -> [DMESG-WARN][16] ([i915#295]) +17 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [INCOMPLETE][18] ([i915#146]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][20] ([i915#2940]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21449/fi-

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation 
(rev3)
URL   : https://patchwork.freedesktop.org/series/96289/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21445_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- shard-glk:  ([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]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [FAIL][50])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk9/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk9/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk8/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk8/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk7/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk7/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk6/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk6/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk5/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk2/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk1/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk9/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk8/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk7/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk7/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk6/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk5/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk5/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/shard-glk4/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tre

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmabuf: include asm/smp.h for cache operations

[Patchwork]

== Series Details ==

Series: drm/i915/dmabuf: include asm/smp.h for cache operations
URL   : https://patchwork.freedesktop.org/series/96300/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21448


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 36)
--

  Additional (2): fi-skl-guc fi-pnv-d510 
  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][3] ([fdo#109315]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +28 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][8] -> [DMESG-WARN][9] ([i915#4269])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][11] ([fdo#109271]) +53 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [INCOMPLETE][12] ([i915#146]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][14] ([i915#2940]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][16] ([i915#2940]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gtt:
- fi-icl-u2:  [INCOMPLETE][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-icl-u2/igt@i915_selftest@l...@gtt.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-icl-u2/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][20] ([i915#3303]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21448/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][22] ([i915#4290]) -> [PASS][23]
   [22]: 

Re: [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire

[Guenter Roeck]

On Mon, Oct 18, 2021 at 06:45:03PM +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if the
> GPU can read the page contents directly from main memory. Underneath we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
> 
> Reported-by: Thomas Hellström 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 

With nosmp builds:

Error log:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function 
'i915_gem_object_get_pages_dmabuf':
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:17: error: implicit declaration 
of function 'wbinvd_on_all_cpus' [-Werror=implicit-function-declaration]
  248 | wbinvd_on_all_cpus();
  | ^~

Guenter

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 5be505ebbb7b..1adcd8e02d29 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct 
> drm_gem_object *gem_obj, int flags)
>  
>  static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>   struct sg_table *pages;
>   unsigned int sg_page_sizes;
>  
> @@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct 
> drm_i915_gem_object *obj)
>   if (IS_ERR(pages))
>   return PTR_ERR(pages);
>  
> - sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> + /* XXX: consider doing a vmap flush or something */
> + if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
> + wbinvd_on_all_cpus();
>  
> + sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
>   __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
>  
>   return 0;
> -- 
> 2.26.3
> 

[Intel-gfx] [PATCH] i915/selftest: Disable irq to calc eng timestamp

[Anshuman Gupta]

gt_pm selftest calculates engine ticks cycles and wall time
cycles by delta of respective engine elapsed TIMESTAMP and ktime
for period of 1000us.
It compares the engine ticks cycles with wall time cycles.

Disable local cpu interrupt so that interrupt handler
should not preempt the measure_clocks() to calculate
correct engine ticks cycles.

Suggested-by: Chris P Wilson 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
index b9441217ca3d..9cf76398bdf5 100644
--- a/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_gt_pm.c
@@ -43,6 +43,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
int i;
 
for (i = 0; i < 5; i++) {
+   local_irq_disable();
preempt_disable();
cycles[i] = -ENGINE_READ_FW(engine, RING_TIMESTAMP);
dt[i] = ktime_get();
@@ -52,6 +53,7 @@ static void measure_clocks(struct intel_engine_cs *engine,
dt[i] = ktime_sub(ktime_get(), dt[i]);
cycles[i] += ENGINE_READ_FW(engine, RING_TIMESTAMP);
preempt_enable();
+   local_irq_enable();
}
 
/* Use the median of both cycle/dt; close enough */
-- 
2.26.2

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: PREEMPT_RT related fixups. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: PREEMPT_RT related fixups. (rev3)
URL   : https://patchwork.freedesktop.org/series/95463/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21447


Summary
---

  **FAILURE**

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

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

Participating hosts (39 -> 33)
--

  Additional (1): fi-skl-guc 
  Missing(7): bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-bsw-cyan fi-apl-guc 
bat-adlp-4 fi-ctg-p8600 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +27 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][6] -> [INCOMPLETE][7] ([i915#3921])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +28 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#4269])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [INCOMPLETE][15] ([i915#146]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][17] ([i915#2940]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21447/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][19] ([i915#2940]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-n3050/igt@i915_selftest@l

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dmabuf: include asm/smp.h for cache operations

[Patchwork]

== Series Details ==

Series: drm/i915/dmabuf: include asm/smp.h for cache operations
URL   : https://patchwork.freedesktop.org/series/96300/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a0c95634697f drm/i915/dmabuf: include asm/smp.h for cache operations
-:25: WARNING:INCLUDE_LINUX: Use #include  instead of 
#25: FILE: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:10:
+#include 

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: PREEMPT_RT related fixups. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: PREEMPT_RT related fixups. (rev3)
URL   : https://patchwork.freedesktop.org/series/95463/
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/intel_wakeref.c:137:19: warning: context imbalance in 
'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: PREEMPT_RT related fixups. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: PREEMPT_RT related fixups. (rev3)
URL   : https://patchwork.freedesktop.org/series/95463/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8fdcd01953e1 drm/i915: Don't disable interrupts and pretend a lock as been 
acquired in __timeline_mark_lock().
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#8: 
   d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as 
irqsafe")

-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d67739268cf0 ("drm/i915/gt: Mark 
up the nested engine-pm timeline lock as irqsafe")'
#8: 
   d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as 
irqsafe")

-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 6c69a45445af ("drm/i915/gt: Mark 
context->active_count as protected by timeline->mutex")'
#9: 
   6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by 
timeline->mutex")

-:29: WARNING:BAD_SIGN_OFF: Non-standard signature: 'Suggested--by:' - perhaps 
'Suggested-by:'?
#29: 
Suggested--by: Peter Zijlstra (Intel) 

-:137: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#137: FILE: drivers/gpu/drm/i915/i915_request.h:645:
+
lockdep_is_held(&rcu_access_pointer(rq->timeline)->mutex) ||

total: 2 errors, 3 warnings, 0 checks, 87 lines checked
b13483964853 drm/i915/gt: Queue and wait for the irq_work item.
711c9c2a91c5 drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + 
spin_lock()
8acc14ce018e drm/i915: Drop the irqs_disabled() check
e33df9c8c839 drm/i915: Use preempt_disable/enable_rt() where recommended
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
  ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms 
driver.")

total: 0 errors, 1 warnings, 0 checks, 18 lines checked
dc40ab39e578 drm/i915: Don't disable interrupts on PREEMPT_RT during atomic 
updates
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT

total: 0 errors, 1 warnings, 0 checks, 42 lines checked
0835ba9201bc drm/i915: Don't check for atomic context on PREEMPT_RT
27816f7f66ac drm/i915: Disable tracing points on PREEMPT_RT
a491b4dd2fa5 drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

[Intel-gfx] ✓ Fi.CI.BAT: success for Remove check for ComboPHY I/O voltage for DP source rate

[Patchwork]

== Series Details ==

Series: Remove check for ComboPHY I/O voltage for DP source rate
URL   : https://patchwork.freedesktop.org/series/96293/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21446


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 35)
--

  Additional (1): fi-skl-guc 
  Missing(5): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][5] ([fdo#109271]) +28 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#1602] / [i915#2426] / 
[i915#4312])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u:   [INCOMPLETE][8] ([i915#146]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][10] ([i915#2940]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][12] ([i915#2940]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gtt:
- fi-icl-u2:  [INCOMPLETE][14] -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-icl-u2/igt@i915_selftest@l...@gtt.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-icl-u2/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][16] ([i915#3303]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}:   [DMESG-WARN][18] ([i915#4290]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
- fi-cfl-8109u:   [FAIL][20] ([i915#2546]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21446/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109315]: https://b

[Intel-gfx] [PATCH v2 2/2] drm/i915/intel_combo_phy: Print procmon ref values

[Ankit Nautiyal]

Add debug print for Procmon Ref values, to help get the
voltage configurations of combo PHYs.

v2: Corrected drm_dbg to drm_dbg_kms (Jani)

Suggested-by: Imre Deak 
Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c 
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 634e8d449457..72985cd5a263 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -112,6 +112,10 @@ static bool icl_verify_procmon_ref_values(struct 
drm_i915_private *dev_priv,
 
procmon = icl_get_procmon_ref_values(dev_priv, phy);
 
+   drm_dbg_kms(&dev_priv->drm,
+   "Combo PHY %c PROCMON values : 0x%x, 0x%x, 0x%x\n",
+   phy_name(phy), procmon->dw1, procmon->dw9, procmon->dw10);
+
ret = check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW1(phy),
(0xff << 16) | 0xff, procmon->dw1);
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW9(phy),
-- 
2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation 
(rev3)
URL   : https://patchwork.freedesktop.org/series/96289/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21445


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 35)
--

  Additional (2): fi-skl-guc fi-pnv-d510 
  Missing(6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan fi-icl-u2 bat-adlp-4 
fi-ctg-p8600 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@reset:
- {fi-tgl-dsi}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-tgl-dsi/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-tgl-dsi/igt@i915_selftest@l...@reset.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4:  [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +28 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-plain-flip@c-dp1:
- fi-cfl-8109u:   [PASS][9] -> [FAIL][10] ([i915#4165])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u:   [PASS][11] -> [DMESG-WARN][12] ([i915#295]) +13 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][14] ([fdo#109271]) +53 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][15] ([i915#2940]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][17] ([i915#2940]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}:   [DMESG-WARN][19] ([i915#3303]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10789/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21445/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_

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

[Maarten Lankhorst]

Hi Dave and Dan,

Last pull request for me for v5.15 I hope.
Out for vacation until the third week of november,
Maxime offered to do the remainder of v5.15.

~Maarten

drm-misc-fixes-2021-10-26:
drm-misc-fixes for v5.15-rc8:
- Fix fence leak in ttm_transfered_destroy.
- Add quirk for Aya Neo 2021
- Reset property count for each drm damage selftest so full run will work 
correctly.
The following changes since commit 74056092ff415e7e20ce2544689b32ee811c4f0b:

  drm/kmb: Enable ADV bridge after modeset (2021-10-21 11:08:09 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-10-26

for you to fetch changes up to ee71fb6c4d99c51f2d82a32c503c872b7e40e7f7:

  drm/i915/selftests: Properly reset mock object propers for each test 
(2021-10-22 11:09:45 +0200)


drm-misc-fixes for v5.15-rc8:
- Fix fence leak in ttm_transfered_destroy.
- Add quirk for Aya Neo 2021
- Reset property count for each drm damage selftest so full run will work 
correctly.


Bryant Mairs (1):
  drm: panel-orientation-quirks: Add quirk for Aya Neo 2021

Christian König (1):
  drm/ttm: fix memleak in ttm_transfered_destroy

Daniel Vetter (1):
  drm/i915/selftests: Properly reset mock object propers for each test

 drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
 drivers/gpu/drm/selftests/test-drm_damage_helper.c | 1 +
 drivers/gpu/drm/ttm/ttm_bo_util.c  | 1 +
 3 files changed, 8 insertions(+)