Re: [Intel-gfx] [RFC][PATCH v3 13/33] timers: drm: Use timer_shutdown_sync() before freeing timer

[Steven Rostedt]

[ Once again, quilt fails the MIME coding ]

From: "Steven Rostedt (Google)" 

Before a timer is freed, timer_shutdown_sync() must be called.

Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/

Cc: "Noralf Trønnes" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Steven Rostedt (Google) 
---
 drivers/gpu/drm/gud/gud_pipe.c   | 2 +-
 drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index 7c6dc2bcd14a..08429bdd57cf 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -272,7 +272,7 @@ static int gud_usb_bulk(struct gud_device *gdrm, size_t len)
 
usb_sg_wait(&ctx.sgr);
 
-   if (!del_timer_sync(&ctx.timer))
+   if (!timer_shutdown_sync(&ctx.timer))
ret = -ETIMEDOUT;
else if (ctx.sgr.status < 0)
ret = ctx.sgr.status;
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..bfaa9a67dc35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -465,7 +465,7 @@ static void irq_i915_sw_fence_work(struct irq_work *wrk)
struct i915_sw_dma_fence_cb_timer *cb =
container_of(wrk, typeof(*cb), work);
 
-   del_timer_sync(&cb->timer);
+   timer_shutdown_sync(&cb->timer);
dma_fence_put(cb->dma);
 
kfree_rcu(cb, rcu);
-- 
2.35.1

[Intel-gfx] [RFC][PATCH v3 00/33] timers: Use timer_shutdown*() before freeing timers

[Steven Rostedt]

Back in April, I posted an RFC patch set to help mitigate a common issue
where a timer gets armed just before it is freed, and when the timer
goes off, it crashes in the timer code without any evidence of who the
culprit was. I got side tracked and never finished up on that patch set.
Since this type of crash is still our #1 crash we are seeing in the field,
it has become a priority again to finish it.

This is v3 of that patch set. Thomas Gleixner posted an untested version
that makes timer->function NULL as the flag that it is shutdown. I took that
code, tested it (fixed it up), added more comments, and changed the
name to timer_shutdown_sync(). I also converted it to use WARN_ON_ONCE()
instead of just WARN_ON() as Linus asked for.

I then created a trivial coccinelle script to find where del_timer*()
is called before being freed, and converted them all to timer_shutdown*()
(There was a couple that still used del_timer() instead of del_timer_sync()).

I also updated DEBUG_OBJECTS_TIMERS to check from where the timer is ever
armed, to calling of timer_shutdown_sync(), and it will trigger if a timer
is freed in between. The current way is to only check if the timer is armed,
but that means it only triggers if the race condition is hit, and with
experience, it's not run on enough machines to catch all of them. By triggering
it from the time the timer is armed to the time it is shutdown, it catches
all potential cases even if the race condition is not hit.

I went though the result of the cocinelle script, and updated the locations.
Some locations were caught by DEBUG_OBJECTS_TIMERS as the coccinelle script
only checked for timers being freed in the same function as the del_timer*().

Ideally, I would have the first patch go into this rc cycle, which is mostly
non functional as it will allow the other patches to come in via the respective
subsystems in the next merge window.

Changes since v2: 
https://lore.kernel.org/all/20221027150525.753064...@goodmis.org/

 - Talking with Thomas Gleixner, he wanted a better name space and to remove
   the "del_" portion of the API.

 - Since there's now a shutdown interface that does not synchronize, to keep
   it closer to del_timer() and del_timer_sync(), the API is now:

timer_shutdown() - same as del_timer() but deactivates the timer.

timer_shutdown_sync() - same as del_timer_sync() but deactivates the timer.

 - Added a few more locations that got converted.

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace/timers

Head SHA1: 25106f0bb7968b3e8c746a7853f44b51840746c3


Steven Rostedt (Google) (33):
  timers: Add timer_shutdown_sync() and timer_shutdown() to be called 
before freeing timers
  timers: s390/cmm: Use timer_shutdown_sync() before freeing timer
  timers: sh: Use timer_shutdown_sync() before freeing timer
  timers: block: Use timer_shutdown_sync() before freeing timer
  timers: ACPI: Use timer_shutdown_sync() before freeing timer
  timers: atm: Use timer_shutdown_sync() before freeing timer
  timers: PM: Use timer_shutdown_sync()
  timers: Bluetooth: Use timer_shutdown_sync() before freeing timer
  timers: hangcheck: Use timer_shutdown_sync() before freeing timer
  timers: ipmi: Use timer_shutdown_sync() before freeing timer
  random: use timer_shutdown_sync() before freeing timer
  timers: dma-buf: Use timer_shutdown_sync() before freeing timer
  timers: drm: Use timer_shutdown_sync() before freeing timer
  timers: HID: Use timer_shutdown_sync() before freeing timer
  timers: Input: Use timer_shutdown_sync() before freeing timer
  timers: mISDN: Use timer_shutdown_sync() before freeing timer
  timers: leds: Use timer_shutdown_sync() before freeing timer
  timers: media: Use timer_shutdown_sync() before freeing timer
  timers: net: Use timer_shutdown_sync() before freeing timer
  timers: usb: Use timer_shutdown_sync() before freeing timer
  timers: cgroup: Use timer_shutdown_sync() before freeing timer
  timers: workqueue: Use timer_shutdown_sync() before freeing timer
  timers: nfc: pn533: Use timer_shutdown_sync() before freeing timer
  timers: pcmcia: Use timer_shutdown_sync() before freeing timer
  timers: scsi: Use timer_shutdown_sync() and timer_shutdown() before 
freeing timer
  timers: tty: Use timer_shutdown_sync() before freeing timer
  timers: ext4: Use timer_shutdown_sync() before freeing timer
  timers: fs/nilfs2: Use timer_shutdown_sync() before freeing timer
  timers: ALSA: Use timer_shutdown_sync() before freeing timer
  timers: jbd2: Use timer_shutdown() before freeing timer
  timers: sched/psi: Use timer_shutdown_sync() before freeing timer
  timers: x86/mce: Use __init_timer() for resetting timers
  timers: Expand DEBUG_OBJECTS_TIMER to check if it ever was used


 .../RCU/Design/Requirements/Requirements.rst   |   2 +-
 Documentation/core-api/local_ops.rst 

[Intel-gfx] [RFC][PATCH v3 13/33] timers: drm: Use timer_shutdown_sync() before freeing timer

[Steven Rostedt]

From: "Steven Rostedt (Google)" 

Before a timer is freed, timer_shutdown_sync() must be called.

Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/

Cc: "Noralf Trønnes" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Steven Rostedt (Google) 
---
 drivers/gpu/drm/gud/gud_pipe.c   | 2 +-
 drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index 7c6dc2bcd14a..08429bdd57cf 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -272,7 +272,7 @@ static int gud_usb_bulk(struct gud_device *gdrm, size_t len)
 
usb_sg_wait(&ctx.sgr);
 
-   if (!del_timer_sync(&ctx.timer))
+   if (!timer_shutdown_sync(&ctx.timer))
ret = -ETIMEDOUT;
else if (ctx.sgr.status < 0)
ret = ctx.sgr.status;
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..bfaa9a67dc35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -465,7 +465,7 @@ static void irq_i915_sw_fence_work(struct irq_work *wrk)
struct i915_sw_dma_fence_cb_timer *cb =
container_of(wrk, typeof(*cb), work);
 
-   del_timer_sync(&cb->timer);
+   timer_shutdown_sync(&cb->timer);
dma_fence_put(cb->dma);
 
kfree_rcu(cb, rcu);
-- 
2.35.1

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Create resized LUTs for ivb+ split gamma mode

[Nautiyal, Ankit K]

Patch looks good to me.

Minor suggestions inline:

On 10/26/2022 5:09 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently when opeating in split gamma mode we do the

nitpick: 'operating' typo.

"skip ever other sw LUT entry" trick in the low level
LUT programming/readout functions. That is very annoying
and a big hinderance to revamping the color management
uapi.

Let's get rid of that problem by making half sized copies
of the software LUTs and plugging those into the internal
{pre,post}_csc_lut attachment points (instead of the sticking
the uapi provide sw LUTs there directly).

With this the low level stuff will operate purely in terms
the hardware LUT sizes, and all uapi nonsense is contained
to the atomic check phase. The one thing we do lose is
intel_color_assert_luts() since we no longer have a way to
check that the uapi LUTs were correctly used when generating
the internal copies. But that seems like a price worth paying.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/display/intel_color.c | 81 +-
  1 file changed, 64 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 33871bfacee7..d48904f90e3a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -597,6 +597,30 @@ create_linear_lut(struct drm_i915_private *i915, int 
lut_size)
return blob;
  }
  
+static struct drm_property_blob *

+create_resized_lut(struct drm_i915_private *i915,
+  const struct drm_property_blob *blob_in, int lut_out_size)
+{
+   int i, lut_in_size = drm_color_lut_size(blob_in);
+   struct drm_property_blob *blob_out;
+   const struct drm_color_lut *lut_in;
+   struct drm_color_lut *lut_out;
+
+   blob_out = drm_property_create_blob(&i915->drm,
+   sizeof(lut_out[0]) * lut_out_size,
+   NULL);
+   if (IS_ERR(blob_out))
+   return blob_out;
+
+   lut_in = blob_in->data;
+   lut_out = blob_out->data;
+
+   for (i = 0; i < lut_out_size; i++)
+   lut_out[i] = lut_in[i * (lut_in_size - 1) / (lut_out_size - 1)];
+
+   return blob_out;
+}
+
  static void i9xx_load_lut_8(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
  {
@@ -723,19 +747,14 @@ static void ivb_load_lut_10(struct intel_crtc *crtc,
u32 prec_index)
  {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
-   int hw_lut_size = ivb_lut_10_size(prec_index);
const struct drm_color_lut *lut = blob->data;
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
  
-	for (i = 0; i < hw_lut_size; i++) {

-   /* We discard half the user entries in split gamma mode */
-   const struct drm_color_lut *entry =
-   &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
-
+   for (i = 0; i < lut_size; i++) {
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe), prec_index++);
intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
- ilk_lut_10(entry));
+ ilk_lut_10(&lut[i]));
}
  
  	/*

@@ -751,7 +770,6 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
u32 prec_index)
  {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
-   int hw_lut_size = ivb_lut_10_size(prec_index);
const struct drm_color_lut *lut = blob->data;
int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
@@ -759,14 +777,9 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
intel_de_write_fw(i915, PREC_PAL_INDEX(pipe),
  prec_index | PAL_PREC_AUTO_INCREMENT);
  
-	for (i = 0; i < hw_lut_size; i++) {

-   /* We discard half the user entries in split gamma mode */
-   const struct drm_color_lut *entry =
-   &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
-
+   for (i = 0; i < lut_size; i++)
intel_de_write_fw(i915, PREC_PAL_DATA(pipe),
- ilk_lut_10(entry));
-   }
+ ilk_lut_10(&lut[i]));
  
  	/*

 * Reset the index, otherwise it prevents the legacy palette to be
@@ -1343,7 +1356,7 @@ void intel_color_assert_luts(const struct 
intel_crtc_state *crtc_state)
crtc_state->pre_csc_lut != 
i915->display.color.glk_linear_degamma_lut);
drm_WARN_ON(&i915->drm,
crtc_state->post_csc_lut != 
crtc_state->hw.gamma_lut);
-   } else {
+   } else if (crtc_state->gamma_mode != GAMMA_MODE_MODE_SPLIT) {
drm_WARN_ON(&i915->drm,
crtc_state->pre_csc_lut != crtc_state->hw.d

Re: [Intel-gfx] [PATCH] i915/pmu: Use a faster read for 2x32 mmio reads

[Dixit, Ashutosh]

On Thu, 03 Nov 2022 11:07:05 -0700, Umesh Nerlige Ramappa wrote:
>

Hi Umesh,

> PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower
> 32 bit registers are read in a loop, there is a latency involved in
> getting the GT timestamp. To reduce the latency, define another version
> of the helper that requires caller to acquire uncore->spinlock and
> necessary forcewakes.

Why does this reduces the latency compared to intel_uncore_read64_2x32?

Thanks.
--
Ashutosh

> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 26 ---
>  drivers/gpu/drm/i915/intel_uncore.h   | 24 +
>  2 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 693b07a97789..64b0193c9ee4 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1252,6 +1252,28 @@ static u32 gpm_timestamp_shift(struct intel_gt *gt)
>   return 3 - shift;
>  }
>
> +static u64 gpm_timestamp(struct intel_uncore *uncore, ktime_t *now)
> +{
> + enum forcewake_domains fw_domains;
> + u64 reg;
> +
> + /* Assume MISC_STATUS0 and MISC_STATUS1 are in the same fw_domain */
> + fw_domains = intel_uncore_forcewake_for_reg(uncore,
> + MISC_STATUS0,
> + FW_REG_READ);
> +
> + spin_lock_irq(&uncore->lock);
> + intel_uncore_forcewake_get__locked(uncore, fw_domains);
> +
> + reg = intel_uncore_read64_2x32_fw(uncore, MISC_STATUS0, MISC_STATUS1);
> + *now = ktime_get();
> +
> + intel_uncore_forcewake_put__locked(uncore, fw_domains);
> + spin_unlock_irq(&uncore->lock);
> +
> + return reg;
> +}
> +
>  static void guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
> @@ -1261,10 +1283,8 @@ static void guc_update_pm_timestamp(struct intel_guc 
> *guc, ktime_t *now)
>   lockdep_assert_held(&guc->timestamp.lock);
>
>   gt_stamp_hi = upper_32_bits(guc->timestamp.gt_stamp);
> - gpm_ts = intel_uncore_read64_2x32(gt->uncore, MISC_STATUS0,
> -   MISC_STATUS1) >> guc->timestamp.shift;
> + gpm_ts = gpm_timestamp(gt->uncore, now) >> guc->timestamp.shift;
>   gt_stamp_lo = lower_32_bits(gpm_ts);
> - *now = ktime_get();
>
>   if (gt_stamp_lo < lower_32_bits(guc->timestamp.gt_stamp))
>   gt_stamp_hi++;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
> b/drivers/gpu/drm/i915/intel_uncore.h
> index 5449146a0624..dd0cf7d4ce6c 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -455,6 +455,30 @@ static inline void intel_uncore_rmw_fw(struct 
> intel_uncore *uncore,
>   intel_uncore_write_fw(uncore, reg, val);
>  }
>
> +/*
> + * Introduce a _fw version of intel_uncore_read64_2x32 so that the 64 bit
> + * register read is as quick as possible.
> + *
> + * NOTE:
> + * Prior to calling this function, the caller must
> + * 1. obtain the uncore->lock
> + * 2. acquire forcewakes for the upper and lower register
> + */
> +static inline u64
> +intel_uncore_read64_2x32_fw(struct intel_uncore *uncore,
> + i915_reg_t lower_reg, i915_reg_t upper_reg)
> +{
> + u32 upper, lower, old_upper, loop = 0;
> +
> + upper = intel_uncore_read_fw(uncore, upper_reg);
> + do {
> + old_upper = upper;
> + lower = intel_uncore_read_fw(uncore, lower_reg);
> + upper = intel_uncore_read_fw(uncore, upper_reg);
> + } while (upper != old_upper && loop++ < 2);
> + return (u64)upper << 32 | lower;
> +}
> +
>  static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
>   i915_reg_t reg, u32 val,
>   u32 mask, u32 expected_val)
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/guc/slpc: Add selftest for slpc tile-tile interaction

[Belgaumkar, Vinay]

On 10/30/2022 10:14 PM, Riana Tauro wrote:

Run a workload on tiles simultaneously by requesting for RP0 frequency.
Pcode can however limit the frequency being granted due to throttling
reasons. This test fails if there is any throttling
It actually passes if there was throttling. Only fails if actual 
frequency does not reach RP0 AND there was no throttle reasons.


v2: Fix build error
v3: Use IS_ERR_OR_NULL to check worker
 Addressed cosmetic review comments (Tvrtko)

Signed-off-by: Riana Tauro 
---
  drivers/gpu/drm/i915/gt/selftest_slpc.c | 60 +
  1 file changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c 
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index 82ec95a299f6..427e714b432b 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -13,6 +13,14 @@ enum test_type {
VARY_MAX,
MAX_GRANTED,
SLPC_POWER,
+   TILE_INTERACTION,
+};
+
+struct slpc_thread {
+   struct kthread_worker *worker;
+   struct kthread_work work;
+   struct intel_gt *gt;
+   int result;
  };
  
  static int slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 freq)

@@ -310,6 +318,7 @@ static int run_test(struct intel_gt *gt, int test_type)
break;
  
  		case MAX_GRANTED:

+   case TILE_INTERACTION:
/* Media engines have a different RP0 */
if (engine->class == VIDEO_DECODE_CLASS ||
engine->class == VIDEO_ENHANCEMENT_CLASS) {


So, for MTL, this will just stop the spinner from running on the media 
tile and return 0, right? Not sure we are testing anything in that case 
(just one spinner running on the Render tile). Should we try and find 
out what media RP0 is and expect that here?


Thanks,

Vinay.


@@ -426,6 +435,56 @@ static int live_slpc_power(void *arg)
return ret;
  }
  
+static void slpc_spinner_thread(struct kthread_work *work)

+{
+   struct slpc_thread *thread = container_of(work, typeof(*thread), work);
+
+   thread->result = run_test(thread->gt, TILE_INTERACTION);
+}
+
+static int live_slpc_tile_interaction(void *arg)
+{
+   struct drm_i915_private *i915 = arg;
+   struct intel_gt *gt;
+   struct slpc_thread *threads;
+   int i = 0, ret = 0;
+
+   threads = kcalloc(I915_MAX_GT, sizeof(*threads), GFP_KERNEL);
+   if (!threads)
+   return -ENOMEM;
+
+   for_each_gt(gt, i915, i) {
+   threads[i].worker = kthread_create_worker(0, 
"igt/slpc_parallel:%d", gt->info.id);
+
+   if (IS_ERR(threads[i].worker)) {
+   ret = PTR_ERR(threads[i].worker);
+   break;
+   }
+
+   threads[i].gt = gt;
+   kthread_init_work(&threads[i].work, slpc_spinner_thread);
+   kthread_queue_work(threads[i].worker, &threads[i].work);
+   }
+
+   for_each_gt(gt, i915, i) {
+   int status;
+
+   if (IS_ERR_OR_NULL(threads[i].worker))
+   continue;
+
+   kthread_flush_work(&threads[i].work);
+   status = READ_ONCE(threads[i].result);
+   if (status && !ret) {
+   pr_err("%s GT %d failed ", __func__, gt->info.id);
+   ret = status;
+   }
+   kthread_destroy_worker(threads[i].worker);
+   }
+
+   kfree(threads);
+   return ret;
+}
+
  int intel_slpc_live_selftests(struct drm_i915_private *i915)
  {
static const struct i915_subtest tests[] = {
@@ -433,6 +492,7 @@ int intel_slpc_live_selftests(struct drm_i915_private *i915)
SUBTEST(live_slpc_vary_min),
SUBTEST(live_slpc_max_granted),
SUBTEST(live_slpc_power),
+   SUBTEST(live_slpc_tile_interaction),
};
  
  	struct intel_gt *gt;

Re: [Intel-gfx] [PATCH v2 0/7] vfio-ccw parent rework

[Matthew Rosato]

On 11/3/22 5:56 PM, Alex Williamson wrote:
> On Wed,  2 Nov 2022 16:01:45 +0100
> Eric Farman  wrote:
> 
>> Hi all,
>>
>> Here is an update to the vfio-ccw lifecycle changes that have been discussed
>> in various forms over the past year [1][2] or so, and which I dusted off
>> recently.
>>
>> Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
>> In summary, the mdev pieces are split out of vfio_ccw_private and into a
>> new vfio_ccw_parent struct that will continue to follow today's lifecycle.
>> The remainder (bulk) of the private struct moves to follow the mdev
>> probe/remove pair. There's opportunity for further separation of the
>> things in the private struct, which would simplify some of the vfio-ccw
>> code, but it got too hairy as I started that. Once vfio-ccw is no longer
>> considered unique, those cleanups can happen at our leisure. 
>>
>> Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of
>> vfio_alloc_device, and thus removes vfio_init_device from the outside world.
>>
>> Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello,
>> CC list!), letting it be handled by vfio_device_release directly.
> 
> Looks like another spin is pending, but the vfio core and collateral
> changes in 6 and 7 look good to me.  Would this go in through the vfio
> or s390 tree?  I'd be happy to merge or provide a branch, depending on
> the route.
> 
> For 6 & 7:
> Acked-by: Alex Williamson 
> 
> Thanks,
> Alex

LGTM with those few comments addressed -- @Eric please send a v3 and I think 
it's ready.

I would suggest vfio tree to reduce the chance of conflicts; this touches 
various vfio drivers (and main) with the last patches while the s390 hits are 
at least all contained to the vfio-ccw driver code.

Re: [Intel-gfx] [PATCH v2 7/7] vfio: Remove vfio_free_device

[Matthew Rosato]

On 11/2/22 11:01 AM, Eric Farman wrote:
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
> 
> Signed-off-by: Eric Farman 
> Reviewed-by: Jason Gunthorpe 
> Reviewed-by: Kevin Tian 

Reviewed-by: Matthew Rosato 

Re: [Intel-gfx] [PATCH v2 6/7] vfio/ccw: replace vfio_init_device with _alloc_

[Matthew Rosato]

On 11/2/22 11:01 AM, Eric Farman wrote:
> Now that we have a reasonable separation of structs that follow
> the subchannel and mdev lifecycles, there's no reason we can't
> call the official vfio_alloc_device routine for our private data,
> and behave like everyone else.
> 
> Signed-off-by: Eric Farman 
> Reviewed-by: Kevin Tian 
> ---
>  drivers/s390/cio/vfio_ccw_drv.c | 18 --
>  drivers/s390/cio/vfio_ccw_ops.c | 28 ++--
>  drivers/s390/cio/vfio_ccw_private.h |  2 --
>  drivers/vfio/vfio_main.c| 10 +-
>  include/linux/vfio.h|  2 --
>  5 files changed, 23 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
> index 041cc0860f0e..fd58c0f4f8cc 100644
> --- a/drivers/s390/cio/vfio_ccw_drv.c
> +++ b/drivers/s390/cio/vfio_ccw_drv.c
> @@ -151,24 +151,6 @@ static void vfio_ccw_sch_irq(struct subchannel *sch)
>   vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
>  }
>  
> -void vfio_ccw_free_private(struct vfio_ccw_private *private)
> -{
> - struct vfio_ccw_crw *crw, *temp;
> -
> - list_for_each_entry_safe(crw, temp, &private->crw, next) {
> - list_del(&crw->next);
> - kfree(crw);
> - }
> -
> - kmem_cache_free(vfio_ccw_crw_region, private->crw_region);
> - kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
> - kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
> - kmem_cache_free(vfio_ccw_io_region, private->io_region);
> - kfree(private->cp.guest_cp);
> - mutex_destroy(&private->io_mutex);
> - kfree(private);
> -}
> -
>  static void vfio_ccw_free_parent(struct device *dev)
>  {
>   struct vfio_ccw_parent *parent = container_of(dev, struct 
> vfio_ccw_parent, dev);
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index 8a929a9cf3c6..1155f8bcedd9 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -102,15 +102,10 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
>   struct vfio_ccw_private *private;
>   int ret;
>  
> - private = kzalloc(sizeof(*private), GFP_KERNEL);
> - if (!private)
> - return -ENOMEM;
> -
> - ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
> - if (ret) {
> - kfree(private);
> - return ret;
> - }
> + private = vfio_alloc_device(vfio_ccw_private, vdev, &mdev->dev,
> + &vfio_ccw_dev_ops);
> + if (IS_ERR(private))
> + return PTR_ERR(private);

OK, and now it makes sense to switch to IS_ERR since _vfio_alloc_device uses 
ERR_PTR.  

Reviewed-by: Matthew Rosato 

Re: [Intel-gfx] [PATCH v2 5/7] vfio/ccw: remove release completion

[Matthew Rosato]

On 11/2/22 11:01 AM, Eric Farman wrote:
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
> 
> Signed-off-by: Eric Farman 
> Reviewed-by: Kevin Tian 

Reviewed-by: Matthew Rosato 

> ---
>  drivers/s390/cio/vfio_ccw_ops.c | 14 +-
>  drivers/s390/cio/vfio_ccw_private.h |  3 ---
>  2 files changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index e45d4acb109b..8a929a9cf3c6 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -54,7 +54,6 @@ static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
>   INIT_LIST_HEAD(&private->crw);
>   INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
>   INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
> - init_completion(&private->release_comp);
>  
>   private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
>  GFP_KERNEL);
> @@ -137,7 +136,7 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device 
> *vdev)
>   struct vfio_ccw_private *private =
>   container_of(vdev, struct vfio_ccw_private, vdev);
>  
> - complete(&private->release_comp);
> + vfio_ccw_free_private(private);
>  }
>  
>  static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
> @@ -155,17 +154,6 @@ static void vfio_ccw_mdev_remove(struct mdev_device 
> *mdev)
>  
>   dev_set_drvdata(&parent->dev, NULL);
>   vfio_put_device(&private->vdev);
> - /*
> -  * Wait for all active references on mdev are released so it
> -  * is safe to defer kfree() to a later point.
> -  *
> -  * TODO: the clean fix is to split parent/mdev info from ccw
> -  * private structure so each can be managed in its own life
> -  * cycle.
> -  */
> - wait_for_completion(&private->release_comp);
> -
> - vfio_ccw_free_private(private);
>  }
>  
>  static int vfio_ccw_mdev_open_device(struct vfio_device *vdev)
> diff --git a/drivers/s390/cio/vfio_ccw_private.h 
> b/drivers/s390/cio/vfio_ccw_private.h
> index 747aba5f5272..2278fd38d34e 100644
> --- a/drivers/s390/cio/vfio_ccw_private.h
> +++ b/drivers/s390/cio/vfio_ccw_private.h
> @@ -102,7 +102,6 @@ struct vfio_ccw_parent {
>   * @req_trigger: eventfd ctx for signaling userspace to return device
>   * @io_work: work for deferral process of I/O handling
>   * @crw_work: work for deferral process of CRW handling
> - * @release_comp: synchronization helper for vfio device release
>   */
>  struct vfio_ccw_private {
>   struct vfio_device vdev;
> @@ -126,8 +125,6 @@ struct vfio_ccw_private {
>   struct eventfd_ctx  *req_trigger;
>   struct work_struct  io_work;
>   struct work_struct  crw_work;
> -
> - struct completion   release_comp;
>  } __aligned(8);
>  
>  int vfio_ccw_sch_quiesce(struct subchannel *sch);

Re: [Intel-gfx] [PATCH v2 4/7] vfio/ccw: move private to mdev lifecycle

[Matthew Rosato]

On 11/2/22 11:01 AM, Eric Farman wrote:
> Now that the mdev parent data is split out into its own struct,
> it is safe to move the remaining private data to follow the
> mdev probe/remove lifecycle. The mdev parent data will remain
> where it is, and follow the subchannel and the css driver
> interfaces.
> 
> Signed-off-by: Eric Farman 
> ---
>  drivers/s390/cio/vfio_ccw_drv.c | 15 +--
>  drivers/s390/cio/vfio_ccw_ops.c | 26 +-
>  drivers/s390/cio/vfio_ccw_private.h |  2 ++
>  3 files changed, 16 insertions(+), 27 deletions(-)
> 

...

> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index eb0b8cc210bb..e45d4acb109b 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -100,15 +100,20 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
>  {
>   struct subchannel *sch = to_subchannel(mdev->dev.parent);
>   struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> - struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
> + struct vfio_ccw_private *private;
>   int ret;
>  
> - if (private->state == VFIO_CCW_STATE_NOT_OPER)
> - return -ENODEV;
> + private = kzalloc(sizeof(*private), GFP_KERNEL);
> + if (!private)
> + return -ENOMEM;

Ha, looks like you time traveled and took my advice :)

In fact it looks like some of my other comments from patch 1 get cleaned up 
here too -- but would still be good to make those changes in patch 1 for 
completeness/bisect.

Reviewed-by: Matthew Rosato 

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  include/drm/gpu_scheduler.h

between commit:

  7b476affcccf ("drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flag")

from Linus' tree and commit:

  4d5230b50dd4 ("drm/scheduler: add drm_sched_job_add_resv_dependencies")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/drm/gpu_scheduler.h
index ca11716d084a,e40baefadc3a..
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@@ -32,15 -32,8 +32,17 @@@
  
  #define MAX_WAIT_SCHED_ENTITY_Q_EMPTY msecs_to_jiffies(1000)
  
 +/**
 + * DRM_SCHED_FENCE_DONT_PIPELINE - Prefent dependency pipelining
 + *
 + * Setting this flag on a scheduler fence prevents pipelining of jobs 
depending
 + * on this fence. In other words we always insert a full CPU round trip before
 + * dependen jobs are pushed to the hw queue.
 + */
 +#define DRM_SCHED_FENCE_DONT_PIPELINE DMA_FENCE_FLAG_USER_BITS
 +
+ enum dma_resv_usage;
+ struct dma_resv;
  struct drm_gem_object;
  
  struct drm_gpu_scheduler;


pgpMOON5oXjwc.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [PATCH v2 1/7] vfio/ccw: create a parent struct

[Matthew Rosato]

On 11/2/22 11:01 AM, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
> 
> The subchannel will point to the parent, and the parent will point
> to the private, for the areas where one or both are needed. Further
> separation of these structs will follow.
> 
> Signed-off-by: Eric Farman 
> ---
>  drivers/s390/cio/vfio_ccw_drv.c | 96 -
>  drivers/s390/cio/vfio_ccw_ops.c |  8 ++-
>  drivers/s390/cio/vfio_ccw_private.h | 20 --
>  3 files changed, 100 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
> index 7f5402fe857a..06022fb37b9d 100644
> --- a/drivers/s390/cio/vfio_ccw_drv.c
> +++ b/drivers/s390/cio/vfio_ccw_drv.c
> @@ -36,10 +36,19 @@ debug_info_t *vfio_ccw_debug_trace_id;
>   */
>  int vfio_ccw_sch_quiesce(struct subchannel *sch)
>  {
> - struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
>   DECLARE_COMPLETION_ONSTACK(completion);
>   int iretry, ret = 0;
>  
> + /*
> +  * Probably an impossible situation, after being called through
> +  * FSM callbacks. But in the event it did, register a warning
> +  * and return as if things were fine.
> +  */
> + if (WARN_ON(!private))
> + return 0;
> +
>   iretry = 255;
>   do {
>  
> @@ -121,7 +130,22 @@ static void vfio_ccw_crw_todo(struct work_struct *work)
>   */
>  static void vfio_ccw_sch_irq(struct subchannel *sch)
>  {
> - struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
> +
> + /*
> +  * The subchannel should still be disabled at this point,
> +  * so an interrupt would be quite surprising. As with an
> +  * interrupt while the FSM is closed, let's attempt to
> +  * disable the subchannel again.
> +  */
> + if (!private) {
> + VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: unexpected interrupt\n",
> + sch->schid.cssid, sch->schid.ssid, sch->schid.sch_no);
> +
> + cio_disable_subchannel(sch);
> + return;
> + }
>  
>   inc_irq_stat(IRQIO_CIO);
>   vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
> @@ -201,10 +225,19 @@ static void vfio_ccw_free_private(struct 
> vfio_ccw_private *private)
>   mutex_destroy(&private->io_mutex);
>   kfree(private);
>  }
> +
> +static void vfio_ccw_free_parent(struct device *dev)
> +{
> + struct vfio_ccw_parent *parent = container_of(dev, struct 
> vfio_ccw_parent, dev);
> +
> + kfree(parent);
> +}
> +
>  static int vfio_ccw_sch_probe(struct subchannel *sch)
>  {
>   struct pmcw *pmcw = &sch->schib.pmcw;
>   struct vfio_ccw_private *private;
> + struct vfio_ccw_parent *parent;
>   int ret = -ENOMEM;
>  
>   if (pmcw->qf) {
> @@ -213,41 +246,62 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
>   return -ENODEV;
>   }
>  
> + parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> + if (IS_ERR(parent))
> + return PTR_ERR(parent);
The error here would be a null ptr due to failed alloc, how about:

if (!parent)
return -ENOMEM;

> +
> + dev_set_name(&parent->dev, "parent");
> + parent->dev.parent = &sch->dev;
> + parent->dev.release = &vfio_ccw_free_parent;
> + ret = device_register(&parent->dev);
> + if (ret)
> + goto out_free;
> +
>   private = vfio_ccw_alloc_private(sch);
> - if (IS_ERR(private))
> + if (IS_ERR(private)) {
> + put_device(&parent->dev);

As you said earlier, unregister_device()

>   return PTR_ERR(private);
> + }
>  
> - dev_set_drvdata(&sch->dev, private);
> + dev_set_drvdata(&sch->dev, parent);
> + dev_set_drvdata(&parent->dev, private);
>  
> - private->mdev_type.sysfs_name = "io";
> - private->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
> - private->mdev_types[0] = &private->mdev_type;
> - ret = mdev_register_parent(&private->parent, &sch->dev,
> + parent->mdev_type.sysfs_name = "io";
> + parent->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
> + parent->mdev_types[0] = &parent->mdev_type;
> + ret = mdev_register_parent(&parent->parent, &sch->dev,
>  &vfio_ccw_mdev_driver,
> -private->mdev_types, 1);
> +parent->mdev_types, 1);
>   if (ret)
> - goto out_free;
> + goto out_unreg;
>  
>   VFIO_CCW_MSG_EVENT(4, "bound to subchannel %x.%x.%04x\n",
>  sch->schid.cssid,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add Wa_14017073508 for SAMedia

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add Wa_14017073508 for SAMedia
URL   : https://patchwork.freedesktop.org/series/110502/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_110502v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 28)
--

  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][1] -> [SKIP][2] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110502v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html

  * igt@i915_selftest@live@hugepages:
- fi-bsw-nick:[PASS][3] -> [DMESG-FAIL][4] ([i915#6217])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110502v1/fi-bsw-nick/igt@i915_selftest@l...@hugepages.html

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

  
 Possible fixes 

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][6] ([i915#6298]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110502v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_110502v1

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110502v1: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

54f3b18ad901 drm/i915/mtl: Add Wa_14017073508 for SAMedia

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add Wa_14017073508 for SAMedia

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add Wa_14017073508 for SAMedia
URL   : https://patchwork.freedesktop.org/series/110502/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add Wa_14017073508 for SAMedia

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add Wa_14017073508 for SAMedia
URL   : https://patchwork.freedesktop.org/series/110502/
State : warning

== Summary ==

Error: dim checkpatch failed
0a9efdca81c1 drm/i915/mtl: Add Wa_14017073508 for SAMedia
-:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#114: FILE: drivers/gpu/drm/i915/i915_drv.h:743:
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
+   (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
&& \
+IS_GRAPHICS_STEP(__i915, since, until))

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

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c

[Fabio M. De Francesco]

On lunedì 17 ottobre 2022 11:37:19 CET Zhao Liu wrote:
> From: Zhao Liu 
> 
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
> 
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
> 
> In drm/i915/gem/i915_gem_shmem.c, the function shmem_pwrite() need to
> disable pagefault to eliminate the potential recursion fault[2]. But
> here __copy_from_user_inatomic() doesn't need to disable preemption and
> local mapping is valid for sched in/out.
> So it can use kmap_local_page() / kunmap_local() with
> pagefault_disable() / pagefault_enable() to replace atomic mapping.
> 
> [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com
> [2]: https://patchwork.freedesktop.org/patch/295840/
> 
> Suggested-by: Ira Weiny 
> Signed-off-by: Zhao Liu 
> ---
> Suggested by credits:
>   Ira: Referred to his suggestions about keeping pagefault_disable().
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

The commit message explains clearly and the changes to the code look good. The 
necessity to reuse pagefault_disable() / pagefault_enable() from the main 
kmap_atomic() side effect is a nice catch.

Reviewed-by: Fabio M. De Francesco 

Thanks!

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index f42ca1179f37..e279a3e30c02 
100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -472,11 +472,13 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
>   if (err < 0)
>   return err;
> 
> - vaddr = kmap_atomic(page);
> + vaddr = kmap_local_page(page);
> + pagefault_disable();
>   unwritten = __copy_from_user_inatomic(vaddr + pg,
> user_data,
> len);
> - kunmap_atomic(vaddr);
> + pagefault_enable();
> + kunmap_local(vaddr);
> 
>   err = aops->write_end(obj->base.filp, mapping, offset, 
len,
> len - unwritten, page, data);

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915/pmu: Use a faster read for 2x32 mmio reads

[Patchwork]

== Series Details ==

Series: i915/pmu: Use a faster read for 2x32 mmio reads
URL   : https://patchwork.freedesktop.org/series/110497/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_110497v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110497v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110497v1, 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_110497v1/index.html

Participating hosts (40 -> 28)
--

  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-rkl-guc/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-rkl-guc/igt@i915_module_l...@load.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][3] -> [INCOMPLETE][4] ([i915#3303] / 
[i915#4785])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][5] ([i915#4312])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-rkl-guc/igt@run...@aborted.html
- fi-hsw-g3258:   NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#4312] / 
[i915#4991])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-hsw-g3258/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][7] ([i915#7229]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][9] ([i915#6298]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110497v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_110497v1

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110497v1: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

06c490fee89b i915/pmu: Use a faster read for 2x32 mmio reads

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 0/7] vfio-ccw parent rework

[Alex Williamson]

On Wed,  2 Nov 2022 16:01:45 +0100
Eric Farman  wrote:

> Hi all,
> 
> Here is an update to the vfio-ccw lifecycle changes that have been discussed
> in various forms over the past year [1][2] or so, and which I dusted off
> recently.
> 
> Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
> In summary, the mdev pieces are split out of vfio_ccw_private and into a
> new vfio_ccw_parent struct that will continue to follow today's lifecycle.
> The remainder (bulk) of the private struct moves to follow the mdev
> probe/remove pair. There's opportunity for further separation of the
> things in the private struct, which would simplify some of the vfio-ccw
> code, but it got too hairy as I started that. Once vfio-ccw is no longer
> considered unique, those cleanups can happen at our leisure. 
> 
> Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of
> vfio_alloc_device, and thus removes vfio_init_device from the outside world.
> 
> Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello,
> CC list!), letting it be handled by vfio_device_release directly.

Looks like another spin is pending, but the vfio core and collateral
changes in 6 and 7 look good to me.  Would this go in through the vfio
or s390 tree?  I'd be happy to merge or provide a branch, depending on
the route.

For 6 & 7:
Acked-by: Alex Williamson 

Thanks,
Alex


> Looking forward to the feedback.
> 
> Thanks,
> Eric
> 
> [1] 
> https://lore.kernel.org/kvm/0-v3-57c1502c62fd+2190-ccw_mdev_...@nvidia.com/
> [2] https://lore.kernel.org/kvm/20220602171948.2790690-1-far...@linux.ibm.com/
> 
> v1->v2:
>  - Rebase to 6.1-rc3
>  - Patch 1:
>[EF] s/device_initialize/device_register/ and associated adjustments
>[MR] Add WARN_ON(!private) in vfio_ccw_sch_quiesce()
>[MR] Move struct vfio_ccw_parent to _private.h, instead of standalone file
>  - Patch 2:
>[MR] Added r-b (Thank you!)
>  - Patch 3:
>[MR] Update commit message to point to introduction of 
> private->release_comp
>[MR] Replace the remnants of vfio_ccw_alloc_private with a straight kzalloc
>[MR] Added r-b (Thank you!)
>  - Patch 5:
>[KT] Added r-b (Thank you!)
>  - Patch 6:
>[JG] Make vfio_init_device static
>[KT] Added r-b (Thank you!)
>  - Patch 7:
>[JG, KT] Added r-b (Thank you!)
> v1: https://lore.kernel.org/kvm/20221019162135.798901-1-far...@linux.ibm.com/
> 
> Eric Farman (7):
>   vfio/ccw: create a parent struct
>   vfio/ccw: remove private->sch
>   vfio/ccw: move private initialization to callback
>   vfio/ccw: move private to mdev lifecycle
>   vfio/ccw: remove release completion
>   vfio/ccw: replace vfio_init_device with _alloc_
>   vfio: Remove vfio_free_device
> 
>  drivers/gpu/drm/i915/gvt/kvmgt.c  |   1 -
>  drivers/s390/cio/vfio_ccw_chp.c   |   5 +-
>  drivers/s390/cio/vfio_ccw_drv.c   | 174 +++---
>  drivers/s390/cio/vfio_ccw_fsm.c   |  27 ++--
>  drivers/s390/cio/vfio_ccw_ops.c   | 107 +++-
>  drivers/s390/cio/vfio_ccw_private.h   |  37 --
>  drivers/s390/crypto/vfio_ap_ops.c |   6 -
>  drivers/vfio/fsl-mc/vfio_fsl_mc.c |   1 -
>  drivers/vfio/pci/vfio_pci_core.c  |   1 -
>  drivers/vfio/platform/vfio_amba.c |   1 -
>  drivers/vfio/platform/vfio_platform.c |   1 -
>  drivers/vfio/vfio_main.c  |  32 ++---
>  include/linux/vfio.h  |   3 -
>  samples/vfio-mdev/mbochs.c|   1 -
>  samples/vfio-mdev/mdpy.c  |   1 -
>  samples/vfio-mdev/mtty.c  |   1 -
>  16 files changed, 197 insertions(+), 202 deletions(-)
> 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915/pmu: Use a faster read for 2x32 mmio reads

[Patchwork]

== Series Details ==

Series: i915/pmu: Use a faster read for 2x32 mmio reads
URL   : https://patchwork.freedesktop.org/series/110497/
State : warning

== Summary ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for mei: add timeout to send

[Patchwork]

== Series Details ==

Series: mei: add timeout to send
URL   : https://patchwork.freedesktop.org/series/110495/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_110495v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 29)
--

  Additional (1): fi-kbl-soraka 
  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

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

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

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][4] ([i915#7099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

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

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][7] -> [INCOMPLETE][8] ([i915#146])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][10] ([i915#7229]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][12] ([i915#6298]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html

  
  [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#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#7099]: https://gitlab.freedesktop.org/drm/intel/issues/7099
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_110495v1

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110495v1: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

2c545cb5ea44 mei: add timeout to send

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mei: add timeout to send

[Patchwork]

== Series Details ==

Series: mei: add timeout to send
URL   : https://patchwork.freedesktop.org/series/110495/
State : warning

== Summary ==

Error: dim checkpatch failed
37ffcfbe1ad7 mei: add timeout to send
-:157: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#157: FILE: drivers/misc/mei/client.c:2087:
+   rets = wait_event_interruptible_timeout(cl->tx_wait,
+   cl->writing_state == MEI_WRITE_COMPLETE 
||

-:166: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#166: FILE: drivers/misc/mei/client.c:2096:
+   rets = wait_event_interruptible(cl->tx_wait,
+   cl->writing_state == MEI_WRITE_COMPLETE 
||

total: 0 errors, 0 warnings, 2 checks, 158 lines checked

[Intel-gfx] ✗ Fi.CI.BAT: failure for KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

[Patchwork]

== Series Details ==

Series: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if 
current->mm is not NULL
URL   : https://patchwork.freedesktop.org/series/110492/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_110492v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_110492v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_110492v1, 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_110492v1/index.html

Participating hosts (40 -> 29)
--

  Additional (1): fi-kbl-soraka 
  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@guc:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110492v1/fi-kbl-soraka/igt@i915_selftest@l...@guc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110492v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

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

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

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][5] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110492v1/fi-kbl-soraka/igt@i915_pm_...@module-reload.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][7] -> [INCOMPLETE][8] ([i915#146])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110492v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110492v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  
  [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#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_110492v1

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110492v1: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

4c114bdbebb1 KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check 
if current->mm is not NULL

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

[Patchwork]

== Series Details ==

Series: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if 
current->mm is not NULL
URL   : https://patchwork.freedesktop.org/series/110492/
State : warning

== Summary ==

Error: dim checkpatch failed
68f3d9527a29 KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check 
if current->mm is not NULL
-:78: WARNING:BAD_SIGN_OFF: Use a single space after To:
#78: 
To:

-:78: ERROR:BAD_SIGN_OFF: Unrecognized email address: ''
#78: 
To:

-:80: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#80: 
Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

-:125: WARNING:TYPO_SPELLING: 'an user' may be misspelled - perhaps 'a user'?
#125: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:1849:
+   pr_err("Test called without an user context!\n");
^^^

total: 1 errors, 3 warnings, 0 checks, 10 lines checked

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Untangle fbdev emulation and helpers (rev3)

[Patchwork]

== Series Details ==

Series: drm/fb-helper: Untangle fbdev emulation and helpers (rev3)
URL   : https://patchwork.freedesktop.org/series/109942/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_109942v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 28)
--

  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258:   [PASS][1] -> [INCOMPLETE][2] ([i915#3303] / 
[i915#4785])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109942v3/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][3] -> [INCOMPLETE][4] ([i915#146])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109942v3/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

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

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][6] ([i915#7229]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109942v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka:   [FAIL][8] ([i915#6298]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109942v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.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
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991
  [i915#6106]: https://gitlab.freedesktop.org/drm/intel/issues/6106
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_109942v3

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_109942v3: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ae46bcb0b7d0 drm/fb-helper: Clarify use of last_close and output_poll_changed
daf61100bb1f drm/fb-helper: Remove unnecessary include statements
5bc7dbd5e53a drm/fb-helper: Move generic fbdev emulation into separate source 
file
7adb21f8df4e drm/fb-helper: Set flag in struct drm_fb_helper for leaking 
physical addresses
c77ca859192a drm/fb-helper: Always initialize generic fbdev emulation
5fd001aac38a drm/fb_helper: Minimize damage-helper overhead
d85e46a760ab drm/fb-helper: Perform all fbdev I/O with the same implementation
a52ac23e9ed6 drm/fb-helper: Call fb_sync in I/O functions
63b548e3ddf9 drm/fb-helper: Disconnect damage worker from update logic
ee2185c8cab6 drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info 
postfix
8f19ec616ef7 drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info 
postfix
63f4182c1ebf drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper
dcd1217f9fc0 drm/fb-helper: Cleanup include statements in header file
577decb7032c drm/tve200: Include 
b1d8471f3017 drm/panel-ili9341: Include 
3d612badf8e8 drm/rockchip: Don't set struct drm_driver.output_poll_changed
9b541df21a0a drm/logicvc: Don't set struct drm_driver.output_poll_changed
35c0a7c68afa drm/ingenic: Don't set struct dr

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/fb-helper: Untangle fbdev emulation and helpers (rev3)

[Patchwork]

== Series Details ==

Series: drm/fb-helper: Untangle fbdev emulation and helpers (rev3)
URL   : https://patchwork.freedesktop.org/series/109942/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./a

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/fb-helper: Untangle fbdev emulation and helpers (rev3)

[Patchwork]

== Series Details ==

Series: drm/fb-helper: Untangle fbdev emulation and helpers (rev3)
URL   : https://patchwork.freedesktop.org/series/109942/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] ✓ Fi.CI.BAT: success for Add KUnit support for i915 driver

[Patchwork]

== Series Details ==

Series: Add KUnit support for i915 driver
URL   : https://patchwork.freedesktop.org/series/110483/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12339 -> Patchwork_110483v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 30)
--

  Additional (2): fi-kbl-soraka fi-tgl-dsi 
  Missing(12): fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 bat-adlp-4 
fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110483v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

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

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

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][4] ([i915#7099])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110483v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u:   [PASS][6] -> [INCOMPLETE][7] ([i915#146])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110483v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110483v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][9] ([i915#7229]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12339/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110483v1/fi-pnv-d510/igt@gem_exec_gttf...@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#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#7099]: https://gitlab.freedesktop.org/drm/intel/issues/7099
  [i915#7125]: https://gitlab.freedesktop.org/drm/intel/issues/7125
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


Build changes
-

  * Linux: CI_DRM_12339 -> Patchwork_110483v1

  CI-20190529: 20190529
  CI_DRM_12339: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7041: 40ea6325f69eb56653171c21b5d4977982a92d0a @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_110483v1: fafe2d945b3d76b8a7e32102311d8d0495724a3e @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

314cba5c1954 drm/i915: check if current->mm is not NULL
92389b73cc89 drm/i915: now that all functions are used, remove __maybe_unused
4d64e5b4e650 drm/i915: add perf selftests to KUnit
9c0cee4d3a02 drm/i915: add live selftests to KUnit
87e55cf24677

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches

[John Harrison]

On 11/3/2022 03:45, Jani Nikula wrote:

On Wed, 02 Nov 2022, John Harrison  wrote:

On 11/2/2022 07:20, Tvrtko Ursulin wrote:

On 02/11/2022 12:12, Jani Nikula wrote:

On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

At the end of each test, IGT does a drop caches call via sysfs with

sysfs?

Sorry, that was meant to say debugfs. I've also been working on some
sysfs IGT issues and evidently got my wires crossed!


special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system times
out (after 90s), attempts a bunch of state dump actions and then
reboots the system to recover it. Worst case, the CI system can't do
anything at all and then times out (after 1000s) and simply reboots.
Sometimes a serial port log of dmesg might be available, sometimes not.

So rather than making life hard for ourselves, change the timeout to
be 10s rather than infinite. Also, trigger the standard
wedge/reset/recover sequence so that testing can continue with a
working system (if possible).

Signed-off-by: John Harrison 
---
   drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae987e92251dd..9d916fbbfc27c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -641,6 +641,9 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,
     DROP_RESET_ACTIVE | \
     DROP_RESET_SEQNO | \
     DROP_RCU)
+
+#define DROP_IDLE_TIMEOUT    (HZ * 10)

I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only used
here.

So move here, dropping i915 prefix, next to the newly proposed one?

Sure, can do that.


I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in
gt/intel_gt.c.

Move there and rename to GT_IDLE_TIMEOUT?


I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in intel_gt_pm.c.

No action needed, maybe drop i915 prefix if wanted.


These two are totally unrelated and in code not being touched by this
change. I would rather not conflate changing random other things with
fixing this specific issue.


I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies.

Add _MS suffix if wanted.


My head spins.

I follow and raise that the newly proposed DROP_IDLE_TIMEOUT applies
to DROP_ACTIVE and not only DROP_IDLE.

My original intention for the name was that is the 'drop caches timeout
for intel_gt_wait_for_idle'. Which is quite the mouthful and hence
abbreviated to DROP_IDLE_TIMEOUT. But yes, I realised later that name
can be conflated with the DROP_IDLE flag. Will rename.



Things get refactored, code moves around, bits get left behind, who
knows. No reason to get too worked up. :) As long as people are taking
a wider view when touching the code base, and are not afraid to send
cleanups, things should be good.

On the other hand, if every patch gets blocked in code review because
someone points out some completely unrelated piece of code could be a
bit better then nothing ever gets fixed. If you spot something that you
think should be improved, isn't the general idea that you should post a
patch yourself to improve it?

The general idea is that every change should improve the driver. If you
need to modify something that's a mess, you fix the mess instead of
adding to the mess. You can't put the onus on cleaning up after you on
someone else.
Please point out in what way this patch is 'adding to the mess' or 
requiring some else to do additional 'cleaning up after'. As stated 
above, I have fixed up the issues pointed out which are related to the 
drop caches code. I don't agree that shoe-horning completely unrelated 
changes into random patches is a good thing. That makes it hard to work 
out what the patch is actually trying to do, it makes bisection more 
confusing, etc. Sure, maybe the unrelated change is trivial. But this 
change was supposed to be trivial too and already it has exploded into 
many hours of time spent not working on the things I am actually 
supposed to be working on.



Sure, the patch at hand is neglible, but hey, so are the fixes.
So feel free to post a trivial patch to fix them. And if 'the patch at 
hand is negligible' then why is it generating so much discussion and 
argument over how it the problem should be fixed irrespective of adding 
in yet more unrelated changes?


John.


BR,
Jani.





For the actual functional change at hand - it would be nice if code
paths in question could handle SIGINT and then we could punt the
decision on how long someone wants to wait purely to userspace. But
it's probably hard and it's only debugfs so whatever.


The code paths in question will already abort on a signal won't they?
Both intel_gt_wait_for_idle() and intel_guc_wait_for_pending_msg(),
which is where the uc_wait_for_idle eventu

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches

[John Harrison]

On 11/3/2022 02:18, Tvrtko Ursulin wrote:

On 03/11/2022 01:33, John Harrison wrote:

On 11/2/2022 07:20, Tvrtko Ursulin wrote:

On 02/11/2022 12:12, Jani Nikula wrote:

On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

At the end of each test, IGT does a drop caches call via sysfs with


sysfs?
Sorry, that was meant to say debugfs. I've also been working on some 
sysfs IGT issues and evidently got my wires crossed!





special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system 
times

out (after 90s), attempts a bunch of state dump actions and then
reboots the system to recover it. Worst case, the CI system can't do
anything at all and then times out (after 1000s) and simply reboots.
Sometimes a serial port log of dmesg might be available, sometimes 
not.


So rather than making life hard for ourselves, change the timeout to
be 10s rather than infinite. Also, trigger the standard
wedge/reset/recover sequence so that testing can continue with a
working system (if possible).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c

index ae987e92251dd..9d916fbbfc27c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -641,6 +641,9 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,
    DROP_RESET_ACTIVE | \
    DROP_RESET_SEQNO | \
    DROP_RCU)
+
+#define DROP_IDLE_TIMEOUT    (HZ * 10)


I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only 
used

here.


So move here, dropping i915 prefix, next to the newly proposed one?

Sure, can do that.




I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in
gt/intel_gt.c.


Move there and rename to GT_IDLE_TIMEOUT?

I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in 
intel_gt_pm.c.


No action needed, maybe drop i915 prefix if wanted.

These two are totally unrelated and in code not being touched by this 
change. I would rather not conflate changing random other things with 
fixing this specific issue.



I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies.


Add _MS suffix if wanted.


My head spins.


I follow and raise that the newly proposed DROP_IDLE_TIMEOUT applies 
to DROP_ACTIVE and not only DROP_IDLE.
My original intention for the name was that is the 'drop caches 
timeout for intel_gt_wait_for_idle'. Which is quite the mouthful and 
hence abbreviated to DROP_IDLE_TIMEOUT. But yes, I realised later 
that name can be conflated with the DROP_IDLE flag. Will rename.





Things get refactored, code moves around, bits get left behind, who 
knows. No reason to get too worked up. :) As long as people are 
taking a wider view when touching the code base, and are not afraid 
to send cleanups, things should be good.
On the other hand, if every patch gets blocked in code review because 
someone points out some completely unrelated piece of code could be a 
bit better then nothing ever gets fixed. If you spot something that 
you think should be improved, isn't the general idea that you should 
post a patch yourself to improve it?


There's two maintainers per branch and an order of magnitude or two 
more developers so it'd be nice if cleanups would just be incoming on 
self-initiative basis. ;)
It's not just maintainers that look at the code and spot problems. Where 
do you think patch set came from? It was not on my list of tasks to work 
on. No-one had logged this as a super urgent bug that needs to be fixed. 
I noticed a problem when trying to debug another issue and saw a way to 
improve the i915 debuggability. So I tried to fix it on a 
'self-initiative basis'. And already that trivial fix has ballooned into 
I don't know how many hours of work that has not been spent on doing the 
things I'm actually supposed to working on.


Likewise, the a bunch of other patches I have recently posted. They are 
just things I happened to spot and spontaneously decided to fix.


And if you don't have time to fix something yourself, you can always 
just log it as a piece of work that needs to be done and add it to the 
backlog of tasks. It will then get assigned to whoever actually has the 
time to do it according to how important it really is.


John.




For the actual functional change at hand - it would be nice if code 
paths in question could handle SIGINT and then we could punt the 
decision on how long someone wants to wait purely to userspace. But 
it's probably hard and it's only debugfs so whatever.


The code paths in question will already abort on a signal won't they? 
Both intel_gt_wait_for_idle() and intel_guc_wait_for_pending_msg(), 
which is where the uc_wait_for_idle eventually ends up, have an 
'if(signal_pending) return -EIN

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add KUnit support for i915 driver

[Patchwork]

== Series Details ==

Series: Add KUnit support for i915 driver
URL   : https://patchwork.freedesktop.org/series/110483/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add KUnit support for i915 driver

[Patchwork]

== Series Details ==

Series: Add KUnit support for i915 driver
URL   : https://patchwork.freedesktop.org/series/110483/
State : warning

== Summary ==

Error: dim checkpatch failed
1c12427bb8a0 drm/i915: export all selftest functions
100f0a51abe8 drm/i915: place selftest preparation on a separate function
0865f4e46dc3 drm/i915: allow running mock selftests via Kunit
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 11, in 
import git
ModuleNotFoundError: No module named 'git'
-:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#24: 
$ qemu-system-x86_64 -nodefaults -m 1024 -kernel 
.kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 
kunit_shutdown=reboot' -no-reboot -nographic -serial stdio

-:269: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#269: 
new file mode 100644

-:340: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#340: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:49:
+   pr_notice("Setting dangerous option KUnit %s - tainting kernel\n",
+ test->name);

-:351: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
#351: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:60:
+#define selftest(x, __y) int __y(void);

-:357: ERROR:OPEN_BRACE: open brace '{' following function definitions go on 
the next line
#357: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:66:
+   static void mock_##__x(struct kunit *test) {\

-:369: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#369: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:78:
+};
+#undef selftest

-:385: WARNING:MODULE_LICENSE: Prefer "GPL" over "GPL v2" - see commit 
bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
#385: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:94:
+MODULE_LICENSE("GPL v2");

total: 1 errors, 4 warnings, 2 checks, 139 lines checked
d2c5ae3de848 drm/i915: add support to run KUnit tests on bare metal
-:119: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#119: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:106:
+   if (WARN(ret > 0 || ret == -ENOTTY,
+   "%s returned %d, conflicting with selftest's magic 
values!\n",

total: 0 errors, 0 warnings, 1 checks, 109 lines checked
c8c52b04820b drm/i915: add live selftests to KUnit
-:27: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
#27: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:185:
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);

-:32: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#32: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:190:
+#define selftest(__x, __y) ^I^I^I^I\$

-:33: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the 
next line
#33: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:191:
+   static void live_##__x(struct kunit *test) {\

-:45: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#45: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:203:
+};
+#undef selftest

total: 1 errors, 2 warnings, 1 checks, 49 lines checked
8f10df5e6a29 drm/i915: add perf selftests to KUnit
-:22: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon
#22: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:209:
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);

-:28: ERROR:OPEN_BRACE: open brace '{' following function definitions go on the 
next line
#28: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:215:
+   static void perf_##__x(struct kunit *test) {\

-:40: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#40: FILE: drivers/gpu/drm/i915/selftests/i915_kunit.c:227:
+};
+#undef selftest

total: 1 errors, 1 warnings, 1 checks, 49 lines checked
3ad2a4823bf9 drm/i915: now that all functions are used, remove __maybe_unused
36f4738dd786 drm/i915: check if current->mm is not NULL
-:49: WARNING:TYPO_SPELLING: 'an user' may be misspelled - perhaps 'a user'?
#49: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:1849:
+   pr_err("Test called without an user context!\n");
^^^

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsc: Add is_dsc_supported()

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Add is_dsc_supported()
URL   : https://patchwork.freedesktop.org/series/110469/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12333_full -> Patchwork_110469v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@toggle:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-skl4/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-skl1/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html

  
 Warnings 

  * igt@gem_tiled_swapping@non-threaded:
- shard-skl:  [SKIP][3] ([fdo#109271]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-skl4/igt@gem_tiled_swapp...@non-threaded.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-skl1/igt@gem_tiled_swapp...@non-threaded.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][5], [PASS][6], [PASS][7], [FAIL][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]) ([i915#4386]) -> ([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], 
[PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-apl1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-apl1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110469v1/shard-apl1/boot.html
   [34]: 
https://intel-gfx-

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Use kmap_local_page() in gem/i915_gem_object.c

[Fabio M. De Francesco]

On giovedì 3 novembre 2022 17:51:23 CET Ira Weiny wrote:
> On Sat, Oct 29, 2022 at 01:17:03PM +0200, Fabio M. De Francesco wrote:
> > On lunedì 17 ottobre 2022 11:37:17 CEST Zhao Liu wrote:
> > > From: Zhao Liu 
> > > 
> > > The use of kmap_atomic() is being deprecated in favor of
> > > kmap_local_page()[1].
> > > 
> > > The main difference between atomic and local mappings is that local
> > > mappings doesn't disable page faults or preemption.
> > 
> > You are right about about page faults which are never disabled by
> > kmap_local_page(). However kmap_atomic might not disable preemption. It
> > depends on CONFIG_PREEMPT_RT.
> > 
> > Please refer to how kmap_atomic_prot() works (this function is called by
> > kmap_atomic() when kernels have HIGHMEM enabled).
> > 
> > > There're 2 reasons why i915_gem_object_read_from_page_kmap() doesn't
> > > need to disable pagefaults and preemption for mapping:
> > > 
> > > 1. The flush operation is safe for CPU hotplug when preemption is not
> > > disabled.
> > 
> > I'm confused here. Why are you talking about CPU hotplug?
> 
> I agree with Fabio here.  I'm not making the connection between cpu hotplug 
and
> this code path.
> 
> Ira

@Zhao,

I'd like to add that I was about to put my reviewed-by tag. The other things I 
objected are minor nits. Please just clarify this connection.

Your code is good and deserves to be applied.

Fabio

> 
> > In any case, developers should never rely on implicit calls of
> > preempt_disable() for the reasons said above. Therefore, flush operations
> > should be allowed regardless that kmap_atomic() potential side effect.
> > 
> > > In drm/i915/gem/i915_gem_object.c, the function
> > > i915_gem_object_read_from_page_kmap() calls drm_clflush_virt_range()
> > 
> > If I recall correctly, drm_clflush_virt_range() can always be called with 
page
> > faults and preemption enabled. If so, this is enough to say that the
> > conversion is safe.
> > 
> > Is this code explicitly related to flushing the cache lines before 
removing /
> > adding CPUs? If I recall correctly, there are several other reasons behind 
the
> > need to issue cache lines flushes. Am I wrong about this?
> > 
> > Can you please say more about what I'm missing here?
> > 
> > > to
> > > use CLFLUSHOPT or WBINVD to flush. Since CLFLUSHOPT is global on x86
> > > and WBINVD is called on each cpu in drm_clflush_virt_range(), the flush
> > > operation is global and any issue with cpu's being added or removed
> > > can be handled safely.
> > 
> > Again your main concern is about CPU hotplug.
> > 
> > Even if I'm missing something, do we really need all these details about 
the
> > inner workings of drm_clflush_virt_range()?
> > 
> > I'm not an expert, so may be that I'm wrong about all I wrote above.
> > 
> > Therefore, can you please elaborate a little more for readers with very 
little
> > knowledge of these kinds of things (like me and perhaps others)?
> > 
> > > 2. Any context switch caused by preemption or sleep (pagefault may
> > > cause sleep) doesn't affect the validity of local mapping.
> > 
> > I'd replace "preemption or sleep" with "preemption and page faults" since
> > yourself then added that page faults lead to tasks being put to sleep.
> > 
> > > Therefore, i915_gem_object_read_from_page_kmap() is a function where
> > > the use of kmap_local_page() in place of kmap_atomic() is correctly
> > > suited.
> > > 
> > > Convert the calls of kmap_atomic() / kunmap_atomic() to
> > > kmap_local_page() / kunmap_local().
> > > 
> > > And remove the redundant variable that stores the address of the mapped
> > > page since kunmap_local() can accept any pointer within the page.
> > > 
> > > [1]: 
> > > https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com
> > > 
> > > Suggested-by: Dave Hansen 
> > > Suggested-by: Ira Weiny 
> > > Suggested-by: Fabio M. De Francesco 
> > > Signed-off-by: Zhao Liu 
> > > ---
> > > 
> > > Suggested by credits:
> > >   Dave: Referred to his explanation about cache flush.
> > >   Ira: Referred to his task document, review comments and explanation 
about
> > >   
> > >cache flush.
> > >   
> > >   Fabio: Referred to his boiler plate commit message.
> > > 
> > > ---
> > > 
> > >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++-
> > >  1 file changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_object.c index
> > 
> > 369006c5317f..a0072abed75e 100644
> > 
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > @@ -413,17 +413,15 @@ void 
__i915_gem_object_invalidate_frontbuffer(struct
> > > drm_i915_gem_object *obj, static void
> > > 
> > >  i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, 
u64
> > 
> > offset, void
> > 
> > > *dst, int size) {
> > > - void *src_map;
> > > 
> > >   void *src_ptr;
> > > 
> > > - src_map = kmap_atomic(i915_gem_object

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Add is_dsc_supported()

[Navare, Manasi]

On Thu, Nov 03, 2022 at 11:32:22AM +0530, Swati Sharma wrote:
> Lets use RUNTIME_INFO->has_dsc since platforms supporting dsc has this
> flag enabled.
> 
> This is done based on the review comments received on
> https://patchwork.freedesktop.org/patch/509393/
> 
> Signed-off-by: Swati Sharma 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 6 +++---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 7 ++-
>  drivers/gpu/drm/i915/display/intel_vdsc.h | 2 ++
>  3 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7400d6b4c587..eb908da80f2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1012,7 +1012,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>* Output bpp is stored in 6.4 format so right shift by 4 to get the
>* integer value since we support only integer values of bpp.
>*/
> - if (DISPLAY_VER(dev_priv) >= 10 &&
> + if (is_dsc_supported(dev_priv) &&
>   drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
>   /*
>* TBD pass the connector BPC,
> @@ -2906,7 +2906,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   intel_dp_set_max_sink_lane_count(intel_dp);
>  
>   /* Read the eDP DSC DPCD registers */
> - if (DISPLAY_VER(dev_priv) >= 10)
> + if (is_dsc_supported(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
>   /*
> @@ -4691,7 +4691,7 @@ intel_dp_detect(struct drm_connector *connector,
>   }
>  
>   /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> - if (DISPLAY_VER(dev_priv) >= 11)
> + if (is_dsc_supported(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
>   intel_dp_configure_mst(intel_dp);
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 269f9792390d..e7c1169538da 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -338,13 +338,18 @@ static const struct rc_parameters *get_rc_params(u16 
> compressed_bpp,
>   return &rc_parameters[row_index][column_index];
>  }
>  
> +bool is_dsc_supported(struct drm_i915_private *dev_priv)
> +{
> + return RUNTIME_INFO(dev_priv)->has_dsc;
> +}
> +
>  bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
>  {
>   const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>  
> - if (!RUNTIME_INFO(i915)->has_dsc)
> + if (!is_dsc_supported(i915))
>   return false;
>  
>   if (DISPLAY_VER(i915) >= 12)

In Runtime info, Gen 12 should have Gen 11 runtime has dsc set, so makes
this check here redundant.

Manasi

> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.h 
> b/drivers/gpu/drm/i915/display/intel_vdsc.h
> index 8763f00fa7e2..049e8b95fdde 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.h
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.h
> @@ -12,7 +12,9 @@ enum transcoder;
>  struct intel_crtc;
>  struct intel_crtc_state;
>  struct intel_encoder;
> +struct drm_i915_private;
>  
> +bool is_dsc_supported(struct drm_i915_private *dev_priv);
>  bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state);
>  void intel_uncompressed_joiner_enable(const struct intel_crtc_state 
> *crtc_state);
>  void intel_dsc_enable(const struct intel_crtc_state *crtc_state);
> -- 
> 2.25.1
> 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Add sysfs RAPL PL1 interface

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Add sysfs RAPL PL1 interface
URL   : https://patchwork.freedesktop.org/series/110476/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/110476/revisions/1/mbox/ not 
applied
Applying: drm/i915/gt: Add sysfs RAPL PL1 interface
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
M   drivers/gpu/drm/i915/gt/intel_rps.c
M   drivers/gpu/drm/i915/gt/intel_rps.h
M   drivers/gpu/drm/i915/i915_reg.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_reg.h
Auto-merging drivers/gpu/drm/i915/gt/intel_rps.h
Auto-merging drivers/gpu/drm/i915/gt/intel_rps.c
Auto-merging drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/gt: Add sysfs RAPL PL1 interface
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".

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches

[John Harrison]

On 11/3/2022 02:38, Tvrtko Ursulin wrote:

On 03/11/2022 09:18, Tvrtko Ursulin wrote:

On 03/11/2022 01:33, John Harrison wrote:

On 11/2/2022 07:20, Tvrtko Ursulin wrote:

On 02/11/2022 12:12, Jani Nikula wrote:

On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

At the end of each test, IGT does a drop caches call via sysfs with


sysfs?
Sorry, that was meant to say debugfs. I've also been working on some 
sysfs IGT issues and evidently got my wires crossed!





special flags set. One of the possible paths waits for idle with an
infinite timeout. That causes problems for debugging issues when CI
catches a "can't go idle" test failure. Best case, the CI system 
times

out (after 90s), attempts a bunch of state dump actions and then
reboots the system to recover it. Worst case, the CI system can't do
anything at all and then times out (after 1000s) and simply reboots.
Sometimes a serial port log of dmesg might be available, 
sometimes not.


So rather than making life hard for ourselves, change the timeout to
be 10s rather than infinite. Also, trigger the standard
wedge/reset/recover sequence so that testing can continue with a
working system (if possible).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c

index ae987e92251dd..9d916fbbfc27c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -641,6 +641,9 @@ 
DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,

    DROP_RESET_ACTIVE | \
    DROP_RESET_SEQNO | \
    DROP_RCU)
+
+#define DROP_IDLE_TIMEOUT    (HZ * 10)


I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only 
used

here.


So move here, dropping i915 prefix, next to the newly proposed one?

Sure, can do that.




I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in
gt/intel_gt.c.


Move there and rename to GT_IDLE_TIMEOUT?

I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in 
intel_gt_pm.c.


No action needed, maybe drop i915 prefix if wanted.

These two are totally unrelated and in code not being touched by 
this change. I would rather not conflate changing random other 
things with fixing this specific issue.



I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies.


Add _MS suffix if wanted.


My head spins.


I follow and raise that the newly proposed DROP_IDLE_TIMEOUT 
applies to DROP_ACTIVE and not only DROP_IDLE.
My original intention for the name was that is the 'drop caches 
timeout for intel_gt_wait_for_idle'. Which is quite the mouthful and 
hence abbreviated to DROP_IDLE_TIMEOUT. But yes, I realised later 
that name can be conflated with the DROP_IDLE flag. Will rename.





Things get refactored, code moves around, bits get left behind, who 
knows. No reason to get too worked up. :) As long as people are 
taking a wider view when touching the code base, and are not afraid 
to send cleanups, things should be good.
On the other hand, if every patch gets blocked in code review 
because someone points out some completely unrelated piece of code 
could be a bit better then nothing ever gets fixed. If you spot 
something that you think should be improved, isn't the general idea 
that you should post a patch yourself to improve it?


There's two maintainers per branch and an order of magnitude or two 
more developers so it'd be nice if cleanups would just be incoming on 
self-initiative basis. ;)


For the actual functional change at hand - it would be nice if code 
paths in question could handle SIGINT and then we could punt the 
decision on how long someone wants to wait purely to userspace. But 
it's probably hard and it's only debugfs so whatever.


The code paths in question will already abort on a signal won't 
they? Both intel_gt_wait_for_idle() and 
intel_guc_wait_for_pending_msg(), which is where the 
uc_wait_for_idle eventually ends up, have an 'if(signal_pending) 
return -EINTR;' check. Beyond that, it sounds like what you are 
asking for is a change in the IGT libraries and/or CI framework to 
start sending signals after some specific timeout. That seems like a 
significantly more complex change (in terms of the number of 
entities affected and number of groups involved) and unnecessary.


If you say so, I haven't looked at them all. But if the code path in 
question already aborts on signals then I am not sure what is the 
patch fixing? I assumed you are trying to avoid the write stuck in D 
forever, which then prevents driver unload and everything, requiring 
the test runner to eventually reboot. If you say SIGINT works then 
you can already recover from userspace, no?


Whether or not 10s is enough CI will hopefully tell us. I'd 
probably err on the side of safety and make it longer, but at most 
half from the test runner timeout.
This is supposed to be test clean up. This i

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c

[Ira Weiny]

On Mon, Oct 17, 2022 at 05:37:23PM +0800, Zhao Liu wrote:
> From: Zhao Liu 
> 
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
> 
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
> 
> In drm/i915/gt/uc/intel_us_fw.c, the function intel_uc_fw_copy_rsa()
> just use the mapping to do memory copy so it doesn't need to disable
> pagefaults and preemption for mapping. Thus the local mapping without
> atomic context (not disable pagefaults / preemption) is enough.
> 
> Therefore, intel_uc_fw_copy_rsa() is a function where the use of
> memcpy_from_page() with kmap_local_page() in place of memcpy() with
> kmap_atomic() is correctly suited.
> 
> Convert the calls of memcpy() with kmap_atomic() / kunmap_atomic() to
> memcpy_from_page() which uses local mapping to copy.
> 
> [1]: 
> https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com/T/#u
> 
> Suggested-by: Ira Weiny 

Reviewed-by: Ira Weiny 

> Suggested-by: Fabio M. De Francesco 
> Signed-off-by: Zhao Liu 
> ---
> Suggested by credits:
>   Ira: Referred to his task document and suggestions about using
>memcpy_from_page() directly.
>   Fabio: Referred to his boiler plate commit message.
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index b91ad4aede1f..64d56f175d32 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -962,16 +962,13 @@ size_t intel_uc_fw_copy_rsa(struct intel_uc_fw *uc_fw, 
> void *dst, u32 max_len)
>  
>   for_each_sgt_page(page, iter, uc_fw->obj->mm.pages) {
>   u32 len = min_t(u32, size, PAGE_SIZE - offset);
> - void *vaddr;
>  
>   if (idx > 0) {
>   idx--;
>   continue;
>   }
>  
> - vaddr = kmap_atomic(page);
> - memcpy(dst, vaddr + offset, len);
> - kunmap_atomic(vaddr);
> + memcpy_from_page(dst, page, offset, len);
>  
>   offset = 0;
>   dst += len;
> -- 
> 2.34.1
> 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove excessive line feeds in state dumps

[Umesh Nerlige Ramappa]

On Mon, Oct 31, 2022 at 03:00:07PM -0700, john.c.harri...@intel.com wrote:

From: John Harrison 

Some of the GuC state dump messages were adding extra line feeds. When
printing via a DRM printer to dmesg, for example, that messes up the
log formatting as it loses any prefixing from the printer. Given that
the extra line feeds are just in the middle of random bits of GuC
state, there isn't any real need for them. So just remove them
completely.

Signed-off-by: John Harrison 


lgtm,

Reviewed-by: Umesh Nerlige Ramappa 


---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 27b09ba1d295f..1bcd61bb50f89 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -871,14 +871,14 @@ void intel_guc_load_status(struct intel_guc *guc, struct 
drm_printer *p)
u32 status = intel_uncore_read(uncore, GUC_STATUS);
u32 i;

-   drm_printf(p, "\nGuC status 0x%08x:\n", status);
+   drm_printf(p, "GuC status 0x%08x:\n", status);
drm_printf(p, "\tBootrom status = 0x%x\n",
   (status & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
drm_printf(p, "\tuKernel status = 0x%x\n",
   (status & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
drm_printf(p, "\tMIA Core status = 0x%x\n",
   (status & GS_MIA_MASK) >> GS_MIA_SHIFT);
-   drm_puts(p, "\nScratch registers:\n");
+   drm_puts(p, "Scratch registers:\n");
for (i = 0; i < 16; i++) {
drm_printf(p, "\t%2d: \t0x%x\n",
   i, intel_uncore_read(uncore, 
SOFT_SCRATCH(i)));
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 4ccb29f9ac55c..4dbdac8002e32 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4901,7 +4901,7 @@ void intel_guc_submission_print_info(struct intel_guc 
*guc,

drm_printf(p, "GuC Number Outstanding Submission G2H: %u\n",
   atomic_read(&guc->outstanding_submission_g2h));
-   drm_printf(p, "GuC tasklet count: %u\n\n",
+   drm_printf(p, "GuC tasklet count: %u\n",
   atomic_read(&sched_engine->tasklet.count));

spin_lock_irqsave(&sched_engine->lock, flags);
@@ -4949,7 +4949,7 @@ static inline void guc_log_context(struct drm_printer *p,
   atomic_read(&ce->pin_count));
drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
   atomic_read(&ce->guc_id.ref));
-   drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
+   drm_printf(p, "\t\tSchedule State: 0x%x\n",
   ce->guc_state.sched_state);
}

@@ -4978,7 +4978,7 @@ void intel_guc_submission_print_context_info(struct 
intel_guc *guc,
   
READ_ONCE(*ce->parallel.guc.wq_head));
drm_printf(p, "\t\tWQI Tail: %u\n",
   
READ_ONCE(*ce->parallel.guc.wq_tail));
-   drm_printf(p, "\t\tWQI Status: %u\n\n",
+   drm_printf(p, "\t\tWQI Status: %u\n",
   
READ_ONCE(*ce->parallel.guc.wq_status));
}

@@ -4986,7 +4986,7 @@ void intel_guc_submission_print_context_info(struct 
intel_guc *guc,
emit_bb_start_parent_no_preempt_mid_batch) {
u8 i;

-   drm_printf(p, "\t\tChildren Go: %u\n\n",
+   drm_printf(p, "\t\tChildren Go: %u\n",
   get_children_go_value(ce));
for (i = 0; i < ce->parallel.number_children; 
++i)
drm_printf(p, "\t\tChildren Join: %u\n",
--
2.37.3

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[Umesh Nerlige Ramappa]

On Thu, Nov 03, 2022 at 11:45:57AM -0700, John Harrison wrote:

On 11/3/2022 04:31, Tvrtko Ursulin wrote:

On 02/11/2022 19:21, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

The function being used to lock the reset-in-progress mutex is called
intel_gt_reset_trylock(). However, as noted it does not follow
standard 'trylock' conventions and exit if already locked. So rename
the current _trylock function to intel_gt_reset_lock_interruptible(),
which is the behaviour it actually provides. In addition, add a new
implementation of _trylock and call that from the busyness stats
worker instead.

v2: Rename existing trylock to interruptible rather than trying to
preserve the existing (confusing) naming scheme (review comments from
Tvrtko).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_reset.c  | 18 --
  drivers/gpu/drm/i915/gt/intel_reset.h  |  1 +
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c  |  4 +++-
  4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c

index e63329bc80659..c29efdef8313a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -330,7 +330,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
  if (ret)
  goto err_rpm;
  -    ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+    ret = intel_gt_reset_lock_interruptible(ggtt->vm.gt, &srcu);
  if (ret)
  goto err_pages;
  diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c

index 3159df6cdd492..24736ebee17c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,15 +1407,19 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
  -int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_lock(struct intel_gt *gt, int *srcu, 
bool retry)

  {
  might_lock(>->reset.backoff_srcu);
-    might_sleep();
+    if (retry)
+    might_sleep();
    rcu_read_lock();
  while (test_bit(I915_RESET_BACKOFF, >->reset.flags)) {
  rcu_read_unlock();
  +    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
 >->reset.flags)))
@@ -1429,6 +1433,16 @@ int intel_gt_reset_trylock(struct intel_gt 
*gt, int *srcu)

  return 0;
  }
  +int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+{
+    return _intel_gt_reset_lock(gt, srcu, false);
+}
+
+int intel_gt_reset_lock_interruptible(struct intel_gt *gt, int *srcu)
+{
+    return _intel_gt_reset_lock(gt, srcu, true);
+}
+
  void intel_gt_reset_unlock(struct intel_gt *gt, int tag)
  __releases(>->reset.backoff_srcu)
  {
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h 
b/drivers/gpu/drm/i915/gt/intel_reset.h

index adc734e673870..25c975b6e8fc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -39,6 +39,7 @@ int __intel_engine_reset_bh(struct 
intel_engine_cs *engine,

  void __i915_request_reset(struct i915_request *rq, bool guilty);
    int __must_check intel_gt_reset_trylock(struct intel_gt *gt, 
int *srcu);
+int __must_check intel_gt_reset_lock_interruptible(struct 
intel_gt *gt, int *srcu);

  void intel_gt_reset_unlock(struct intel_gt *gt, int tag);
    void intel_gt_set_wedged(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index 941613be3b9dd..92e514061d20b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1401,7 +1401,9 @@ static void guc_timestamp_ping(struct 
work_struct *wrk)

    /*
   * Synchronize with gt reset to make sure the worker does not
- * corrupt the engine/guc stats.
+ * corrupt the engine/guc stats. NB: can't actually block waiting
+ * for a reset to complete as the reset requires flushing out
+ * this worker thread if started. So waiting would deadlock.
   */
  ret = intel_gt_reset_trylock(gt, &srcu);
  if (ret)


LGTM but I don't remember fully how ping worker and reset interact 
so I'll let Umesh r-b. Like is it okay to skip the ping or we'd need 
to re-schedule it ASAP due wrap issues? Maybe reset makes

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[John Harrison]

On 11/3/2022 04:31, Tvrtko Ursulin wrote:

On 02/11/2022 19:21, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

The function being used to lock the reset-in-progress mutex is called
intel_gt_reset_trylock(). However, as noted it does not follow
standard 'trylock' conventions and exit if already locked. So rename
the current _trylock function to intel_gt_reset_lock_interruptible(),
which is the behaviour it actually provides. In addition, add a new
implementation of _trylock and call that from the busyness stats
worker instead.

v2: Rename existing trylock to interruptible rather than trying to
preserve the existing (confusing) naming scheme (review comments from
Tvrtko).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_reset.c  | 18 --
  drivers/gpu/drm/i915/gt/intel_reset.h  |  1 +
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c  |  4 +++-
  4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c

index e63329bc80659..c29efdef8313a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -330,7 +330,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
  if (ret)
  goto err_rpm;
  -    ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);
+    ret = intel_gt_reset_lock_interruptible(ggtt->vm.gt, &srcu);
  if (ret)
  goto err_pages;
  diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c

index 3159df6cdd492..24736ebee17c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,15 +1407,19 @@ void intel_gt_handle_error(struct intel_gt *gt,
  intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
  -int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+static int _intel_gt_reset_lock(struct intel_gt *gt, int *srcu, bool 
retry)

  {
  might_lock(>->reset.backoff_srcu);
-    might_sleep();
+    if (retry)
+    might_sleep();
    rcu_read_lock();
  while (test_bit(I915_RESET_BACKOFF, >->reset.flags)) {
  rcu_read_unlock();
  +    if (!retry)
+    return -EBUSY;
+
  if (wait_event_interruptible(gt->reset.queue,
   !test_bit(I915_RESET_BACKOFF,
 >->reset.flags)))
@@ -1429,6 +1433,16 @@ int intel_gt_reset_trylock(struct intel_gt 
*gt, int *srcu)

  return 0;
  }
  +int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)
+{
+    return _intel_gt_reset_lock(gt, srcu, false);
+}
+
+int intel_gt_reset_lock_interruptible(struct intel_gt *gt, int *srcu)
+{
+    return _intel_gt_reset_lock(gt, srcu, true);
+}
+
  void intel_gt_reset_unlock(struct intel_gt *gt, int tag)
  __releases(>->reset.backoff_srcu)
  {
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h 
b/drivers/gpu/drm/i915/gt/intel_reset.h

index adc734e673870..25c975b6e8fc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -39,6 +39,7 @@ int __intel_engine_reset_bh(struct intel_engine_cs 
*engine,

  void __i915_request_reset(struct i915_request *rq, bool guilty);
    int __must_check intel_gt_reset_trylock(struct intel_gt *gt, int 
*srcu);
+int __must_check intel_gt_reset_lock_interruptible(struct intel_gt 
*gt, int *srcu);

  void intel_gt_reset_unlock(struct intel_gt *gt, int tag);
    void intel_gt_set_wedged(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index 941613be3b9dd..92e514061d20b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1401,7 +1401,9 @@ static void guc_timestamp_ping(struct 
work_struct *wrk)

    /*
   * Synchronize with gt reset to make sure the worker does not
- * corrupt the engine/guc stats.
+ * corrupt the engine/guc stats. NB: can't actually block waiting
+ * for a reset to complete as the reset requires flushing out
+ * this worker thread if started. So waiting would deadlock.
   */
  ret = intel_gt_reset_trylock(gt, &srcu);
  if (ret)


LGTM but I don't remember fully how ping worker and reset interact so 
I'll let Umesh r-b. Like is it okay to skip the ping or we'd need to 
re-schedule it ASAP due wrap issues? Maybe reset makes that pointless, 
I don't remember.
The reset is cancelling the 

[Intel-gfx] [PATCH v2] drm/i915/mtl: Add Wa_14017073508 for SAMedia

[Badal Nilawar]

This workaround is added for Media tile of MTL A step. It is to help
pcode workaround which handles the hardware issue seen during package C2/C3
transitions due to RC6 entry/exit transitions on Media tile. As a part of
workaround pcode expect kmd to send mailbox message "media busy" when
components of Media tile are in use and "media idle" otherwise.
As per workaround description gucrc need to be disabled so enabled
host based RC for Media tile.

v2:
 - Correct workaround id (Matt)
 - Fix review comments (Rodrigo)

Cc: Rodrigo Vivi 
Cc: Radhakrishna Sripada 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 ++-
 drivers/gpu/drm/i915/i915_drv.h   |  4 
 drivers/gpu/drm/i915/i915_reg.h   |  9 
 4 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index f553e2173bda..833b7682643f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -19,10 +19,31 @@
 #include "intel_rc6.h"
 #include "intel_rps.h"
 #include "intel_wakeref.h"
+#include "intel_pcode.h"
 #include "pxp/intel_pxp_pm.h"
 
 #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)
 
+static void mtl_media_busy(struct intel_gt *gt)
+{
+   /* Wa_14017073508: mtl */
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA)
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
+static void mtl_media_idle(struct intel_gt *gt)
+{
+   /* Wa_14017073508: mtl */
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA)
+   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
+ PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
+ PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+}
+
 static void user_forcewake(struct intel_gt *gt, bool suspend)
 {
int count = atomic_read(>->user_wakeref);
@@ -70,6 +91,9 @@ static int __gt_unpark(struct intel_wakeref *wf)
 
GT_TRACE(gt, "\n");
 
+   /* Wa_14017073508: mtl */
+   mtl_media_busy(gt);
+
/*
 * It seems that the DMC likes to transition between the DC states a lot
 * when there are no connected displays (no active power domains) during
@@ -119,6 +143,9 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_BUG_ON(!wakeref);
intel_display_power_put_async(i915, POWER_DOMAIN_GT_IRQ, wakeref);
 
+   /* Wa_14017073508: mtl */
+   mtl_media_idle(gt);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
index 8f8dd05835c5..b5855091cf6a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -11,9 +11,20 @@
 
 static bool __guc_rc_supported(struct intel_guc *guc)
 {
+   struct intel_gt *gt = guc_to_gt(guc);
+
+   /*
+* Wa_14017073508: mtl
+* Do not enable gucrc to avoid additional interrupts which
+* may disrupt pcode wa.
+*/
+   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   gt->type == GT_MEDIA)
+   return false;
+
/* GuC RC is unavailable for pre-Gen12 */
return guc->submission_supported &&
-   GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+   GRAPHICS_VER(gt->i915) >= 12;
 }
 
 static bool __guc_rc_selected(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 05b3300cc4ed..659b92382ff2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -740,6 +740,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \
(IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until))
 
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
+   (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
&& \
+IS_GRAPHICS_STEP(__i915, since, until))
+
 /*
  * DG2 hardware steppings are a bit unusual.  The hardware design was forked to
  * create three variants (G10, G11, and G12) which each have distinct
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 765a10e0de88..23d732413919 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6679,6 +6679,15 @@
 /*   XEHP_PCODE_FREQUENCY_CONFIG param2 */
 #define PCODE_MBOX_DOMAIN_NONE 0x0
 #define PCODE_MBOX_DOMAIN_MEDIAFF  0x3
+
+/* Wa_14017210380: mtl */
+#define   PCODE_MBOX_GT_STATE  0x50
+/* sub-commands (para

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Bump up sample period for busy stats selftest

[Umesh Nerlige Ramappa]

On Thu, Nov 03, 2022 at 10:01:11AM -0700, Dixit, Ashutosh wrote:

On Wed, 02 Nov 2022 17:11:49 -0700, Umesh Nerlige Ramappa wrote:


Engine busyness samples around a 10ms period is failing with busyness
ranging approx. from 87% to 115%. The expected range is +/- 5% of the
sample period.

When determining busyness of active engine, the GuC based engine
busyness implementation relies on a 64 bit timestamp register read. The
latency incurred by this register read causes the failure.

On DG1, when the test fails, the observed latencies range from 900us -
1.5ms.

One solution tried was to reduce the latency between reg read and
CPU timestamp capture, but such optimization does not add value to user
since the CPU timestamp obtained here is only used for (1) selftest and
(2) i915 rps implementation specific to execlist scheduler. Also, this
solution only reduces the frequency of failure and does not eliminate
it.

In order to make the selftest more robust and account for such
latencies, increase the sample period to 100 ms.


Does it make sense, and also by way of documenting, to use 10 ms for
execlists and 100 ms for GuC? Maybe a comment in the code would be nice
too. Thanks.


I was hoping to keep the same logic for execlist/guc backends. I can add 
it to the comments though.


sadly, this is the 2nd time we are bumping this up. This was originally 
100us for execlists. With the GuC backend, there is a latency by design 
since active busyness is calculated using GT timestamp register. 
Execlists relied solely on ktime_get() to check for active busyness and 
that seemed to have negligible latency. I see no robust option here.


Thanks,
Umesh





Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 0dcb3ed44a73..87c94314cf67 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -317,7 +317,7 @@ static int live_engine_busy_stats(void *arg)
ENGINE_TRACE(engine, "measuring busy time\n");
preempt_disable();
de = intel_engine_get_busy_time(engine, &t[0]);
-   mdelay(10);
+   mdelay(100);
de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
preempt_enable();
dt = ktime_sub(t[1], t[0]);
--
2.36.1

Re: [Intel-gfx] [PATCH] i915/pmu: Use a faster read for 2x32 mmio reads

[Umesh Nerlige Ramappa]

On Thu, Nov 03, 2022 at 11:07:05AM -0700, Umesh Nerlige Ramappa wrote:

PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower
32 bit registers are read in a loop, there is a latency involved in
getting the GT timestamp. To reduce the latency, define another version
of the helper that requires caller to acquire uncore->spinlock and
necessary forcewakes.

Signed-off-by: Umesh Nerlige Ramappa 


Not for review, just to demonstrate one of the solutions to a DG1 BAT 
issue


Thanks,
Umesh

---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 26 ---
drivers/gpu/drm/i915/intel_uncore.h   | 24 +
2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 693b07a97789..64b0193c9ee4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1252,6 +1252,28 @@ static u32 gpm_timestamp_shift(struct intel_gt *gt)
return 3 - shift;
}

+static u64 gpm_timestamp(struct intel_uncore *uncore, ktime_t *now)
+{
+   enum forcewake_domains fw_domains;
+   u64 reg;
+
+   /* Assume MISC_STATUS0 and MISC_STATUS1 are in the same fw_domain */
+   fw_domains = intel_uncore_forcewake_for_reg(uncore,
+   MISC_STATUS0,
+   FW_REG_READ);
+
+   spin_lock_irq(&uncore->lock);
+   intel_uncore_forcewake_get__locked(uncore, fw_domains);
+
+   reg = intel_uncore_read64_2x32_fw(uncore, MISC_STATUS0, MISC_STATUS1);
+   *now = ktime_get();
+
+   intel_uncore_forcewake_put__locked(uncore, fw_domains);
+   spin_unlock_irq(&uncore->lock);
+
+   return reg;
+}
+
static void guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
{
struct intel_gt *gt = guc_to_gt(guc);
@@ -1261,10 +1283,8 @@ static void guc_update_pm_timestamp(struct intel_guc 
*guc, ktime_t *now)
lockdep_assert_held(&guc->timestamp.lock);

gt_stamp_hi = upper_32_bits(guc->timestamp.gt_stamp);
-   gpm_ts = intel_uncore_read64_2x32(gt->uncore, MISC_STATUS0,
- MISC_STATUS1) >> guc->timestamp.shift;
+   gpm_ts = gpm_timestamp(gt->uncore, now) >> guc->timestamp.shift;
gt_stamp_lo = lower_32_bits(gpm_ts);
-   *now = ktime_get();

if (gt_stamp_lo < lower_32_bits(guc->timestamp.gt_stamp))
gt_stamp_hi++;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 5449146a0624..dd0cf7d4ce6c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -455,6 +455,30 @@ static inline void intel_uncore_rmw_fw(struct intel_uncore 
*uncore,
intel_uncore_write_fw(uncore, reg, val);
}

+/*
+ * Introduce a _fw version of intel_uncore_read64_2x32 so that the 64 bit
+ * register read is as quick as possible.
+ *
+ * NOTE:
+ * Prior to calling this function, the caller must
+ * 1. obtain the uncore->lock
+ * 2. acquire forcewakes for the upper and lower register
+ */
+static inline u64
+intel_uncore_read64_2x32_fw(struct intel_uncore *uncore,
+   i915_reg_t lower_reg, i915_reg_t upper_reg)
+{
+   u32 upper, lower, old_upper, loop = 0;
+
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   do {
+   old_upper = upper;
+   lower = intel_uncore_read_fw(uncore, lower_reg);
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   } while (upper != old_upper && loop++ < 2);
+   return (u64)upper << 32 | lower;
+}
+
static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
i915_reg_t reg, u32 val,
u32 mask, u32 expected_val)
--
2.36.1

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Bump up sample period for busy stats selftest

[Umesh Nerlige Ramappa]

On Thu, Nov 03, 2022 at 12:28:46PM +, Tvrtko Ursulin wrote:


On 03/11/2022 00:11, Umesh Nerlige Ramappa wrote:

Engine busyness samples around a 10ms period is failing with busyness
ranging approx. from 87% to 115%. The expected range is +/- 5% of the
sample period.

When determining busyness of active engine, the GuC based engine
busyness implementation relies on a 64 bit timestamp register read. The
latency incurred by this register read causes the failure.

On DG1, when the test fails, the observed latencies range from 900us -
1.5ms.


Do I read this right - that the latency of a 64 bit timestamp register 
read is 0.9 - 1.5ms? That would be the read in 
guc_update_pm_timestamp?


Correct. That is total time taken by intel_uncore_read64_2x32() measured 
with local_clock().


One other thing I missed out in the comments is that enable_dc=0 also 
resolves the issue, but display team confirmed there is no relation to 
display in this case other than that it somehow introduces a latency in 
the reg read.




Regards,

Tvrtko


One solution tried was to reduce the latency between reg read and
CPU timestamp capture, but such optimization does not add value to user
since the CPU timestamp obtained here is only used for (1) selftest and
(2) i915 rps implementation specific to execlist scheduler. Also, this
solution only reduces the frequency of failure and does not eliminate
it.


Note that this solution is here - 
https://patchwork.freedesktop.org/patch/509991/?series=110497&rev=1


but I am not intending to use it since it just reduces the frequency of 
failues, but the inherent issue still exists.


Regards,
Umesh



In order to make the selftest more robust and account for such
latencies, increase the sample period to 100 ms.

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 0dcb3ed44a73..87c94314cf67 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -317,7 +317,7 @@ static int live_engine_busy_stats(void *arg)
ENGINE_TRACE(engine, "measuring busy time\n");
preempt_disable();
de = intel_engine_get_busy_time(engine, &t[0]);
-   mdelay(10);
+   mdelay(100);
de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
preempt_enable();
dt = ktime_sub(t[1], t[0]);

[Intel-gfx] [PATCH] i915/pmu: Use a faster read for 2x32 mmio reads

[Umesh Nerlige Ramappa]

PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower
32 bit registers are read in a loop, there is a latency involved in
getting the GT timestamp. To reduce the latency, define another version
of the helper that requires caller to acquire uncore->spinlock and
necessary forcewakes.

Signed-off-by: Umesh Nerlige Ramappa 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 26 ---
 drivers/gpu/drm/i915/intel_uncore.h   | 24 +
 2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 693b07a97789..64b0193c9ee4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1252,6 +1252,28 @@ static u32 gpm_timestamp_shift(struct intel_gt *gt)
return 3 - shift;
 }
 
+static u64 gpm_timestamp(struct intel_uncore *uncore, ktime_t *now)
+{
+   enum forcewake_domains fw_domains;
+   u64 reg;
+
+   /* Assume MISC_STATUS0 and MISC_STATUS1 are in the same fw_domain */
+   fw_domains = intel_uncore_forcewake_for_reg(uncore,
+   MISC_STATUS0,
+   FW_REG_READ);
+
+   spin_lock_irq(&uncore->lock);
+   intel_uncore_forcewake_get__locked(uncore, fw_domains);
+
+   reg = intel_uncore_read64_2x32_fw(uncore, MISC_STATUS0, MISC_STATUS1);
+   *now = ktime_get();
+
+   intel_uncore_forcewake_put__locked(uncore, fw_domains);
+   spin_unlock_irq(&uncore->lock);
+
+   return reg;
+}
+
 static void guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
 {
struct intel_gt *gt = guc_to_gt(guc);
@@ -1261,10 +1283,8 @@ static void guc_update_pm_timestamp(struct intel_guc 
*guc, ktime_t *now)
lockdep_assert_held(&guc->timestamp.lock);
 
gt_stamp_hi = upper_32_bits(guc->timestamp.gt_stamp);
-   gpm_ts = intel_uncore_read64_2x32(gt->uncore, MISC_STATUS0,
- MISC_STATUS1) >> guc->timestamp.shift;
+   gpm_ts = gpm_timestamp(gt->uncore, now) >> guc->timestamp.shift;
gt_stamp_lo = lower_32_bits(gpm_ts);
-   *now = ktime_get();
 
if (gt_stamp_lo < lower_32_bits(guc->timestamp.gt_stamp))
gt_stamp_hi++;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 5449146a0624..dd0cf7d4ce6c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -455,6 +455,30 @@ static inline void intel_uncore_rmw_fw(struct intel_uncore 
*uncore,
intel_uncore_write_fw(uncore, reg, val);
 }
 
+/*
+ * Introduce a _fw version of intel_uncore_read64_2x32 so that the 64 bit
+ * register read is as quick as possible.
+ *
+ * NOTE:
+ * Prior to calling this function, the caller must
+ * 1. obtain the uncore->lock
+ * 2. acquire forcewakes for the upper and lower register
+ */
+static inline u64
+intel_uncore_read64_2x32_fw(struct intel_uncore *uncore,
+   i915_reg_t lower_reg, i915_reg_t upper_reg)
+{
+   u32 upper, lower, old_upper, loop = 0;
+
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   do {
+   old_upper = upper;
+   lower = intel_uncore_read_fw(uncore, lower_reg);
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   } while (upper != old_upper && loop++ < 2);
+   return (u64)upper << 32 | lower;
+}
+
 static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
i915_reg_t reg, u32 val,
u32 mask, u32 expected_val)
-- 
2.36.1

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Bump up sample period for busy stats selftest

[Dixit, Ashutosh]

On Wed, 02 Nov 2022 17:11:49 -0700, Umesh Nerlige Ramappa wrote:
>
> Engine busyness samples around a 10ms period is failing with busyness
> ranging approx. from 87% to 115%. The expected range is +/- 5% of the
> sample period.
>
> When determining busyness of active engine, the GuC based engine
> busyness implementation relies on a 64 bit timestamp register read. The
> latency incurred by this register read causes the failure.
>
> On DG1, when the test fails, the observed latencies range from 900us -
> 1.5ms.
>
> One solution tried was to reduce the latency between reg read and
> CPU timestamp capture, but such optimization does not add value to user
> since the CPU timestamp obtained here is only used for (1) selftest and
> (2) i915 rps implementation specific to execlist scheduler. Also, this
> solution only reduces the frequency of failure and does not eliminate
> it.
>
> In order to make the selftest more robust and account for such
> latencies, increase the sample period to 100 ms.

Does it make sense, and also by way of documenting, to use 10 ms for
execlists and 100 ms for GuC? Maybe a comment in the code would be nice
too. Thanks.

>
> Signed-off-by: Umesh Nerlige Ramappa 
> ---
>  drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c 
> b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> index 0dcb3ed44a73..87c94314cf67 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> @@ -317,7 +317,7 @@ static int live_engine_busy_stats(void *arg)
>   ENGINE_TRACE(engine, "measuring busy time\n");
>   preempt_disable();
>   de = intel_engine_get_busy_time(engine, &t[0]);
> - mdelay(10);
> + mdelay(100);
>   de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
>   preempt_enable();
>   dt = ktime_sub(t[1], t[0]);
> --
> 2.36.1
>

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Use kmap_local_page() in gem/i915_gem_object.c

[Ira Weiny]

On Sat, Oct 29, 2022 at 01:17:03PM +0200, Fabio M. De Francesco wrote:
> On lunedì 17 ottobre 2022 11:37:17 CEST Zhao Liu wrote:
> > From: Zhao Liu 
> > 
> > The use of kmap_atomic() is being deprecated in favor of
> > kmap_local_page()[1].
> > 
> > The main difference between atomic and local mappings is that local
> > mappings doesn't disable page faults or preemption.
> 
> You are right about about page faults which are never disabled by 
> kmap_local_page(). However kmap_atomic might not disable preemption. It 
> depends on CONFIG_PREEMPT_RT.
> 
> Please refer to how kmap_atomic_prot() works (this function is called by 
> kmap_atomic() when kernels have HIGHMEM enabled).
> 
> > 
> > There're 2 reasons why i915_gem_object_read_from_page_kmap() doesn't
> > need to disable pagefaults and preemption for mapping:
> > 
> > 1. The flush operation is safe for CPU hotplug when preemption is not
> > disabled. 
> 
> I'm confused here. Why are you talking about CPU hotplug?

I agree with Fabio here.  I'm not making the connection between cpu hotplug and
this code path.

Ira

> In any case, developers should never rely on implicit calls of 
> preempt_disable() for the reasons said above. Therefore, flush operations 
> should be allowed regardless that kmap_atomic() potential side effect.
> 
> > In drm/i915/gem/i915_gem_object.c, the function
> > i915_gem_object_read_from_page_kmap() calls drm_clflush_virt_range()
> 
> If I recall correctly, drm_clflush_virt_range() can always be called with 
> page 
> faults and preemption enabled. If so, this is enough to say that the 
> conversion is safe. 
> 
> Is this code explicitly related to flushing the cache lines before removing / 
> adding CPUs? If I recall correctly, there are several other reasons behind 
> the 
> need to issue cache lines flushes. Am I wrong about this?
> 
> Can you please say more about what I'm missing here?
> 
> > to
> > use CLFLUSHOPT or WBINVD to flush. Since CLFLUSHOPT is global on x86
> > and WBINVD is called on each cpu in drm_clflush_virt_range(), the flush
> > operation is global and any issue with cpu's being added or removed
> > can be handled safely.
> 
> Again your main concern is about CPU hotplug.
> 
> Even if I'm missing something, do we really need all these details about the 
> inner workings of drm_clflush_virt_range()? 
> 
> I'm not an expert, so may be that I'm wrong about all I wrote above.
> 
> Therefore, can you please elaborate a little more for readers with very 
> little 
> knowledge of these kinds of things (like me and perhaps others)?
>  
> > 2. Any context switch caused by preemption or sleep (pagefault may
> > cause sleep) doesn't affect the validity of local mapping.
> 
> I'd replace "preemption or sleep" with "preemption and page faults" since 
> yourself then added that page faults lead to tasks being put to sleep.  
> 
> > Therefore, i915_gem_object_read_from_page_kmap() is a function where
> > the use of kmap_local_page() in place of kmap_atomic() is correctly
> > suited.
> > 
> > Convert the calls of kmap_atomic() / kunmap_atomic() to
> > kmap_local_page() / kunmap_local().
> > 
> > And remove the redundant variable that stores the address of the mapped
> > page since kunmap_local() can accept any pointer within the page.
> > 
> > [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com
> > 
> > Suggested-by: Dave Hansen 
> > Suggested-by: Ira Weiny 
> > Suggested-by: Fabio M. De Francesco 
> > Signed-off-by: Zhao Liu 
> > ---
> > Suggested by credits:
> >   Dave: Referred to his explanation about cache flush.
> >   Ira: Referred to his task document, review comments and explanation about
> >cache flush.
> >   Fabio: Referred to his boiler plate commit message.
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 
> 369006c5317f..a0072abed75e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -413,17 +413,15 @@ void __i915_gem_object_invalidate_frontbuffer(struct
> > drm_i915_gem_object *obj, static void
> >  i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64 
> offset, void
> > *dst, int size) {
> > -   void *src_map;
> > void *src_ptr;
> > 
> > -   src_map = kmap_atomic(i915_gem_object_get_page(obj, offset >> 
> PAGE_SHIFT));
> > -
> > -   src_ptr = src_map + offset_in_page(offset);
> > +   src_ptr = kmap_local_page(i915_gem_object_get_page(obj, offset >> 
> PAGE_SHIFT))
> > + + offset_in_page(offset);
> > if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
> > drm_clflush_virt_range(src_ptr, size);
> > memcpy(dst, src_ptr, size);
> > 
> > -   kunmap_atomic(src_map);
> > +   kunmap_local(src_ptr);
> >  }
> > 
> >  static void
> 
> The changes look good, but I'd li

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c

[Ira Weiny]

On Mon, Oct 17, 2022 at 05:37:19PM +0800, Zhao Liu wrote:
> From: Zhao Liu 
> 
> The use of kmap_atomic() is being deprecated in favor of
> kmap_local_page()[1].
> 
> The main difference between atomic and local mappings is that local
> mappings doesn't disable page faults or preemption.
> 
> In drm/i915/gem/i915_gem_shmem.c, the function shmem_pwrite() need to
> disable pagefault to eliminate the potential recursion fault[2]. But
> here __copy_from_user_inatomic() doesn't need to disable preemption and
> local mapping is valid for sched in/out.
> 
> So it can use kmap_local_page() / kunmap_local() with
> pagefault_disable() / pagefault_enable() to replace atomic mapping.
> 
> [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com
> [2]: https://patchwork.freedesktop.org/patch/295840/
> 
> Suggested-by: Ira Weiny 

Reviewed-by: Ira Weiny 

> Signed-off-by: Zhao Liu 
> ---
> Suggested by credits:
>   Ira: Referred to his suggestions about keeping pagefault_disable().
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index f42ca1179f37..e279a3e30c02 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -472,11 +472,13 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
>   if (err < 0)
>   return err;
>  
> - vaddr = kmap_atomic(page);
> + vaddr = kmap_local_page(page);
> + pagefault_disable();
>   unwritten = __copy_from_user_inatomic(vaddr + pg,
> user_data,
> len);
> - kunmap_atomic(vaddr);
> + pagefault_enable();
> + kunmap_local(vaddr);
>  
>   err = aops->write_end(obj->base.filp, mapping, offset, len,
> len - unwritten, page, data);
> -- 
> 2.34.1
> 

[Intel-gfx] [PATCH] mei: add timeout to send

[Alexander Usyskin]

When driver wakes up the firmware from the low power stand,
it is sending a memory ready message.
The send is done via synchronous/blocking function to ensure
that firmware is in ready state. However firmware might be
in unstable state and send might be block forever.
To address this issue a timeout is added to blocking write command on
the internal bus.

Signed-off-by: Alexander Usyskin 
---
 drivers/misc/mei/bus-fixup.c | 19 +++
 drivers/misc/mei/bus.c   |  9 +
 drivers/misc/mei/client.c| 21 +
 drivers/misc/mei/client.h|  2 +-
 drivers/misc/mei/main.c  |  2 +-
 drivers/misc/mei/mei_dev.h   |  2 +-
 6 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 71fbf0bc8453..3174cad8a5cc 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -128,7 +128,7 @@ static int mei_osver(struct mei_cl_device *cldev)
os_ver = (struct mei_os_ver *)fwcaps->data;
os_ver->os_type = OSTYPE_LINUX;
 
-   return __mei_cl_send(cldev->cl, buf, size, 0, mode);
+   return __mei_cl_send(cldev->cl, buf, size, 0, mode, 0);
 }
 
 #define MKHI_FWVER_BUF_LEN (sizeof(struct mkhi_msg_hdr) + \
@@ -149,7 +149,7 @@ static int mei_fwver(struct mei_cl_device *cldev)
req.hdr.command = MKHI_GEN_GET_FW_VERSION_CMD;
 
ret = __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0,
-   MEI_CL_IO_TX_BLOCKING);
+   MEI_CL_IO_TX_BLOCKING, 0);
if (ret < 0) {
dev_err(&cldev->dev, "Could not send ReqFWVersion cmd\n");
return ret;
@@ -188,17 +188,19 @@ static int mei_fwver(struct mei_cl_device *cldev)
return ret;
 }
 
+#define GFX_MEMORY_READY_TIMEOUT 200
+
 static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
 {
struct mkhi_gfx_mem_ready req = {0};
-   unsigned int mode = MEI_CL_IO_TX_INTERNAL;
+   unsigned int mode = MEI_CL_IO_TX_INTERNAL | MEI_CL_IO_TX_BLOCKING;
 
req.hdr.group_id = MKHI_GROUP_ID_GFX;
req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
 
dev_dbg(&cldev->dev, "Sending memory ready command\n");
-   return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
+   return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode, 
GFX_MEMORY_READY_TIMEOUT);
 }
 
 static void mei_mkhi_fix(struct mei_cl_device *cldev)
@@ -263,12 +265,13 @@ static void mei_gsc_mkhi_fix_ver(struct mei_cl_device 
*cldev)
 
if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
ret = mei_gfx_memory_ready(cldev);
-   if (ret < 0)
+   if (ret < 0) {
dev_err(&cldev->dev, "memory ready command failed 
%d\n", ret);
-   else
+   } else {
dev_dbg(&cldev->dev, "memory ready command sent\n");
+   cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
+   }
/* we go to reset after that */
-   cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
goto out;
}
 
@@ -374,7 +377,7 @@ static int mei_nfc_if_version(struct mei_cl *cl,
WARN_ON(mutex_is_locked(&bus->device_lock));
 
ret = __mei_cl_send(cl, (u8 *)&cmd, sizeof(cmd), 0,
-   MEI_CL_IO_TX_BLOCKING);
+   MEI_CL_IO_TX_BLOCKING, 0);
if (ret < 0) {
dev_err(bus->dev, "Could not send IF version cmd\n");
return ret;
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 1fbe127ff633..136b45192904 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -29,11 +29,12 @@
  * @length: buffer length
  * @vtag: virtual tag
  * @mode: sending mode
+ * @timeout: send timeout for blocking writes, 0 for infinite timeout
  *
  * Return: written size bytes or < 0 on error
  */
 ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8 vtag,
- unsigned int mode)
+ unsigned int mode, unsigned long timeout)
 {
struct mei_device *bus;
struct mei_cl_cb *cb;
@@ -108,7 +109,7 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, 
size_t length, u8 vtag,
cb->buf.size = 0;
}
 
-   rets = mei_cl_write(cl, cb);
+   rets = mei_cl_write(cl, cb, timeout);
 
if (mode & MEI_CL_IO_SGL && rets == 0)
rets = length;
@@ -254,7 +255,7 @@ ssize_t mei_cldev_send_vtag(struct mei_cl_device *cldev, 
const u8 *buf,
 {
struct mei_cl *cl = cldev->cl;
 
-   return __mei_cl_send(cl, buf, length, vtag, MEI_CL_IO_TX_BLOCKING);
+   return __mei_cl_send(cl, buf, length, vtag, MEI_CL_IO_TX_BLOCKING, 0);
 }
 EXPORT_SYMBOL_GPL(mei_cldev_send_vtag);
 
@@ -924,7 +925,7 @@ ssize_t mei_cldev_send_gsc_command(struct mei_cl_device 
*cldev,
}
 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't wait forever in drop_caches (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Don't wait forever in drop_caches (rev2)
URL   : https://patchwork.freedesktop.org/series/110395/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12333_full -> Patchwork_110395v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@cursor-vs-flip@toggle:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-skl4/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110395v2/shard-skl4/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html

  * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-tglb7/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110395v2/shard-tglb8/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-b-planes.html

  
New tests
-

  New tests have been introduced between CI_DRM_12333_full and 
Patchwork_110395v2_full:

### New IGT tests (1) ###

  * igt@fbdev@pan:
- Statuses : 6 pass(s)
- Exec time: [0.03, 0.07] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [PASS][50], 
[PASS][51], [FAIL][52], [PASS][53], [PASS][54]) ([i915#4392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110395v2/shard-glk5/boot.html
   [31]: 
https://i

[Intel-gfx] KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

[Mauro Carvalho Chehab]

Hi,

I'm facing a couple of issues when testing KUnit with the i915 driver.

The DRM subsystem and the i915 driver has, for a long time, his own
way to do unit tests, which seems to be added before KUnit.

I'm now checking if it is worth start using KUnit at i915. So, I wrote
a RFC with some patches adding support for the tests we have to be
reported using Kernel TAP and KUnit.

There are basically 3 groups of tests there:

- mock tests - check i915 hardware-independent logic;
- live tests - run some hardware-specific tests;
- perf tests - check perf support - also hardware-dependent.

As they depend on i915 driver, they run only on x86, with PCI
stack enabled, but the mock tests run nicely via qemu.

The live and perf tests require a real hardware. As we run them
together with our CI, which, among other things, test module
unload/reload and test loading i915 driver with different
modprobe parameters, the KUnit tests should be able to run as
a module.

While testing KUnit, I noticed a couple of issues:

1. kunit.py parser is currently broken when used with modules

the parser expects "TAP version xx" output, but this won't
happen when loading the kunit test driver.

Are there any plans or patches fixing this issue?

2. current->mm is not initialized

Some tests do mmap(). They need the mm user context to be initialized,
but this is not happening right now.

Are there a way to properly initialize it for KUnit?

3. there's no test filters for modules

In order to be able to do proper CI automation, it is needed to
be able to control what tests will run or not. That's specially
interesting at development time where some tests may not apply
or not run properly on new hardware.

Are there any plans to add support for it at kunit_test_suites()
when the driver is built as module? Ideally, the best would be to
export a per-module filter_glob parameter on such cases.

4. there are actually 3 levels of tests on i915:
- Level 1: mock, live, perf
- Level 2: test group (mmap, fences, ...)
- Level 3: unit tests

Currently, KUnit seems to have just two levels (test suite and tests).
Are there a way to add test groups there?

Regards,
Mauro

Forwarded message:

Date: Thu,  3 Nov 2022 14:51:38 +
From: Mauro Carvalho Chehab 
To: 
Cc: Thomas Hellström , 
linux-kselft...@vger.kernel.org, Michał Winiarski , 
dri-de...@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, Daniel 
Latypov , linux-ker...@vger.kernel.org, 
igt-...@lists.freedesktop.org, Matthew Auld , Daniel 
Vetter , Rodrigo Vivi , 
sk...@linuxfoundation.org, Isabella Basso , David Airlie 
, Christian König 
Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL


The mmap tests require mm in order to work. Failing to do that
will cause a crash:

[  316.820722] BUG: kernel NULL pointer dereference, address: 00e8
[  316.822517] #PF: supervisor write access in kernel mode
[  316.823430] #PF: error_code(0x0002) - not-present page
[  316.824390] PGD 0 P4D 0
[  316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U  
 N 6.1.0-rc2-drm-266703e6f163+ #14
[  316.827503] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 
06/10/2020
[  316.828633] RIP: 0010:down_write_killable+0x50/0x110
[  316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 
ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00  48 0f 
b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74
[  316.830896] RSP: 0018:c90001eabc58 EFLAGS: 00010246
[  316.832008] RAX:  RBX: 00e8 RCX: 
[  316.833141] RDX: 0001 RSI: 81c94fc9 RDI: 81c94fc9
[  316.834195] RBP: 0158 R08: 0001 R09: 
[  316.835231] R10:  R11: 8883a13350b8 R12: 0002
[  316.836259] R13: 0001 R14: 0010 R15: 00e8
[  316.837237] FS:  () GS:8883a380() 
knlGS:
[  316.838214] CS:  0010 DS:  ES:  CR0: 80050033
[  316.839190] CR2: 00e8 CR3: 02812003 CR4: 00770ef0
[  316.840147] PKRU: 5554
[  316.841099] Call Trace:
[  316.842047]  
[  316.842990]  ? vm_mmap_pgoff+0x78/0x150
[  316.843936]  vm_mmap_pgoff+0x78/0x150
[  316.844884]  igt_mmap_offset+0x178/0x1b9 [i915]
[  316.846119]  __igt_mmap+0xfe/0x680 [i915]

Unfortunately, when KUnit module runs, it doesn't create an
user context, causing mmap tests to fail.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +
 1 file changed, 5 insertions(+)

di

[Intel-gfx] [PATCH v3 18/23] drm/fb_helper: Minimize damage-helper overhead

[Thomas Zimmermann]

Pull the test for fb_dirty into the caller to avoid extra work
if no callback has been set. In this case no damage handling is
required and no damage area needs to be computed. Print a warning
if the damage worker runs without getting an fb_dirty callback.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/drm_fb_helper.c | 90 ++---
 1 file changed, 60 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c7c0c0a8532b4..3dfda1e3830b3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -449,12 +449,13 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper 
*fb_helper,
 static void drm_fb_helper_damage_work(struct work_struct *work)
 {
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper, 
damage_work);
+   struct drm_device *dev = helper->dev;
struct drm_clip_rect *clip = &helper->damage_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
int ret;
 
-   if (!helper->funcs->fb_dirty)
+   if (drm_WARN_ON_ONCE(dev, !helper->funcs->fb_dirty))
return;
 
spin_lock_irqsave(&helper->damage_lock, flags);
@@ -659,16 +660,12 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_fini);
 
-static void drm_fb_helper_damage(struct fb_info *info, u32 x, u32 y,
+static void drm_fb_helper_damage(struct drm_fb_helper *helper, u32 x, u32 y,
 u32 width, u32 height)
 {
-   struct drm_fb_helper *helper = info->par;
struct drm_clip_rect *clip = &helper->damage_clip;
unsigned long flags;
 
-   if (!helper->funcs->fb_dirty)
-   return;
-
spin_lock_irqsave(&helper->damage_lock, flags);
clip->x1 = min_t(u32, clip->x1, x);
clip->y1 = min_t(u32, clip->y1, y);
@@ -718,6 +715,7 @@ static void drm_fb_helper_memory_range_to_clip(struct 
fb_info *info, off_t off,
  */
 void drm_fb_helper_deferred_io(struct fb_info *info, struct list_head 
*pagereflist)
 {
+   struct drm_fb_helper *helper = info->par;
unsigned long start, end, min_off, max_off;
struct fb_deferred_io_pageref *pageref;
struct drm_rect damage_area;
@@ -733,17 +731,19 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
if (min_off >= max_off)
return;
 
-   /*
-* As we can only track pages, we might reach beyond the end
-* of the screen and account for non-existing scanlines. Hence,
-* keep the covered memory area within the screen buffer.
-*/
-   max_off = min(max_off, info->screen_size);
+   if (helper->funcs->fb_dirty) {
+   /*
+* As we can only track pages, we might reach beyond the end
+* of the screen and account for non-existing scanlines. Hence,
+* keep the covered memory area within the screen buffer.
+*/
+   max_off = min(max_off, info->screen_size);
 
-   drm_fb_helper_memory_range_to_clip(info, min_off, max_off - min_off, 
&damage_area);
-   drm_fb_helper_damage(info, damage_area.x1, damage_area.y1,
-drm_rect_width(&damage_area),
-drm_rect_height(&damage_area));
+   drm_fb_helper_memory_range_to_clip(info, min_off, max_off - 
min_off, &damage_area);
+   drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
+drm_rect_width(&damage_area),
+drm_rect_height(&damage_area));
+   }
 }
 EXPORT_SYMBOL(drm_fb_helper_deferred_io);
 
@@ -877,6 +877,7 @@ static ssize_t drm_fb_helper_write_screen_buffer(struct 
fb_info *info, const cha
 ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos)
 {
+   struct drm_fb_helper *helper = info->par;
loff_t pos = *ppos;
ssize_t ret;
struct drm_rect damage_area;
@@ -885,10 +886,12 @@ ssize_t drm_fb_helper_sys_write(struct fb_info *info, 
const char __user *buf,
if (ret <= 0)
return ret;
 
-   drm_fb_helper_memory_range_to_clip(info, pos, ret, &damage_area);
-   drm_fb_helper_damage(info, damage_area.x1, damage_area.y1,
-drm_rect_width(&damage_area),
-drm_rect_height(&damage_area));
+   if (helper->funcs->fb_dirty) {
+   drm_fb_helper_memory_range_to_clip(info, pos, ret, 
&damage_area);
+   drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
+drm_rect_width(&damage_area),
+drm_rect_height(&damage_area));
+   }
 
return ret;
 }
@@ -904,8 +907,12 @@ EXPORT

[Intel-gfx] [PATCH v3 15/23] drm/fb-helper: Disconnect damage worker from update logic

[Thomas Zimmermann]

The fbdev helpers implement a damage worker that forwards fbdev
updates to the DRM driver. The worker's update logic depends on
the generic fbdev emulation. Separate the two via function pointer.

The generic fbdev emulation sets struct drm_fb_helper_funcs.fb_dirty,
a new callback that hides the update logic from the damage worker.
It's not possible to use the generic logic with other fbdev emulation,
because it contains additional code for the shadow buffering that
the generic emulation employs.

DRM drivers with internal fbdev emulation can set fb_dirty to their
own implementation if they require damage handling; although no such
drivers currently exist.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/drm_fb_helper.c | 75 -
 include/drm/drm_fb_helper.h | 15 +++
 2 files changed, 61 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bfbb2af144060..f6d22cc4cd876 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -448,35 +448,24 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper 
*fb_helper,
 
 static void drm_fb_helper_damage_work(struct work_struct *work)
 {
-   struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
-   damage_work);
-   struct drm_device *dev = helper->dev;
+   struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper, 
damage_work);
struct drm_clip_rect *clip = &helper->damage_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
int ret;
 
+   if (!helper->funcs->fb_dirty)
+   return;
+
spin_lock_irqsave(&helper->damage_lock, flags);
clip_copy = *clip;
clip->x1 = clip->y1 = ~0;
clip->x2 = clip->y2 = 0;
spin_unlock_irqrestore(&helper->damage_lock, flags);
 
-   /* Call damage handlers only if necessary */
-   if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
-   return;
-
-   if (helper->buffer) {
-   ret = drm_fb_helper_damage_blit(helper, &clip_copy);
-   if (drm_WARN_ONCE(dev, ret, "Damage blitter failed: ret=%d\n", 
ret))
-   goto err;
-   }
-
-   if (helper->fb->funcs->dirty) {
-   ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, 
&clip_copy, 1);
-   if (drm_WARN_ONCE(dev, ret, "Dirty helper failed: ret=%d\n", 
ret))
-   goto err;
-   }
+   ret = helper->funcs->fb_dirty(helper, &clip_copy);
+   if (ret)
+   goto err;
 
return;
 
@@ -670,16 +659,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_fini);
 
-static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)
-{
-   struct drm_device *dev = fb_helper->dev;
-   struct drm_framebuffer *fb = fb_helper->fb;
-
-   return dev->mode_config.prefer_shadow_fbdev ||
-  dev->mode_config.prefer_shadow ||
-  fb->funcs->dirty;
-}
-
 static void drm_fb_helper_damage(struct fb_info *info, u32 x, u32 y,
 u32 width, u32 height)
 {
@@ -687,7 +666,7 @@ static void drm_fb_helper_damage(struct fb_info *info, u32 
x, u32 y,
struct drm_clip_rect *clip = &helper->damage_clip;
unsigned long flags;
 
-   if (!drm_fbdev_use_shadow_fb(helper))
+   if (!helper->funcs->fb_dirty)
return;
 
spin_lock_irqsave(&helper->damage_lock, flags);
@@ -2111,6 +2090,16 @@ void drm_fb_helper_output_poll_changed(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
 
+static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct drm_framebuffer *fb = fb_helper->fb;
+
+   return dev->mode_config.prefer_shadow_fbdev ||
+  dev->mode_config.prefer_shadow ||
+  fb->funcs->dirty;
+}
+
 /* @user: 1=userspace, 0=fbcon */
 static int drm_fbdev_fb_open(struct fb_info *info, int user)
 {
@@ -2487,8 +2476,36 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
return 0;
 }
 
+static int drm_fbdev_fb_dirty(struct drm_fb_helper *helper, struct 
drm_clip_rect *clip)
+{
+   struct drm_device *dev = helper->dev;
+   int ret;
+
+   if (!drm_fbdev_use_shadow_fb(helper))
+   return 0;
+
+   /* Call damage handlers only if necessary */
+   if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+   return 0;
+
+   if (helper->buffer) {
+   ret = drm_fb_helper_damage_blit(helper, clip);
+   if (drm_WARN_ONCE(dev, ret, "Damage blitter failed: ret=%d\n", 
ret))
+   return ret;
+   }
+
+   if (helper->fb->funcs->dirty) {
+   ret 

[Intel-gfx] [PATCH v3 16/23] drm/fb-helper: Call fb_sync in I/O functions

[Thomas Zimmermann]

Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the
behavior of fbdev. Fbdev implementations of fb_read and fb_write in
struct fb_ops invoke fb_sync to synchronize with outstanding operations
before I/O. Doing the same in DRM implementations will allow us to use
them throughout DRM drivers.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f6d22cc4cd876..379e0d2f67198 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2246,6 +2246,9 @@ static ssize_t drm_fbdev_fb_read(struct fb_info *info, 
char __user *buf,
if (total_size - count < pos)
count = total_size - pos;
 
+   if (info->fbops->fb_sync)
+   info->fbops->fb_sync(info);
+
if (drm_fbdev_use_iomem(info))
ret = fb_read_screen_base(info, buf, count, pos);
else
@@ -2327,6 +2330,9 @@ static ssize_t drm_fbdev_fb_write(struct fb_info *info, 
const char __user *buf,
count = total_size - pos;
}
 
+   if (info->fbops->fb_sync)
+   info->fbops->fb_sync(info);
+
/*
 * Copy to framebuffer even if we already logged an error. Emulates
 * the behavior of the original fbdev implementation.
-- 
2.38.0

[Intel-gfx] [PATCH v3 17/23] drm/fb-helper: Perform all fbdev I/O with the same implementation

[Thomas Zimmermann]

Implement the fbdev's read/write helpers with the same functions. Use
the generic fbdev's code as template. Convert all drivers.

DRM's fb helpers must implement regular I/O functionality in struct
fb_ops and possibly perform a damage update. Handle all this in the
same functions and convert drivers. The functionality has been used
as part of the generic fbdev code for some time. The drivers don't
set struct drm_fb_helper.fb_dirty, so they will not be affected by
damage handling.

For I/O memory, fb helpers now provide drm_fb_helper_cfb_read() and
drm_fb_helper_cfb_write(). Several drivers require these. Until now
tegra used I/O read and write, although the memory buffer appears to
be in system memory. So use _sys_ helpers now.

v3:
* fix docs (Javier)
v2:
* rebase onto vmwgfx changes

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/armada/armada_fbdev.c  |   2 +
 drivers/gpu/drm/drm_fb_helper.c| 383 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   2 +
 drivers/gpu/drm/gma500/framebuffer.c   |   2 +
 drivers/gpu/drm/i915/display/intel_fbdev.c |   2 +
 drivers/gpu/drm/radeon/radeon_fb.c |   2 +
 drivers/gpu/drm/tegra/fb.c |   2 +
 include/drm/drm_fb_helper.h|  17 +
 8 files changed, 254 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index f02f6a5ba8320..584cee123bd8e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -19,6 +19,8 @@
 static const struct fb_ops armada_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
+   .fb_read= drm_fb_helper_cfb_read,
+   .fb_write   = drm_fb_helper_cfb_write,
.fb_fillrect= drm_fb_helper_cfb_fillrect,
.fb_copyarea= drm_fb_helper_cfb_copyarea,
.fb_imageblit   = drm_fb_helper_cfb_imageblit,
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 379e0d2f67198..c7c0c0a8532b4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -747,30 +747,132 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
 }
 EXPORT_SYMBOL(drm_fb_helper_deferred_io);
 
+typedef ssize_t (*drm_fb_helper_read_screen)(struct fb_info *info, char __user 
*buf,
+size_t count, loff_t pos);
+
+static ssize_t __drm_fb_helper_read(struct fb_info *info, char __user *buf, 
size_t count,
+   loff_t *ppos, drm_fb_helper_read_screen 
read_screen)
+{
+   loff_t pos = *ppos;
+   size_t total_size;
+   ssize_t ret;
+
+   if (info->screen_size)
+   total_size = info->screen_size;
+   else
+   total_size = info->fix.smem_len;
+
+   if (pos >= total_size)
+   return 0;
+   if (count >= total_size)
+   count = total_size;
+   if (total_size - count < pos)
+   count = total_size - pos;
+
+   if (info->fbops->fb_sync)
+   info->fbops->fb_sync(info);
+
+   ret = read_screen(info, buf, count, pos);
+   if (ret > 0)
+   *ppos += ret;
+
+   return ret;
+}
+
+typedef ssize_t (*drm_fb_helper_write_screen)(struct fb_info *info, const char 
__user *buf,
+ size_t count, loff_t pos);
+
+static ssize_t __drm_fb_helper_write(struct fb_info *info, const char __user 
*buf, size_t count,
+loff_t *ppos, drm_fb_helper_write_screen 
write_screen)
+{
+   loff_t pos = *ppos;
+   size_t total_size;
+   ssize_t ret;
+   int err = 0;
+
+   if (info->screen_size)
+   total_size = info->screen_size;
+   else
+   total_size = info->fix.smem_len;
+
+   if (pos > total_size)
+   return -EFBIG;
+   if (count > total_size) {
+   err = -EFBIG;
+   count = total_size;
+   }
+   if (total_size - count < pos) {
+   if (!err)
+   err = -ENOSPC;
+   count = total_size - pos;
+   }
+
+   if (info->fbops->fb_sync)
+   info->fbops->fb_sync(info);
+
+   /*
+* Copy to framebuffer even if we already logged an error. Emulates
+* the behavior of the original fbdev implementation.
+*/
+   ret = write_screen(info, buf, count, pos);
+   if (ret < 0)
+   return ret; /* return last error, if any */
+   else if (!ret)
+   return err; /* return previous error, if any */
+
+   *ppos += ret;
+
+   return ret;
+}
+
+static ssize_t drm_fb_helper_read_screen_buffer(struct fb_info *info, char 
__user *buf,
+   size_t count, loff_t pos)
+{
+   const char *src = info->screen_buffer +

[Intel-gfx] [PATCH v3 22/23] drm/fb-helper: Remove unnecessary include statements

[Thomas Zimmermann]

Remove include statements for  where it is not
required (i.e., most of them). In a few places include other header
files that are required by the source code.

v3:
* fix amdgpu include statements
* fix rockchip include statements

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c  | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   | 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   | 1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c| 1 -
 drivers/gpu/drm/ast/ast_drv.h   | 1 -
 drivers/gpu/drm/bridge/tc358762.c   | 2 +-
 drivers/gpu/drm/drm_crtc_helper.c   | 1 -
 drivers/gpu/drm/drm_gem_framebuffer_helper.c| 1 -
 drivers/gpu/drm/drm_probe_helper.c  | 1 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h   | 3 ++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
 drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 1 -
 drivers/gpu/drm/imx/imx-ldb.c   | 2 +-
 drivers/gpu/drm/imx/imx-tve.c   | 1 -
 drivers/gpu/drm/imx/parallel-display.c  | 2 +-
 drivers/gpu/drm/kmb/kmb_plane.c | 1 -
 drivers/gpu/drm/mgag200/mgag200_drv.h   | 1 -
 drivers/gpu/drm/qxl/qxl_drv.h   | 1 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 +
 drivers/gpu/drm/tidss/tidss_kms.c   | 1 -
 drivers/gpu/drm/v3d/v3d_drv.c   | 1 -
 drivers/gpu/drm/vboxvideo/vbox_main.c   | 1 -
 drivers/gpu/drm/virtio/virtgpu_drv.h| 1 -
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 1 -
 31 files changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 491d4846fc02c..e1320edfc5274 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -26,7 +26,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ddaecb2610c94..56a031a2e087e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -37,6 +37,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index dd6f9ae6fbe9f..311a8ea6f0654 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -39,8 +39,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index bf1ff8f0e7120..e3a18f069ce5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -29,6 +29,7 @@
 #include "amdgpu.h"
 #include 
 #include 
+#include 
 #include "amdgpu_uvd.h"
 #include "amdgpu_vce.h"
 #include "atom.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 37322550d7508..8a39300b1a845 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 05051d5d2ec31..90f87b2d985b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c928bc9eb2026..0352de72c886a 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 62315fd5a05f2..07bd16e820461 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -23,6 +23,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 87d5e4c21cb37..d73df100f2b3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -21,6 +21,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
diff --git a/driv

[Intel-gfx] [PATCH v3 14/23] drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info postfix

[Thomas Zimmermann]

Rename drm_fb_helper_unregister_fbi() to drm_fb_helper_unregister_info()
as part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/armada/armada_fbdev.c  | 2 +-
 drivers/gpu/drm/drm_fb_helper.c| 8 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 2 +-
 drivers/gpu/drm/gma500/framebuffer.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
 drivers/gpu/drm/msm/msm_fbdev.c| 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c| 2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
 drivers/gpu/drm/tegra/fb.c | 2 +-
 include/drm/drm_fb_helper.h| 4 ++--
 11 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index eaae98d9377ae..f02f6a5ba8320 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -155,7 +155,7 @@ void armada_fbdev_fini(struct drm_device *dev)
struct drm_fb_helper *fbh = priv->fbdev;
 
if (fbh) {
-   drm_fb_helper_unregister_fbi(fbh);
+   drm_fb_helper_unregister_info(fbh);
 
drm_fb_helper_fini(fbh);
 
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 881e6a04fa706..bfbb2af144060 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -612,19 +612,19 @@ struct fb_info *drm_fb_helper_alloc_info(struct 
drm_fb_helper *fb_helper)
 EXPORT_SYMBOL(drm_fb_helper_alloc_info);
 
 /**
- * drm_fb_helper_unregister_fbi - unregister fb_info framebuffer device
+ * drm_fb_helper_unregister_info - unregister fb_info framebuffer device
  * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * A wrapper around unregister_framebuffer, to release the fb_info
  * framebuffer device. This must be called before releasing all resources for
  * @fb_helper by calling drm_fb_helper_fini().
  */
-void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper)
+void drm_fb_helper_unregister_info(struct drm_fb_helper *fb_helper)
 {
if (fb_helper && fb_helper->info)
unregister_framebuffer(fb_helper->info);
 }
-EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
+EXPORT_SYMBOL(drm_fb_helper_unregister_info);
 
 /**
  * drm_fb_helper_fini - finialize a &struct drm_fb_helper
@@ -2497,7 +2497,7 @@ static void drm_fbdev_client_unregister(struct 
drm_client_dev *client)
 
if (fb_helper->info)
/* drm_fbdev_fb_destroy() takes care of cleanup */
-   drm_fb_helper_unregister_fbi(fb_helper);
+   drm_fb_helper_unregister_info(fb_helper);
else
drm_fbdev_release(fb_helper);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8741eb0b1b604..86c489d945849 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -201,7 +201,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
drm_framebuffer_remove(fb);
}
 
-   drm_fb_helper_unregister_fbi(fb_helper);
+   drm_fb_helper_unregister_info(fb_helper);
 
drm_fb_helper_fini(fb_helper);
 }
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 6d0e3bf6435ee..6098d936e44b6 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -383,7 +383,7 @@ static int psb_fbdev_destroy(struct drm_device *dev,
 {
struct drm_framebuffer *fb = fb_helper->fb;
 
-   drm_fb_helper_unregister_fbi(fb_helper);
+   drm_fb_helper_unregister_info(fb_helper);
 
drm_fb_helper_fini(fb_helper);
drm_framebuffer_unregister_private(fb);
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 05b841343ea3e..1b576c859837b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -584,7 +584,7 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-   drm_fb_helper_unregister_fbi(&ifbdev->helper);
+   drm_fb_helper_unregister_info(&ifbdev->helper);
 }
 
 void intel_fbdev_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index 4d9a0fcbf95b6..31e1e30cb52a2 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -182,7 +182,7 @@ void msm_fbdev_free(struct drm_device *dev)
 
DBG();
 
-   drm_fb_helper_unregister_fbi(helper);
+   drm_fb_helper_unregister_info(helper);
 
drm_fb_helper_fini(helper);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c

[Intel-gfx] [PATCH v3 12/23] drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper

[Thomas Zimmermann]

Rename struct drm_fb_helper.fbdev to info. The current name is
misleading as it overlaps with generic fbdev naming conventions.
Adapt to the usual naming in fbdev drivers by calling the field
'info'. No functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/drm_fb_helper.c| 40 +++---
 drivers/gpu/drm/i915/display/intel_fbdev.c |  2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c| 23 ++---
 drivers/gpu/drm/omapdrm/omap_fbdev.c   |  2 +-
 drivers/gpu/drm/tegra/fb.c |  2 +-
 include/drm/drm_fb_helper.h|  4 +--
 6 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 71edb80fe0fb9..480bf4f568b7b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -368,7 +368,7 @@ static void drm_fb_helper_resume_worker(struct work_struct 
*work)
resume_work);
 
console_lock();
-   fb_set_suspend(helper->fbdev, 0);
+   fb_set_suspend(helper->info, 0);
console_unlock();
 }
 
@@ -401,7 +401,7 @@ static void drm_fb_helper_damage_blit_real(struct 
drm_fb_helper *fb_helper,
break;
}
 
-   src = fb_helper->fbdev->screen_buffer + offset;
+   src = fb_helper->info->screen_buffer + offset;
iosys_map_incr(dst, offset); /* go to first pixel within clip rect */
 
for (y = clip->y1; y < clip->y2; y++) {
@@ -598,7 +598,7 @@ struct fb_info *drm_fb_helper_alloc_fbi(struct 
drm_fb_helper *fb_helper)
goto err_free_cmap;
}
 
-   fb_helper->fbdev = info;
+   fb_helper->info = info;
info->skip_vt_switch = true;
 
return info;
@@ -621,8 +621,8 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
  */
 void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper)
 {
-   if (fb_helper && fb_helper->fbdev)
-   unregister_framebuffer(fb_helper->fbdev);
+   if (fb_helper && fb_helper->info)
+   unregister_framebuffer(fb_helper->info);
 }
 EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
 
@@ -647,13 +647,13 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
cancel_work_sync(&fb_helper->resume_work);
cancel_work_sync(&fb_helper->damage_work);
 
-   info = fb_helper->fbdev;
+   info = fb_helper->info;
if (info) {
if (info->cmap.len)
fb_dealloc_cmap(&info->cmap);
framebuffer_release(info);
}
-   fb_helper->fbdev = NULL;
+   fb_helper->info = NULL;
 
mutex_lock(&kernel_fb_helper_lock);
if (!list_empty(&fb_helper->kernel_fb_list)) {
@@ -914,8 +914,8 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
  */
 void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend)
 {
-   if (fb_helper && fb_helper->fbdev)
-   fb_set_suspend(fb_helper->fbdev, suspend);
+   if (fb_helper && fb_helper->info)
+   fb_set_suspend(fb_helper->info, suspend);
 }
 EXPORT_SYMBOL(drm_fb_helper_set_suspend);
 
@@ -938,20 +938,20 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
 void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
bool suspend)
 {
-   if (!fb_helper || !fb_helper->fbdev)
+   if (!fb_helper || !fb_helper->info)
return;
 
/* make sure there's no pending/ongoing resume */
flush_work(&fb_helper->resume_work);
 
if (suspend) {
-   if (fb_helper->fbdev->state != FBINFO_STATE_RUNNING)
+   if (fb_helper->info->state != FBINFO_STATE_RUNNING)
return;
 
console_lock();
 
} else {
-   if (fb_helper->fbdev->state == FBINFO_STATE_RUNNING)
+   if (fb_helper->info->state == FBINFO_STATE_RUNNING)
return;
 
if (!console_trylock()) {
@@ -960,7 +960,7 @@ void drm_fb_helper_set_suspend_unlocked(struct 
drm_fb_helper *fb_helper,
}
}
 
-   fb_set_suspend(fb_helper->fbdev, suspend);
+   fb_set_suspend(fb_helper->info, suspend);
console_unlock();
 }
 EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
@@ -1850,7 +1850,7 @@ EXPORT_SYMBOL(drm_fb_helper_fill_info);
 /*
  * This is a continuation of drm_setup_crtcs() that sets up anything related
  * to the framebuffer. During initialization, drm_setup_crtcs() is called 
before
- * the framebuffer has been allocated (fb_helper->fb and fb_helper->fbdev).
+ * the framebuffer has been allocated (fb_helper->fb and fb_helper->info).
  * So, any setup that touches those fields needs to be done here instead of in
  * drm_setup_crtcs().
  */
@@ -1858,7 +1858,7 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper 
*fb_helper)
 {
struct drm_client_dev *client = &fb_helper-

[Intel-gfx] [PATCH v3 19/23] drm/fb-helper: Always initialize generic fbdev emulation

[Thomas Zimmermann]

Initialize the generic fbdev emulation even if it has been disabled
on the kernel command line. The hotplug and mode initialization will
fail accordingly.

The kernel parameter can still be changed at runtime and the emulation
will initialize after hotplugging the connector.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/drm_fb_helper.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3dfda1e3830b3..95f389433c4a6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -526,11 +526,6 @@ int drm_fb_helper_init(struct drm_device *dev,
 {
int ret;
 
-   if (!drm_fbdev_emulation) {
-   dev->fb_helper = fb_helper;
-   return 0;
-   }
-
/*
 * If this is not the generic fbdev client, initialize a drm_client
 * without callbacks so we can use the modesets.
@@ -2716,9 +2711,6 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
 
-   if (!drm_fbdev_emulation)
-   return;
-
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper) {
drm_err(dev, "Failed to allocate fb_helper\n");
-- 
2.38.0

[Intel-gfx] [PATCH v3 23/23] drm/fb-helper: Clarify use of last_close and output_poll_changed

[Thomas Zimmermann]

Clarify documentation in the use of struct drm_driver.last_close and
struct drm_mode_config_funcs.output_poll_changed. Those callbacks should
not be said for fbdev implementations on top of struct drm_client_funcs.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5eb2f0d4bf8d4..e0384f967c0b3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -89,11 +89,13 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * It will automatically set up deferred I/O if the driver requires a shadow
  * buffer.
  *
- * At runtime drivers should restore the fbdev console by using
+ * Existing fbdev implementations should restore the fbdev console by using
  * drm_fb_helper_lastclose() as their &drm_driver.lastclose callback.
  * They should also notify the fb helper code from updates to the output
  * configuration by using drm_fb_helper_output_poll_changed() as their
- * &drm_mode_config_funcs.output_poll_changed callback.
+ * &drm_mode_config_funcs.output_poll_changed callback. New implementations
+ * of fbdev should be build on top of struct &drm_client_funcs, which handles
+ * this automatically. Setting the old callbacks should be avoided.
  *
  * For suspend/resume consider using drm_mode_config_helper_suspend() and
  * drm_mode_config_helper_resume() which takes care of fbdev as well.
-- 
2.38.0

[Intel-gfx] [PATCH v3 21/23] drm/fb-helper: Move generic fbdev emulation into separate source file

[Thomas Zimmermann]

Move the generic fbdev implementation into its own source and header
file. Adapt drivers. No functional changes, but some of the internal
helpers have been renamed to fit into the drm_fbdev_ naming scheme.

v3:
* rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h}
* rebase onto vmwgfx changes
* rebase onto xlnx changes
* fix include statements in amdgpu

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/Makefile  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |   1 +
 .../gpu/drm/arm/display/komeda/komeda_drv.c   |   2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c   |   2 +-
 drivers/gpu/drm/arm/malidp_drv.c  |   2 +-
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c   |   2 +-
 drivers/gpu/drm/ast/ast_drv.c |   1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |   2 +-
 drivers/gpu/drm/drm_fb_helper.c   | 498 +-
 drivers/gpu/drm/drm_fbdev_generic.c   | 493 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |   2 +-
 drivers/gpu/drm/gud/gud_drv.c |   2 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |   1 +
 .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c   |   2 +-
 drivers/gpu/drm/hyperv/hyperv_drm_drv.c   |   2 +-
 drivers/gpu/drm/imx/dcss/dcss-kms.c   |   2 +-
 drivers/gpu/drm/imx/imx-drm-core.c|   2 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |   2 +-
 drivers/gpu/drm/kmb/kmb_drv.c |   2 +-
 drivers/gpu/drm/logicvc/logicvc_drm.c |   2 +-
 drivers/gpu/drm/mcde/mcde_drv.c   |   2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|   2 +-
 drivers/gpu/drm/meson/meson_drv.c |   2 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c |   1 +
 drivers/gpu/drm/mxsfb/lcdif_drv.c |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c |   2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c  |   2 +-
 drivers/gpu/drm/pl111/pl111_drv.c |   2 +-
 drivers/gpu/drm/qxl/qxl_drv.c |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |   2 +-
 drivers/gpu/drm/solomon/ssd130x.c |   2 +-
 drivers/gpu/drm/sti/sti_drv.c |   2 +-
 drivers/gpu/drm/stm/drv.c |   2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c |   2 +-
 drivers/gpu/drm/tidss/tidss_drv.c |   2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   2 +-
 drivers/gpu/drm/tiny/arcpgu.c |   2 +-
 drivers/gpu/drm/tiny/bochs.c  |   2 +-
 drivers/gpu/drm/tiny/cirrus.c |   2 +-
 drivers/gpu/drm/tiny/gm12u320.c   |   2 +-
 drivers/gpu/drm/tiny/hx8357d.c|   2 +-
 drivers/gpu/drm/tiny/ili9163.c|   2 +-
 drivers/gpu/drm/tiny/ili9225.c|   2 +-
 drivers/gpu/drm/tiny/ili9341.c|   2 +-
 drivers/gpu/drm/tiny/ili9486.c|   2 +-
 drivers/gpu/drm/tiny/mi0283qt.c   |   2 +-
 drivers/gpu/drm/tiny/ofdrm.c  |   2 +-
 drivers/gpu/drm/tiny/panel-mipi-dbi.c |   2 +-
 drivers/gpu/drm/tiny/repaper.c|   2 +-
 drivers/gpu/drm/tiny/simpledrm.c  |   2 +-
 drivers/gpu/drm/tiny/st7586.c |   2 +-
 drivers/gpu/drm/tiny/st7735r.c|   2 +-
 drivers/gpu/drm/tve200/tve200_drv.c   |   2 +-
 drivers/gpu/drm/udl/udl_drv.c |   2 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.c  |   2 +-
 drivers/gpu/drm/vc4/vc4_drv.c |   2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c  |   1 +
 drivers/gpu/drm/vkms/vkms_drv.c   |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |   2 +-
 drivers/gpu/drm/xlnx/zynqmp_kms.c |   2 +-
 include/drm/drm_fb_helper.h   |   9 -
 include/drm/drm_fbdev_generic.h   |  15 +
 63 files changed, 571 insertions(+), 558 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_fbdev_generic.c
 create mode 100644 include/drm/drm_fbdev_generic.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6e55c47288e42..c44a54cadb618 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -117,7 +117,9 @@ drm_kms_helper-y := \
drm_self_refresh_helper.o \
drm_simple_kms_helper.o
 drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
-drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
+drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += \
+   drm_fbdev_generic.o \
+   drm_fb_helper.o
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 
 #
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 3c9fecdd6b2f3..ca96ee2c2c962 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -25,6 +25,7 @@
 #inclu

[Intel-gfx] [PATCH v3 20/23] drm/fb-helper: Set flag in struct drm_fb_helper for leaking physical addresses

[Thomas Zimmermann]

Uncouple the parameter drm_leak_fbdev_smem from the implementation by
setting a flag in struct drm_fb_helper. This will help to move the
generic fbdev emulation into its own source file, while keeping the
parameter in drm_fb_helper.c. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_fb_helper.c | 10 +++---
 include/drm/drm_fb_helper.h |  2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 95f389433c4a6..105d9c8fe3250 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -74,7 +74,7 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
  * considered as a broken and legacy behaviour from a modern fbdev device.
  */
 #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
-static bool drm_leak_fbdev_smem = false;
+static bool drm_leak_fbdev_smem;
 module_param_unsafe(drm_leak_fbdev_smem, bool, 0600);
 MODULE_PARM_DESC(drm_leak_fbdev_smem,
 "Allow unsafe leaking fbdev physical smem address 
[default=false]");
@@ -1968,6 +1968,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
sizes.surface_height = config->max_height;
}
 
+#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
+   fb_helper->hint_leak_smem_start = drm_leak_fbdev_smem;
+#endif
+
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
if (ret < 0)
@@ -2165,7 +2169,7 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
info->var.pixclock = 0;
/* Shamelessly allow physical address leaking to userspace */
 #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
-   if (!drm_leak_fbdev_smem)
+   if (!fb_helper->hint_leak_smem_start)
 #endif
/* don't leak any physical addresses to userspace */
info->flags |= FBINFO_HIDE_SMEM_START;
@@ -2564,7 +2568,7 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
 * case.
 */
 #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
-   if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0 &&
+   if (fb_helper->hint_leak_smem_start && fbi->fix.smem_start == 0 
&&
!drm_WARN_ON_ONCE(dev, map.is_iomem))
fbi->fix.smem_start =
page_to_phys(virt_to_page(fbi->screen_buffer));
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6581183618b89..3dfb5d1093871 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -199,6 +199,8 @@ struct drm_fb_helper {
 * See also: @deferred_setup
 */
int preferred_bpp;
+
+   bool hint_leak_smem_start;
 };
 
 static inline struct drm_fb_helper *
-- 
2.38.0

[Intel-gfx] [PATCH v3 13/23] drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix

[Thomas Zimmermann]

Rename drm_fb_helper_alloc_fbi() to drm_fb_helper_alloc_info() as
part of unifying the naming within fbdev helpers. Adapt drivers. No
functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/armada/armada_fbdev.c  | 2 +-
 drivers/gpu/drm/drm_fb_helper.c| 8 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  | 2 +-
 drivers/gpu/drm/gma500/framebuffer.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +-
 drivers/gpu/drm/msm/msm_fbdev.c| 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c| 2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
 drivers/gpu/drm/tegra/fb.c | 2 +-
 include/drm/drm_fb_helper.h| 4 ++--
 11 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 38f5170c0fea6..eaae98d9377ae 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -72,7 +72,7 @@ static int armada_fbdev_create(struct drm_fb_helper *fbh,
if (IS_ERR(dfb))
return PTR_ERR(dfb);
 
-   info = drm_fb_helper_alloc_fbi(fbh);
+   info = drm_fb_helper_alloc_info(fbh);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
goto err_fballoc;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 480bf4f568b7b..881e6a04fa706 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -558,7 +558,7 @@ int drm_fb_helper_init(struct drm_device *dev,
 EXPORT_SYMBOL(drm_fb_helper_init);
 
 /**
- * drm_fb_helper_alloc_fbi - allocate fb_info and some of its members
+ * drm_fb_helper_alloc_info - allocate fb_info and some of its members
  * @fb_helper: driver-allocated fbdev helper
  *
  * A helper to alloc fb_info and the members cmap and apertures. Called
@@ -570,7 +570,7 @@ EXPORT_SYMBOL(drm_fb_helper_init);
  * fb_info pointer if things went okay, pointer containing error code
  * otherwise
  */
-struct fb_info *drm_fb_helper_alloc_fbi(struct drm_fb_helper *fb_helper)
+struct fb_info *drm_fb_helper_alloc_info(struct drm_fb_helper *fb_helper)
 {
struct device *dev = fb_helper->dev->dev;
struct fb_info *info;
@@ -609,7 +609,7 @@ struct fb_info *drm_fb_helper_alloc_fbi(struct 
drm_fb_helper *fb_helper)
framebuffer_release(info);
return ERR_PTR(ret);
 }
-EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
+EXPORT_SYMBOL(drm_fb_helper_alloc_info);
 
 /**
  * drm_fb_helper_unregister_fbi - unregister fb_info framebuffer device
@@ -2440,7 +2440,7 @@ static int drm_fb_helper_generic_probe(struct 
drm_fb_helper *fb_helper,
fb_helper->fb = buffer->fb;
fb = buffer->fb;
 
-   fbi = drm_fb_helper_alloc_fbi(fb_helper);
+   fbi = drm_fb_helper_alloc_info(fb_helper);
if (IS_ERR(fbi))
return PTR_ERR(fbi);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 767afd2bfa822..8741eb0b1b604 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -63,7 +63,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
unsigned int size = fb->width * fb->height * fb->format->cpp[0];
unsigned long offset;
 
-   fbi = drm_fb_helper_alloc_fbi(helper);
+   fbi = drm_fb_helper_alloc_info(helper);
if (IS_ERR(fbi)) {
DRM_DEV_ERROR(to_dma_dev(helper->dev),
  "failed to allocate fb info.\n");
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 5f502a0048ab8..6d0e3bf6435ee 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -268,7 +268,7 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
 
memset(dev_priv->vram_addr + backing->offset, 0, size);
 
-   info = drm_fb_helper_alloc_fbi(fb_helper);
+   info = drm_fb_helper_alloc_info(fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
goto err_drm_gem_object_put;
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index d533ecd451025..05b841343ea3e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -254,7 +254,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unlock;
}
 
-   info = drm_fb_helper_alloc_fbi(helper);
+   info = drm_fb_helper_alloc_info(helper);
if (IS_ERR(info)) {
drm_err(&dev_priv->drm, "Failed to allocate fb_info (%pe)\n", 
info);
ret = PTR_ERR(info);
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index b373e30003203..4d9a0fcbf95b6 100644
--- a/drivers/gpu/d

[Intel-gfx] [PATCH v3 11/23] drm/fb-helper: Cleanup include statements in header file

[Thomas Zimmermann]

Only include what we have to.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 include/drm/drm_fb_helper.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index fddd0d1af6891..e923089522896 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -32,11 +32,9 @@
 
 struct drm_fb_helper;
 
-#include 
-#include 
-#include 
 #include 
-#include 
+
+#include 
 
 enum mode_set_atomic {
LEAVE_ATOMIC_MODE_SET,
-- 
2.38.0

[Intel-gfx] [PATCH v3 08/23] drm/rockchip: Don't set struct drm_driver.output_poll_changed

[Thomas Zimmermann]

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as rockchip uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
* fix commit description (Christian)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 092bf863110b7..7de64b0ad047f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -101,7 +100,6 @@ rockchip_fb_create(struct drm_device *dev, struct drm_file 
*file,
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
.fb_create = rockchip_fb_create,
-   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.38.0

[Intel-gfx] [PATCH v3 06/23] drm/ingenic: Don't set struct drm_driver.output_poll_changed

[Thomas Zimmermann]

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as ingenic uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
* fix commit description (Christian, Sergey)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ab0515d2c420a..99f86f1ba8bee 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1018,7 +1018,6 @@ static const struct drm_bridge_funcs 
ingenic_drm_bridge_funcs = {
 
 static const struct drm_mode_config_funcs ingenic_drm_mode_config_funcs = {
.fb_create  = ingenic_drm_gem_fb_create,
-   .output_poll_changed= drm_fb_helper_output_poll_changed,
.atomic_check   = drm_atomic_helper_check,
.atomic_commit  = drm_atomic_helper_commit,
 };
-- 
2.38.0

[Intel-gfx] [PATCH v3 10/23] drm/tve200: Include

[Thomas Zimmermann]

Include  for of_match_ptr().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/tve200/tve200_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tve200/tve200_drv.c 
b/drivers/gpu/drm/tve200/tve200_drv.c
index 04db72e3fa9c2..611785e097576 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.38.0

[Intel-gfx] [PATCH v3 09/23] drm/panel-ili9341: Include

[Thomas Zimmermann]

Include  for devm_of_find_backlight().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 39dc40cf681f0..b59472c29a40d 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -18,6 +18,7 @@
  * Copyright 2018 David Lechner 
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.38.0

[Intel-gfx] [PATCH v3 03/23] drm/vboxvideo: Don't set struct drm_driver.lastclose

[Thomas Zimmermann]

Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as vboxvideo uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index f4f2bd79a7cb6..1cd716eb17a1c 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -178,8 +178,6 @@ static const struct drm_driver driver = {
.driver_features =
DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
 
-   .lastclose = drm_fb_helper_lastclose,
-
.fops = &vbox_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
-- 
2.38.0

[Intel-gfx] [PATCH v3 07/23] drm/logicvc: Don't set struct drm_driver.output_poll_changed

[Thomas Zimmermann]

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as logicvc uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
* fix commit description (Christian)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/logicvc/logicvc_mode.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/logicvc/logicvc_mode.c 
b/drivers/gpu/drm/logicvc/logicvc_mode.c
index d8207ffda1af9..9971950ebd4ee 100644
--- a/drivers/gpu/drm/logicvc/logicvc_mode.c
+++ b/drivers/gpu/drm/logicvc/logicvc_mode.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -26,7 +25,6 @@
 
 static const struct drm_mode_config_funcs logicvc_mode_config_funcs = {
.fb_create  = drm_gem_fb_create,
-   .output_poll_changed= drm_fb_helper_output_poll_changed,
.atomic_check   = drm_atomic_helper_check,
.atomic_commit  = drm_atomic_helper_commit,
 };
-- 
2.38.0

[Intel-gfx] [PATCH v3 04/23] drm/amdgpu: Don't set struct drm_driver.output_poll_changed

[Thomas Zimmermann]

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
* fix commit description (Christian)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 1 -
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 1a06b8d724f39..dd6f9ae6fbe9f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1214,7 +1214,6 @@ amdgpu_display_user_framebuffer_create(struct drm_device 
*dev,
 
 const struct drm_mode_config_funcs amdgpu_mode_funcs = {
.fb_create = amdgpu_display_user_framebuffer_create,
-   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list amdgpu_underscan_enum_list[] =
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3c072754738d2..d58dd916488a1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -82,7 +82,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2810,7 +2809,6 @@ const struct amdgpu_ip_block_version dm_ip_block =
 static const struct drm_mode_config_funcs amdgpu_dm_mode_funcs = {
.fb_create = amdgpu_display_user_framebuffer_create,
.get_format_info = amd_get_format_info,
-   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = amdgpu_dm_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.38.0

[Intel-gfx] [PATCH v3 02/23] drm/mcde: Don't set struct drm_driver.lastclose

[Thomas Zimmermann]

Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as mcde uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 1c4482ad507d9..38c3907bb151a 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -203,7 +203,6 @@ DEFINE_DRM_GEM_DMA_FOPS(drm_fops);
 static const struct drm_driver mcde_drm_driver = {
.driver_features =
DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-   .lastclose = drm_fb_helper_lastclose,
.ioctls = NULL,
.fops = &drm_fops,
.name = "mcde",
-- 
2.38.0

[Intel-gfx] [PATCH v3 01/23] drm/komeda: Don't set struct drm_driver.lastclose

[Thomas Zimmermann]

Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as komeda uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 451746ebbe713..62dc64550793e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -59,7 +58,6 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data)
 
 static const struct drm_driver komeda_kms_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
-   .lastclose  = drm_fb_helper_lastclose,
DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(komeda_gem_dma_dumb_create),
.fops = &komeda_cma_fops,
.name = "komeda",
-- 
2.38.0

[Intel-gfx] [PATCH v3 05/23] drm/imx/dcss: Don't set struct drm_driver.output_poll_changed

[Thomas Zimmermann]

Don't set struct drm_driver.output_poll_changed. It's used to restore
the fbdev console. But as DCSS uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See the
functions drm_kms_helper_hotplug_event() and
drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c.

v2:
* fix commit description (Christian)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c 
b/drivers/gpu/drm/imx/dcss/dcss-kms.c
index b4f82ebca5325..1defd6a40f11d 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
@@ -21,7 +21,6 @@ DEFINE_DRM_GEM_DMA_FOPS(dcss_cma_fops);
 
 static const struct drm_mode_config_funcs dcss_drm_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
-   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.38.0

[Intel-gfx] [PATCH v3 00/23] drm/fb-helper: Untangle fbdev emulation and helpers

[Thomas Zimmermann]

Separate generic fbdev emulation from the helper code that is shared
among the various fbdev implementations within DRM. Affects many drivers.

It has become apparent that our fully generic fbdev emulation will
never produce optimal results for all drivers. In its current form,
it is also hard to maintain. The goal of this patchset is to improve
readability and streamline the fbdev helper code within DRM. In the
long term, we want to get to a point where drivers or memory managers
can pick and combine the various helpers for optimal fbdev support.

Patches 1 to 8 start by preparing drivers. Setting struct drm_driver's
lastclose and output_poll_changed is not required by generic fbdev
emulation.

Two drivers depend on fb helpers implicitly including other Linux header
files. Fixing this in patches 9 and 10 allows to remove unnecesary include
statements from the fb-helper header in patch 11.

Do some renaming in patches 12 to 14.

There are currently various implementation of the fbdev I/O helpers
with varying feature sets. The fb helpers for fbdev I/O should all call
fb_sync, which is what fbdev's internal implementation does. For DRM,
damage handling needs to be performed after updating a framebuffer. The
damage worker is part of the fb helpers, but the actual update logic only
works with generic fbdev emulation. Separate the two, which also gives
other drivers an option to set their own damage handling if neccessary.
The full-featured I/O helpers can be moved under a shared implementation
and called by all drivers. Patches 15 to 18 resolve these issues.

Patch 19 changes fbdev disablement to work at the level of display
detection. If disabled, generic fbdev emulation will be initialized,
but no display will be detected. It can later be enabled by changing
the parameter in sysfs and plugging in a connector.

Patches 20 to 22 move the generic fbdev emulation into their own source
and header files and clean up the include statements throughout DRM. Many
drivers only call drm_fbdev_generic_setup() and can avoid including other
Linux header files.

Patch 23 is a documentation update.

Built on x86-64, aarch64, arm, ppc64le. Tested with various combinations
of bochs, i915, simpledrm.

v3:
* documentation fixes (Javier)
* rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h}
* keep drm_leak_fbdev_smem in drm_fb_helper.c
* fix several include statements
* rebases
v2:
* fixed commit descriptions (Christian, Sergey)

Thomas Zimmermann (23):
  drm/komeda: Don't set struct drm_driver.lastclose
  drm/mcde: Don't set struct drm_driver.lastclose
  drm/vboxvideo: Don't set struct drm_driver.lastclose
  drm/amdgpu: Don't set struct drm_driver.output_poll_changed
  drm/imx/dcss: Don't set struct drm_driver.output_poll_changed
  drm/ingenic: Don't set struct drm_driver.output_poll_changed
  drm/logicvc: Don't set struct drm_driver.output_poll_changed
  drm/rockchip: Don't set struct drm_driver.output_poll_changed
  drm/panel-ili9341: Include 
  drm/tve200: Include 
  drm/fb-helper: Cleanup include statements in header file
  drm/fb_helper: Rename field fbdev to info in struct drm_fb_helper
  drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info postfix
  drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use _info
postfix
  drm/fb-helper: Disconnect damage worker from update logic
  drm/fb-helper: Call fb_sync in I/O functions
  drm/fb-helper: Perform all fbdev I/O with the same implementation
  drm/fb_helper: Minimize damage-helper overhead
  drm/fb-helper: Always initialize generic fbdev emulation
  drm/fb-helper: Set flag in struct drm_fb_helper for leaking physical
addresses
  drm/fb-helper: Move generic fbdev emulation into separate source file
  drm/fb-helper: Remove unnecessary include statements
  drm/fb-helper: Clarify use of last_close and output_poll_changed

 drivers/gpu/drm/Makefile  |4 +-
 .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|1 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|1 +
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |1 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |1 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |2 -
 .../gpu/drm/arm/display/komeda/komeda_drv.c   |2 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |2 -
 drivers/gpu/drm/arm/hdlcd_crtc.c  |1 -
 drivers/gpu/drm/arm/hdlcd_drv.c   |2 +-
 drivers/gpu/drm/arm/malidp_drv.c  |2 +-
 drivers/gpu/drm/armada/armada_fbdev.c |6 +-
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c   |2 +-
 drivers/gpu/drm/ast/ast_drv.c   

[Intel-gfx] ✓ Fi.CI.BAT: success for Add DP MST DSC support to i915 (rev16)

[Patchwork]

== Series Details ==

Series: Add DP MST DSC support to i915 (rev16)
URL   : https://patchwork.freedesktop.org/series/101492/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12337 -> Patchwork_101492v16


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 29)
--

  Additional (3): fi-kbl-soraka fi-hsw-4770 fi-apl-guc 
  Missing(13): fi-bdw-samus fi-hsw-4200u bat-dg2-8 bat-dg2-9 bat-adlp-6 
bat-adlp-4 fi-ctg-p8600 bat-adln-1 bat-rplp-1 bat-rpls-1 bat-rpls-2 bat-dg2-11 
bat-jsl-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][2] -> [FAIL][3] ([i915#7229])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12337/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

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

  * igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][8] ([i915#7099])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- fi-skl-6700k2:  [PASS][10] -> [INCOMPLETE][11] ([i915#4817])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12337/fi-skl-6700k2/igt@i915_susp...@basic-s3-without-i915.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-skl-6700k2/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271]) +9 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka:   [PASS][16] -> [FAIL][17] ([i915#6298])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12337/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][18] ([fdo#109271]) +13 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101492v16/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][19]

[Intel-gfx] [PATCH RFC v2 0/8] Add KUnit support for i915 driver

[Mauro Carvalho Chehab]

This RFC patch series implement KUnit support for i915 driver,
using the already-existing tests inside i915 selftests.

On this version, mock selftest can now run in qemu with:

$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/i915/selftests

The tests which depends on having a real i915 hardware will be skipped.

All selftests will run on bare metal, by modprobing test-i915 module.

The output can be parsed (with a hack) using kunit.py:

$ (echo "[0.00] TAP version 14"; dmesg)>logs; 
./tools/testing/kunit/kunit.py parse logs
[14:29:06] 
[14:29:06]  i915 mock selftests (18 subtests) =
[14:29:06] [PASSED] mock_sanitycheck
[14:29:06] [PASSED] mock_shmem
[14:29:06] [PASSED] mock_fence
[14:29:06] [PASSED] mock_scatterlist
[14:29:06] [PASSED] mock_syncmap
[14:29:06] [PASSED] mock_uncore
[14:29:06] [PASSED] mock_ring
[14:29:06] [PASSED] mock_engine
[14:29:06] [PASSED] mock_timelines
[14:29:06] [PASSED] mock_requests
[14:29:06] [PASSED] mock_objects
[14:29:06] [PASSED] mock_phys
[14:29:06] [PASSED] mock_dmabuf
[14:29:06] [PASSED] mock_vma
[14:29:06] [PASSED] mock_evict
[14:29:06] [PASSED] mock_gtt
[14:29:06] [PASSED] mock_hugepages
[14:29:06] [PASSED] mock_memory_region
[14:29:06] === [PASSED] i915 mock selftests ===
[14:29:06]  i915 live selftests (36 subtests) =
[14:29:06] [PASSED] live_sanitycheck
[14:29:06] [PASSED] live_uncore
[14:29:06] [PASSED] live_workarounds
[14:29:06] [PASSED] live_gt_engines
[14:29:06] [PASSED] live_gt_timelines
[14:29:06] [PASSED] live_gt_contexts
[14:29:06] [PASSED] live_gt_lrc
[14:29:06] [PASSED] live_gt_mocs
[14:29:06] [PASSED] live_gt_pm
[14:29:06] [PASSED] live_gt_heartbeat
[14:29:06] [PASSED] live_requests
[14:29:06] [PASSED] live_migrate
[14:29:06] [PASSED] live_active
[14:29:06] [PASSED] live_objects
[14:29:06] i915: Performing live_mman selftests with st_random_seed=0x1e5d7be5 
st_timeout=500
[14:29:06] test_i915: Setting dangerous option KUnit live_mman - tainting kernel
[14:29:06] test_i915: Running live_mman on :00:02.0
[14:29:06] Test called without an user context!
[14:29:06] # live_mman: EXPECTATION FAILED at 
drivers/gpu/drm/i915/selftests/i915_kunit.c:110
[14:29:06] Expected ret == 0, but
[14:29:06] ret == -22
[14:29:06] not ok 15 - live_mman
[14:29:06] [FAILED] live_mman
[14:29:06] [PASSED] live_dmabuf
[14:29:06] [PASSED] live_vma
[14:29:06] [PASSED] live_coherency
[14:29:06] [PASSED] live_gtt
[14:29:06] [PASSED] live_gem
[14:29:06] [PASSED] live_evict
[14:29:06] [PASSED] live_hugepages
[14:29:06] [PASSED] live_gem_contexts
[14:29:06] [PASSED] live_client
[14:29:06] [PASSED] live_gem_migrate
[14:29:06] [PASSED] live_reset
[14:29:06] [PASSED] live_memory_region
[14:29:06] [PASSED] live_hangcheck
[14:29:06] [PASSED] live_execlists
[14:29:06] [PASSED] live_ring_submission
[14:29:06] [PASSED] live_perf
[14:29:06] [PASSED] live_slpc
[14:29:06] [PASSED] live_guc
[14:29:06] [PASSED] live_guc_multi_lrc
[14:29:06] [PASSED] live_guc_hang
[14:29:06] [PASSED] live_late_gt_pm
[14:29:06] test_i915: :00:02.0: it is a i915 device.
[14:29:06] # Subtest: i915 live selftests
[14:29:06] 1..36
[14:29:06] # i915 live selftests: pass:35 fail:1 skip:0 total:36
[14:29:06] # Totals: pass:35 fail:1 skip:0 total:36
[14:29:06] not ok 2 - i915 live selftests
[14:29:06] === [FAILED] i915 live selftests ===
[14:29:06] = i915 perf selftests (4 subtests) =
[14:29:06] [PASSED] perf_engine_cs
[14:29:06] [PASSED] perf_request
[14:29:06] [PASSED] perf_migrate
[14:29:06] [PASSED] perf_region
[14:29:06] === [PASSED] i915 perf selftests ===
[14:29:06] 
[14:29:06] Testing complete. Ran 58 tests: passed: 57, failed: 1

It is worth noticing that the mmap tests will fail while running via
KUnit. The reason is that such tests depend on having an user
context allocated at current->mm. While modprobing i915 with
selftests enabled allocates it - this is done by Kernel fork() logic),
modprobing test-i915 doesn't. So, such tests won't run.

We probably need to modify kunit core in order for it to call
mm_alloc() internally before starting the tests.

Comments? 

PS.: the current approach is getting only the final results of the
selftests. I opted for this strategy as we need to support i915 selftests,
as those are used by Intel DRM CI bot. A more intrusive change could
be done in the future, in order to export all tests called via SUBTESTS()
macro.

It also makes sense to add filtering capabilities to the module, as this ends
being needed during development phase, where some tests might fail
on newer hardware.

---
v2:
  - changes outside KUnit module moved to separate patches;
  - added support for running live and perf selftests on bare metal;
  - made the KUnit test logic identical

[Intel-gfx] [PATCH RFC v2 2/8] drm/i915: place selftest preparation on a separate function

[Mauro Carvalho Chehab]

The selftest preparation logic should also be used by KUnit. So,
place it on a separate function and export it.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/i915_selftest.h  |  2 ++
 .../gpu/drm/i915/selftests/i915_selftest.c| 22 ---
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_selftest.h 
b/drivers/gpu/drm/i915/i915_selftest.h
index f54de0499be7..7fab96a42a62 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -44,6 +44,7 @@ struct i915_selftest {
 
 extern struct i915_selftest i915_selftest;
 
+void i915_prepare_selftests(const char *name);
 int i915_mock_selftests(void);
 int i915_live_selftests(struct pci_dev *pdev);
 int i915_perf_selftests(struct pci_dev *pdev);
@@ -111,6 +112,7 @@ int __i915_subtests(const char *caller,
 
 #else /* !IS_ENABLED(CONFIG_DRM_I915_SELFTEST) */
 
+static inline void i915_prepare_selftests(const char *) {};
 static inline int i915_mock_selftests(void) { return 0; }
 static inline int i915_live_selftests(struct pci_dev *pdev) { return 0; }
 static inline int i915_perf_selftests(struct pci_dev *pdev) { return 0; }
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 571c9021bd2c..011f7b1f7ff5 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -129,13 +129,8 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
 }
 
-static int __run_selftests(const char *name,
-  struct selftest *st,
-  unsigned int count,
-  void *data)
+void i915_prepare_selftests(const char *name)
 {
-   int err = 0;
-
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
 
@@ -144,10 +139,21 @@ static int __run_selftests(const char *name,
msecs_to_jiffies_timeout(i915_selftest.timeout_ms) :
MAX_SCHEDULE_TIMEOUT;
 
-   set_default_test_all(st, count);
-
pr_info(DRIVER_NAME ": Performing %s selftests with st_random_seed=0x%x 
st_timeout=%u\n",
name, i915_selftest.random_seed, i915_selftest.timeout_ms);
+}
+EXPORT_SYMBOL_NS_GPL(i915_prepare_selftests, I915_SELFTEST);
+
+static int __run_selftests(const char *name,
+  struct selftest *st,
+  unsigned int count,
+  void *data)
+{
+   int err = 0;
+
+   i915_prepare_selftests(name);
+
+   set_default_test_all(st, count);
 
/* Tests are listed in order in i915_*_selftests.h */
for (; count--; st++) {
-- 
2.38.1

[Intel-gfx] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

[Mauro Carvalho Chehab]

The mmap tests require mm in order to work. Failing to do that
will cause a crash:

[  316.820722] BUG: kernel NULL pointer dereference, address: 00e8
[  316.822517] #PF: supervisor write access in kernel mode
[  316.823430] #PF: error_code(0x0002) - not-present page
[  316.824390] PGD 0 P4D 0
[  316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI
[  316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U  
 N 6.1.0-rc2-drm-266703e6f163+ #14
[  316.827503] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 
06/10/2020
[  316.828633] RIP: 0010:down_write_killable+0x50/0x110
[  316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 
ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00  48 0f 
b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74
[  316.830896] RSP: 0018:c90001eabc58 EFLAGS: 00010246
[  316.832008] RAX:  RBX: 00e8 RCX: 
[  316.833141] RDX: 0001 RSI: 81c94fc9 RDI: 81c94fc9
[  316.834195] RBP: 0158 R08: 0001 R09: 
[  316.835231] R10:  R11: 8883a13350b8 R12: 0002
[  316.836259] R13: 0001 R14: 0010 R15: 00e8
[  316.837237] FS:  () GS:8883a380() 
knlGS:
[  316.838214] CS:  0010 DS:  ES:  CR0: 80050033
[  316.839190] CR2: 00e8 CR3: 02812003 CR4: 00770ef0
[  316.840147] PKRU: 5554
[  316.841099] Call Trace:
[  316.842047]  
[  316.842990]  ? vm_mmap_pgoff+0x78/0x150
[  316.843936]  vm_mmap_pgoff+0x78/0x150
[  316.844884]  igt_mmap_offset+0x178/0x1b9 [i915]
[  316.846119]  __igt_mmap+0xfe/0x680 [i915]

Unfortunately, when KUnit module runs, it doesn't create an
user context, causing mmap tests to fail.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index add5ae56cd89..2c5f93e946b5 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1845,6 +1845,11 @@ int i915_gem_mman_live_selftests(struct drm_i915_private 
*i915)
SUBTEST(igt_mmap_gpu),
};
 
+   if (!current->mm) {
+   pr_err("Test called without an user context!\n");
+   return -EINVAL;
+   }
+
return i915_live_subtests(tests, i915);
 }
 EXPORT_SYMBOL_NS_GPL(i915_gem_mman_live_selftests, I915_SELFTEST);
-- 
2.38.1

[Intel-gfx] [PATCH RFC v2 4/8] drm/i915: add support to run KUnit tests on bare metal

[Mauro Carvalho Chehab]

Add a logic to seek for PCI devices and to run tests on
them, if the tests are willing to run on physical hardware,
instead of using Qemu.

Later patches will add the KUnit tests. So, for now, mark
such functions with __maybe_unused, to avoid build issues
with WERROR.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/selftests/i915_kunit.c | 100 
 1 file changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c 
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 731b84a1fdc3..430610864f6e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -8,9 +8,109 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
+#include "i915_drv.h"
 #include "i915_selftest.h"
 
+#define MAX_PCI_BOARDS 8
+
+/*
+ * PCI selftest support
+ *
+ * It is possible to run tests that demands hardware in bare metal.
+ *
+ * Add a logic to detect and get PCI devices using i915 driver, up to
+ * MAX_PCI_BOARDS devices.
+ */
+
+static int n_boards;
+static struct pci_dev *dev_i915[MAX_PCI_BOARDS];
+static int __maybe_unused i915_pci_init_suite(struct kunit_suite *suite)
+{
+   struct pci_dev *pdev = NULL;
+   int i;
+
+   /* Check for PCI devices with i915 driver */
+   do {
+   /*
+* Let's search all devices at the PCI ID. We could, instead,
+* use include/drm/i915_pciids.h, but that would mean a much
+* more complex code, and won't still warrant that the device
+* was bound to i915 driver. So, let's check the driver's
+* name instead.
+*/
+   pdev = pci_get_device(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pdev);
+   if (pdev) {
+   if (pdev->driver && !strcmp(pdev->driver->name, 
"i915")) {
+   pr_info("%s: it is a i915 device.\n",
+   pci_name(pdev));
+
+   for (i = 0; i < n_boards; i++) {
+   if (pdev == dev_i915[i]) {
+   pci_dev_put(pdev);
+   continue;
+   }
+   }
+   dev_i915[n_boards++] = pdev;
+   if (n_boards >= MAX_PCI_BOARDS)
+   break;
+   } else {
+   pci_dev_put(pdev);
+   }
+   }
+   } while (pdev);
+
+   return 0;
+}
+
+static void __maybe_unused i915_pci_exit_suite(struct kunit_suite *suite)
+{
+   int i;
+
+   for (i = 0; i < n_boards; i++)
+   pci_dev_put(dev_i915[i]);
+
+   n_boards = 0;
+}
+
+static void __maybe_unused run_pci_test(struct kunit *test,
+   int (*f)(struct drm_i915_private *i915))
+{
+   struct drm_i915_private *i915;
+   int i, ret, disable_display;
+
+   if (!n_boards)
+   kunit_skip(test, "runs only on i915 hardware\n");
+
+   for (i = 0; i < n_boards; i++) {
+   i915 = pdev_to_i915(dev_i915[i]);
+
+   cond_resched();
+   if (signal_pending(current))
+   return;
+
+   pr_info("Running %s on %s\n",
+   test->name, pci_name(dev_i915[i]));
+
+   /* FIXME: is it ok to disable_display here? */
+   disable_display = i915->params.disable_display;
+   i915->params.disable_display = 1;
+   ret = f(i915);
+   i915->params.disable_display = disable_display;
+
+   if (ret == -EINTR && !signal_pending(current))
+   ret = 0;
+
+   if (WARN(ret > 0 || ret == -ENOTTY,
+   "%s returned %d, conflicting with selftest's magic 
values!\n",
+   test->name, ret))
+   ret = -EINVAL;
+
+   KUNIT_EXPECT_EQ(test, ret, 0);
+   }
+}
+
 /*
  * Test run logic, similar to what i915 selftest does
  */
-- 
2.38.1

[Intel-gfx] [PATCH RFC v2 1/8] drm/i915: export all selftest functions

[Mauro Carvalho Chehab]

In order to prepare for a new KUnit module that will run
selftests, export all selftest functions to I915_SELFTEST
namespace.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  | 2 ++
 drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c  | 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c| 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 ++
 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c| 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c   | 1 +
 drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 ++
 drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c   | 1 +
 drivers/gpu/drm/i915/gt/selftest_context.c   | 1 +
 drivers/gpu/drm/i915/gt/selftest_engine.c| 1 +
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 ++
 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c  | 1 +
 drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 +
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 ++
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c   | 1 +
 drivers/gpu/drm/i915/gt/selftest_migrate.c   | 2 ++
 drivers/gpu/drm/i915/gt/selftest_mocs.c  | 1 +
 drivers/gpu/drm/i915/gt/selftest_reset.c | 1 +
 drivers/gpu/drm/i915/gt/selftest_ring.c  | 1 +
 drivers/gpu/drm/i915/gt/selftest_ring_submission.c   | 1 +
 drivers/gpu/drm/i915/gt/selftest_slpc.c  | 1 +
 drivers/gpu/drm/i915/gt/selftest_timeline.c  | 2 ++
 drivers/gpu/drm/i915/gt/selftest_workarounds.c   | 1 +
 drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 +
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c| 1 +
 drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c  | 1 +
 drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c  | 1 +
 drivers/gpu/drm/i915/selftests/i915_active.c | 1 +
 drivers/gpu/drm/i915/selftests/i915_gem.c| 1 +
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c  | 2 ++
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 ++
 drivers/gpu/drm/i915/selftests/i915_perf.c   | 1 +
 drivers/gpu/drm/i915/selftests/i915_request.c| 3 +++
 drivers/gpu/drm/i915/selftests/i915_selftest.c   | 2 ++
 drivers/gpu/drm/i915/selftests/i915_sw_fence.c   | 1 +
 drivers/gpu/drm/i915/selftests/i915_syncmap.c| 1 +
 drivers/gpu/drm/i915/selftests/i915_vma.c| 2 ++
 drivers/gpu/drm/i915/selftests/intel_memory_region.c | 3 +++
 drivers/gpu/drm/i915/selftests/intel_uncore.c| 2 ++
 drivers/gpu/drm/i915/selftests/scatterlist.c | 1 +
 42 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 0cb99e75b0bc..7cbd01dbff4c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1948,6 +1948,7 @@ int i915_gem_huge_page_mock_selftests(void)
mock_destroy_device(dev_priv);
return err;
 }
+EXPORT_SYMBOL_NS_GPL(i915_gem_huge_page_mock_selftests, I915_SELFTEST);
 
 int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
 {
@@ -1970,3 +1971,4 @@ int i915_gem_huge_page_live_selftests(struct 
drm_i915_private *i915)
 
return i915_live_subtests(tests, i915);
 }
+EXPORT_SYMBOL_NS_GPL(i915_gem_huge_page_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 9a6a6b5b722b..9f1ff1e783f6 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -763,3 +763,4 @@ int i915_gem_client_blt_live_selftests(struct 
drm_i915_private *i915)
 
return i915_live_subtests(tests, i915);
 }
+EXPORT_SYMBOL_NS_GPL(i915_gem_client_blt_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index a666d7e610f5..1fcbc68c9c0f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -436,3 +436,4 @@ int i915_gem_coherency_live_selftests(struct 
drm_i915_private *i915)
 
return i915_live_subtests(tests, i915);
 }
+EXPORT_SYMBOL_NS_GPL(i915_gem_coherency_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/se

[Intel-gfx] [PATCH RFC v2 7/8] drm/i915: now that all functions are used, remove __maybe_unused

[Mauro Carvalho Chehab]

The PCI-specific KUnit tests that run in bare metal got added,
so we can remove the __maybe_unused from such functions.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/selftests/i915_kunit.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c 
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 6de5d3fa8920..e6dbffe919e6 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -26,7 +26,7 @@
 
 static int n_boards;
 static struct pci_dev *dev_i915[MAX_PCI_BOARDS];
-static int __maybe_unused i915_pci_init_suite(struct kunit_suite *suite)
+static int i915_pci_init_suite(struct kunit_suite *suite)
 {
struct pci_dev *pdev = NULL;
int i;
@@ -64,7 +64,7 @@ static int __maybe_unused i915_pci_init_suite(struct 
kunit_suite *suite)
return 0;
 }
 
-static void __maybe_unused i915_pci_exit_suite(struct kunit_suite *suite)
+static void i915_pci_exit_suite(struct kunit_suite *suite)
 {
int i;
 
@@ -74,8 +74,8 @@ static void __maybe_unused i915_pci_exit_suite(struct 
kunit_suite *suite)
n_boards = 0;
 }
 
-static void __maybe_unused run_pci_test(struct kunit *test,
-   int (*f)(struct drm_i915_private *i915))
+static void run_pci_test(struct kunit *test,
+int (*f)(struct drm_i915_private *i915))
 {
struct drm_i915_private *i915;
int i, ret, disable_display;
-- 
2.38.1

[Intel-gfx] [PATCH RFC v2 3/8] drm/i915: allow running mock selftests via Kunit

[Mauro Carvalho Chehab]

The mock selftests don't require any hardware to run. They can
easily run via kunit with qemu or bare metal.

Add support for it.

With this change, mock selftest can now run in qemu with:

$ ./tools/testing/kunit/kunit.py run --arch=x86_64 \
--kunitconfig=drivers/gpu/drm/i915/selftests
[16:50:24] Configuring KUnit Kernel ...
[16:50:24] Building KUnit Kernel ...
Populating config with:
$ make ARCH=x86_64 O=.kunit olddefconfig
Building with:
$ make ARCH=x86_64 O=.kunit --jobs=8
[16:50:32] Starting KUnit Kernel (1/1)...
[16:50:32] 
Running tests with:
$ qemu-system-x86_64 -nodefaults -m 1024 -kernel 
.kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 
kunit_shutdown=reboot' -no-reboot -nographic -serial stdio
[16:50:33]  i915 mock selftests (18 subtests) =
[16:50:33] [PASSED] mock_sanitycheck
[16:50:33] [PASSED] mock_shmem
[16:50:37] [PASSED] mock_fence
[16:50:38] [PASSED] mock_scatterlist
[16:50:39] [PASSED] mock_syncmap
[16:50:39] [PASSED] mock_uncore
[16:50:39] [PASSED] mock_ring
[16:50:39] [PASSED] mock_engine
[16:50:43] [PASSED] mock_timelines
[16:50:45] [PASSED] mock_requests
[16:50:45] [PASSED] mock_objects
[16:50:45] [PASSED] mock_phys
[16:50:45] [PASSED] mock_dmabuf
[16:50:50] [PASSED] mock_vma
[16:50:51] [PASSED] mock_evict
[16:50:53] [PASSED] mock_gtt
[16:50:54] [PASSED] mock_hugepages
[16:50:55] [PASSED] mock_memory_region
[16:50:55] === [PASSED] i915 mock selftests ===
[16:50:55] 
[16:50:55] Testing complete. Ran 18 tests: passed: 18
[16:50:55] Elapsed time: 31.530s total, 0.003s configuring, 8.512s 
building, 22.974s running

It is also possible to run the tests on a bare metal machine,
and even collect code coverage data with:

$ sudo lcov -z && sudo modprobe test-i915 && sudo rmmod test-i915 &&
  sudo IGT_KERNEL_TREE=~/linux 
~/freedesktop-igt/scripts/code_cov_capture mock_selftest
Auto-detecting gcov kernel support.
Found upstream gcov kernel support at /sys/kernel/debug/gcov
Resetting kernel execution counters
Done.
[627.14] Code coverage wrote to mock_selftest.info

The KTAP and Kernel logs will be similar to:

[  596.382685] # Subtest: i915 mock selftests
[  596.382688] 1..18
[  596.387744] i915: i915_mock_sanitycheck() - ok!
[  596.395423] ok 1 - mock_sanitycheck
[  596.395495] i915: Running shmem_utils_mock_selftests/igt_shmem_basic
[  596.406650] ok 2 - mock_shmem
[  596.406737] i915: Running i915_sw_fence_mock_selftests/test_self
[  596.416868] i915: Running i915_sw_fence_mock_selftests/test_dag
[  596.423220] i915: Running i915_sw_fence_mock_selftests/test_AB
[  596.429585] i915: Running i915_sw_fence_mock_selftests/test_ABC
[  596.435921] i915: Running i915_sw_fence_mock_selftests/test_AB_C
[  596.442293] i915: Running i915_sw_fence_mock_selftests/test_C_AB
[  596.448671] i915: Running i915_sw_fence_mock_selftests/test_chain
[  596.485336] i915: Running i915_sw_fence_mock_selftests/test_ipc
[  596.492984] i915: Running i915_sw_fence_mock_selftests/test_timer
[  602.484395] i915: Running i915_sw_fence_mock_selftests/test_dma_fence
[  603.876315] Asynchronous wait on fence mock:mock:0 timed out 
(hint:fence_notify [i915])
[  603.886148] ok 3 - mock_fence
[  603.886377] i915: Running scatterlist_mock_selftests/igt_sg_alloc
[  604.398052] sg_alloc_table timed out
[  604.401979] i915: Running scatterlist_mock_selftests/igt_sg_trim
[  604.909003] i915_sg_trim timed out
[  604.912850] ok 4 - mock_scatterlist
[  604.912987] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_init
[  604.924092] i915: Running i915_syncmap_mock_selftests/igt_syncmap_one
[  605.430961] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_join_above
[  605.438458] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_join_below
[  605.446670] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_neighbours
[  606.736462] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_compact
[  606.744342] i915: Running 
i915_syncmap_mock_selftests/igt_syncmap_random
[  607.266569] ok 5 - mock_syncmap
[  607.266771] ok 6 - mock_uncore
[  607.271144] i915: Running 
intel_ring_mock_selftests/igt_ring_direction
[  607.281872] ok 7 - mock_ring
[  607.282142] i915: Running 
intel_engine

[Intel-gfx] [PATCH RFC v2 5/8] drm/i915: add live selftests to KUnit

[Mauro Carvalho Chehab]

Now that i915 KUnit has PCI support, add live tests as well.

NOTE: currently, some tests are failing when excecuting via
KUnit. I'll do a further investigation to check why, and if
this patch can be safely merged or not.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/selftests/i915_kunit.c | 35 -
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c 
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 430610864f6e..f5281c866d75 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -177,6 +177,31 @@ static struct kunit_case i915_mock_tests[] = {
 };
 #undef selftest
 
+/*
+ * Suite 2: live selftests
+ */
+
+/* Declare selftest functions */
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);
+#include "i915_live_selftests.h"
+#undef selftest
+
+/* Create selftest functions */
+#define selftest(__x, __y) \
+   static void live_##__x(struct kunit *test) {\
+   run_pci_test(test, __y);\
+   }
+#include "i915_live_selftests.h"
+#undef selftest
+
+/* Fill tests array */
+#define selftest(__x, __y) KUNIT_CASE(live_##__x),
+static struct kunit_case i915_live_tests[] = {
+#include "i915_live_selftests.h"
+   {}
+};
+#undef selftest
+
 /*
  * Declare test suites
  */
@@ -187,9 +212,17 @@ static struct kunit_suite i915_test_suites[] = {
.test_cases = i915_mock_tests,
.init = initialize_i915_selftests,
},
+   {
+   .name = "i915 live selftests",
+   .test_cases = i915_live_tests,
+   .init = initialize_i915_selftests,
+   .suite_init = i915_pci_init_suite,
+   .suite_exit = i915_pci_exit_suite,
+   },
 };
 
-kunit_test_suites(i915_test_suites);
+kunit_test_suites(&i915_test_suites[0],
+ &i915_test_suites[1]);
 
 MODULE_LICENSE("GPL v2");
 MODULE_IMPORT_NS(I915_SELFTEST);
-- 
2.38.1

[Intel-gfx] [PATCH RFC v2 6/8] drm/i915: add perf selftests to KUnit

[Mauro Carvalho Chehab]

Now that i915 KUnit has PCI support, add perf tests as well.

Signed-off-by: Mauro Carvalho Chehab 
---

To avoid mailbombing on a large number of people, only mailing lists were C/C 
on the cover.
See [PATCH RFC v2 0/8] at: 
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/

 drivers/gpu/drm/i915/selftests/i915_kunit.c | 34 -
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c 
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index f5281c866d75..6de5d3fa8920 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -202,6 +202,30 @@ static struct kunit_case i915_live_tests[] = {
 };
 #undef selftest
 
+/*
+ * Suite 3: live selftests
+ */
+
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);
+#include "i915_perf_selftests.h"
+#undef selftest
+
+/* Create selftest functions */
+#define selftest(__x, __y) \
+   static void perf_##__x(struct kunit *test) {\
+   run_pci_test(test, __y);\
+   }
+#include "i915_perf_selftests.h"
+#undef selftest
+
+/* Fill tests array */
+#define selftest(__x, __y) KUNIT_CASE(perf_##__x),
+static struct kunit_case i915_perf_tests[] = {
+#include "i915_perf_selftests.h"
+   {}
+};
+#undef selftest
+
 /*
  * Declare test suites
  */
@@ -219,10 +243,18 @@ static struct kunit_suite i915_test_suites[] = {
.suite_init = i915_pci_init_suite,
.suite_exit = i915_pci_exit_suite,
},
+   {
+   .name = "i915 perf selftests",
+   .test_cases = i915_perf_tests,
+   .init = initialize_i915_selftests,
+   .suite_init = i915_pci_init_suite,
+   .suite_exit = i915_pci_exit_suite,
+   },
 };
 
 kunit_test_suites(&i915_test_suites[0],
- &i915_test_suites[1]);
+ &i915_test_suites[1],
+ &i915_test_suites[2]);
 
 MODULE_LICENSE("GPL v2");
 MODULE_IMPORT_NS(I915_SELFTEST);
-- 
2.38.1

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add DP MST DSC support to i915 (rev16)

[Patchwork]

== Series Details ==

Series: Add DP MST DSC support to i915 (rev16)
URL   : https://patchwork.freedesktop.org/series/101492/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or 
member 'lock' not described in 'i915_perf_stream'

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pps: improve eDP power on flow. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/pps: improve eDP power on flow. (rev3)
URL   : https://patchwork.freedesktop.org/series/110038/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12333_full -> Patchwork_110038v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-iclb6/igt@gem_exec_whis...@basic-contexts-forked-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v3/shard-iclb8/igt@gem_exec_whis...@basic-contexts-forked-all.html

  * igt@kms_cursor_legacy@cursor-vs-flip@toggle:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-skl4/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v3/shard-skl1/igt@kms_cursor_legacy@cursor-vs-f...@toggle.html

  
New tests
-

  New tests have been introduced between CI_DRM_12333_full and 
Patchwork_110038v3_full:

### New IGT tests (1) ###

  * igt@fbdev@pan:
- Statuses : 6 pass(s)
- Exec time: [0.03, 0.07] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [FAIL][48], [PASS][49], [PASS][50], 
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk3/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk6/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk7/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-glk9/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v3/shard-glk1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110038v3/

[Intel-gfx] [PATCH v1] drm/i915/gt: Add sysfs RAPL PL1 interface

[Sujaritha Sundaresan]

Adding the rapl_pl1_freq_mhz sysfs attribute.

Signed-off-by: Sujaritha Sundaresan 
Cc: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 20 ++
 drivers/gpu/drm/i915/gt/intel_rps.c | 44 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  3 ++
 drivers/gpu/drm/i915/i915_reg.h |  4 ++
 4 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 904160952369..e7f00ec252f8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -496,6 +496,17 @@ static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
 static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
 static const struct attribute * const gen6_gt_attrs[]  = GEN6_GT_ATTR;
 
+static ssize_t rapl_pl1_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   u32 rapl_pl1 = intel_rps_read_rapl_pl1_frequency(>->rps);
+
+   return sysfs_emit(buff, "%u\n", rapl_pl1);
+}
+
+
 static ssize_t punit_req_freq_mhz_show(struct device *dev,
   struct device_attribute *attr,
   char *buff)
@@ -534,6 +545,7 @@ struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
.mask = mask__, \
 }
 
+static DEVICE_ATTR_RO(rapl_pl1_freq_mhz);
 static DEVICE_ATTR_RO(punit_req_freq_mhz);
 static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status, 
GT0_PERF_LIMIT_REASONS_MASK);
 static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
@@ -790,12 +802,20 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct 
kobject *kobj)
if (!is_object_gt(kobj))
return;
 
+   ret = sysfs_create_file(kobj, &dev_attr_rapl_pl1_freq_mhz.attr);
+   if (ret)
+   drm_warn(>->i915->drm,
+   "failed to create gt%u rapl_pl1_freq_mhz sysfs(%pe)",
+   gt->info.id, ERR_PTR(ret));
+
+
ret = sysfs_create_file(kobj, &dev_attr_punit_req_freq_mhz.attr);
if (ret)
drm_warn(>->i915->drm,
 "failed to create gt%u punit_req_freq_mhz sysfs (%pe)",
 gt->info.id, ERR_PTR(ret));
 
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 17b40b625e31..0e89b941e3be 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -9,6 +9,7 @@
 
 #include "i915_drv.h"
 #include "i915_irq.h"
+#include "i915_reg.h"
 #include "intel_breadcrumbs.h"
 #include "intel_gt.h"
 #include "intel_gt_clock_utils.h"
@@ -2422,6 +2423,49 @@ bool rps_read_mask_mmio(struct intel_rps *rps,
return rps_read_mmio(rps, reg32) & mask;
 }
 
+u32 intel_rps_read_rapl_pl1(struct intel_rps *rps)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   i915_reg_t rgadr;
+   u32 rapl_pl1;
+
+   if (IS_METEORLAKE(i915)) {
+   rgadr = MTL_RAPL_PL1_FREQ_LIMIT;
+   } else if (IS_XEHPSDV(i915)) {
+   rgadr = XEHPSDV_RAPL_PL1_FREQ_LIMIT;
+   } else {
+   MISSING_CASE(GRAPHICS_VER(i915));
+   rgadr = INVALID_MMIO_REG;
+   }
+
+   if (!i915_mmio_reg_valid(rgadr))
+   rapl_pl1 = 0;
+   else
+   rapl_pl1 = rps_read_mmio(rps, rgadr);
+
+   return rapl_pl1;
+}
+
+u32 intel_rps_get_rapl(struct intel_rps *rps, u32 rapl_pl1)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   u32 rapl = 0;
+
+   if (IS_METEORLAKE(i915) || IS_XEHPSDV(i915))
+   rapl = rapl_pl1 & RAPL_PL1_FREQ_LIMIT_MASK;
+   else
+   MISSING_CASE(GRAPHICS_VER(i915));
+
+   return rapl;
+}
+
+u32 intel_rps_read_rapl_pl1_frequency(struct intel_rps *rps)
+{
+   u32 rapl_freq = intel_rps_get_rapl(rps, intel_rps_read_rapl_pl1(rps));
+
+   return (rapl_freq >> 8) * GT_FREQUENCY_MULTIPLIER;
+}
+
 /* External interface for intel_ips.ko */
 
 static struct drm_i915_private __rcu *ips_mchdev;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 4509dfdc52e0..4adc6aaedba0 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -34,6 +34,7 @@ void intel_rps_mark_interactive(struct intel_rps *rps, bool 
interactive);
 int intel_gpu_freq(struct intel_rps *rps, int val);
 int intel_freq_opcode(struct intel_rps *rps, int val);
 u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat1);
+u32 intel_rps_get_rapl(struct intel_rps *rps, u32 rapl_pl1);
 u32 intel_rps_read_actual_frequency(struct

[Intel-gfx] [PATCH 6/6] drm/i915: Bpp/timeslot calculation fixes for DP MST DSC

[Stanislav Lisovskiy]

Fix intel_dp_dsc_compute_config, previously timeslots parameter
was used in fact not as a timeslots, but more like a ratio
timeslots/64, which of course didn't have any effect for SST DSC,
but causes now issues for MST DSC.
Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp
only for SST DSC case, while for MST case it has been calculated
earlier already with intel_dp_dsc_mst_compute_link_config.
Third we also were wrongly determining sink min bpp/max bpp, those
limites should be intersected with our limits to find common
acceptable bpp's, plus on top of that we should align those with
VESA bpps and only then calculate required timeslots amount.
Some MST hubs started to work only after third change was made.

v2: Make kernel test robot happy(claimed there was unitialzed use,
while there is none)

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 69 ++---
 drivers/gpu/drm/i915/display/intel_dp.h |  3 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 69 +
 3 files changed, 106 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8288a30dbd51..82752b696498 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,9 +716,14 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
*i915,
 * for SST -> TimeSlotsPerMTP is 1,
 * for MST -> TimeSlotsPerMTP has to be calculated
 */
-   bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
-intel_dp_mode_to_fec_clock(mode_clock);
-   drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
+   bits_per_pixel = DIV_ROUND_UP((link_clock * lane_count) * timeslots,
+ intel_dp_mode_to_fec_clock(mode_clock) * 
8);
+
+   drm_dbg_kms(&i915->drm, "Max link bpp is %u for %u timeslots "
+   "total bw %u pixel clock %u\n",
+   bits_per_pixel, timeslots,
+   (link_clock * lane_count * 8),
+   intel_dp_mode_to_fec_clock(mode_clock));
 
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
@@ -1047,7 +1052,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
target_clock,
mode->hdisplay,
bigjoiner,
-   pipe_bpp, 1) >> 4;
+   pipe_bpp, 64) >> 4;
dsc_slice_count =
intel_dp_dsc_get_slice_count(intel_dp,
 target_clock,
@@ -1481,7 +1486,8 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
struct link_config_limits *limits,
-   int timeslots)
+   int timeslots,
+   bool compute_pipe_bpp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
@@ -1496,7 +1502,10 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
 
-   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
+   if (compute_pipe_bpp)
+   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
conn_state->max_requested_bpc);
+   else
+   pipe_bpp = pipe_config->pipe_bpp;
 
if (intel_dp->force_dsc_bpc) {
pipe_bpp = intel_dp->force_dsc_bpc * 3;
@@ -1527,31 +1536,47 @@ int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
} else {
-   u16 dsc_max_output_bpp;
+   u16 dsc_max_output_bpp = 0;
u8 dsc_dp_slice_count;
 
-   dsc_max_output_bpp =
-   intel_dp_dsc_get_output_bpp(dev_priv,
-   pipe_config->port_clock,
-   pipe_config->lane_count,
-   adjusted_mode->crtc_clock,
-   
adjusted_mode->crtc_hdisplay,
-  

[Intel-gfx] [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function

[Stanislav Lisovskiy]

We might to use that function separately from intel_dp_dsc_compute_config
for DP DSC over MST case, because allocating bandwidth in that
case can be a bit more tricky. So in order to avoid code copy-pasta
lets extract this to separate function and reuse it for both SST
and MST cases.

v2: Removed multiple blank lines

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 50 +
 drivers/gpu/drm/i915/display/intel_dp.h |  1 +
 drivers/gpu/drm/i915/display/intel_dp_mst.c |  1 -
 3 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 70f4d6422795..8288a30dbd51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -671,6 +671,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
return 6144 * 8;
 }
 
+u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp, u32 
pipe_bpp)
+{
+   u32 bits_per_pixel = bpp;
+   int i;
+
+   /* Error out if the max bpp is less than smallest allowed valid bpp */
+   if (bits_per_pixel < valid_dsc_bpp[0]) {
+   drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min %u\n",
+   bits_per_pixel, valid_dsc_bpp[0]);
+   return 0;
+   }
+
+   /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs 
*/
+   if (DISPLAY_VER(i915) >= 13) {
+   bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
+   } else {
+   /* Find the nearest match in the array of known BPPs from VESA 
*/
+   for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
+   if (bits_per_pixel < valid_dsc_bpp[i + 1])
+   break;
+   }
+   drm_dbg_kms(&i915->drm, "Set dsc bpp from %d to VESA %d\n",
+   bits_per_pixel, valid_dsc_bpp[i]);
+
+   bits_per_pixel = valid_dsc_bpp[i];
+   }
+
+   return bits_per_pixel;
+}
+
 u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
u32 link_clock, u32 lane_count,
u32 mode_clock, u32 mode_hdisplay,
@@ -679,7 +709,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
*i915,
u32 timeslots)
 {
u32 bits_per_pixel, max_bpp_small_joiner_ram;
-   int i;
 
/*
 * Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
@@ -712,24 +741,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private 
*i915,
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
}
 
-   /* Error out if the max bpp is less than smallest allowed valid bpp */
-   if (bits_per_pixel < valid_dsc_bpp[0]) {
-   drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min %u\n",
-   bits_per_pixel, valid_dsc_bpp[0]);
-   return 0;
-   }
-
-   /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs 
*/
-   if (DISPLAY_VER(i915) >= 13) {
-   bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
-   } else {
-   /* Find the nearest match in the array of known BPPs from VESA 
*/
-   for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
-   if (bits_per_pixel < valid_dsc_bpp[i + 1])
-   break;
-   }
-   bits_per_pixel = valid_dsc_bpp[i];
-   }
+   bits_per_pixel = intel_dp_dsc_nearest_vesa_bpp(i915, bits_per_pixel, 
pipe_bpp);
 
/*
 * Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
b/drivers/gpu/drm/i915/display/intel_dp.h
index c6539a6915e9..0fe10d93b75c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
 }
 
 u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp, u32 
pipe_bpp);
 
 void intel_ddi_update_pipe(struct intel_atomic_state *state,
   struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 61b2bd504e80..8442eea27a57 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -114,7 +114,6 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct 
intel_encoder *encoder,
return slots;
 }
 
-
 static int intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
struct drm_connector_state 
*conn_state,
-- 
2.37.3

Re: [Intel-gfx] [PATCH] drm/i915/selftest: Bump up sample period for busy stats selftest

[Tvrtko Ursulin]

On 03/11/2022 00:11, Umesh Nerlige Ramappa wrote:

Engine busyness samples around a 10ms period is failing with busyness
ranging approx. from 87% to 115%. The expected range is +/- 5% of the
sample period.

When determining busyness of active engine, the GuC based engine
busyness implementation relies on a 64 bit timestamp register read. The
latency incurred by this register read causes the failure.

On DG1, when the test fails, the observed latencies range from 900us -
1.5ms.


Do I read this right - that the latency of a 64 bit timestamp register 
read is 0.9 - 1.5ms? That would be the read in guc_update_pm_timestamp?


Regards,

Tvrtko


One solution tried was to reduce the latency between reg read and
CPU timestamp capture, but such optimization does not add value to user
since the CPU timestamp obtained here is only used for (1) selftest and
(2) i915 rps implementation specific to execlist scheduler. Also, this
solution only reduces the frequency of failure and does not eliminate
it.

In order to make the selftest more robust and account for such
latencies, increase the sample period to 100 ms.

Signed-off-by: Umesh Nerlige Ramappa 
---
  drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c 
b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 0dcb3ed44a73..87c94314cf67 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -317,7 +317,7 @@ static int live_engine_busy_stats(void *arg)
ENGINE_TRACE(engine, "measuring busy time\n");
preempt_disable();
de = intel_engine_get_busy_time(engine, &t[0]);
-   mdelay(10);
+   mdelay(100);
de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
preempt_enable();
dt = ktime_sub(t[1], t[0]);

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftest: Bump up sample period for busy stats selftest

[Patchwork]

== Series Details ==

Series: drm/i915/selftest: Bump up sample period for busy stats selftest
URL   : https://patchwork.freedesktop.org/series/110454/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12333_full -> Patchwork_110454v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_12333_full and 
Patchwork_110454v1_full:

### New IGT tests (1) ###

  * igt@fbdev@pan:
- Statuses : 6 pass(s)
- Exec time: [0.03, 0.07] s

  

Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-apl:  ([PASS][1], [PASS][2], [PASS][3], [FAIL][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]) ([i915#4386]) -> ([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], [PASS][50])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl2/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl3/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl7/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12333/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl8/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl1/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl2/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl2/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl2/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl2/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl3/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl3/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110454v1/shard-apl3/boot.html
   [41]: 
https

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Factor out function to get/put AUX_IO power for main link

[Imre Deak]

On Wed, Nov 02, 2022 at 09:02:41PM +0200, Jani Nikula wrote:
> On Wed, 02 Nov 2022, Imre Deak  wrote:
> > Factor out functions to get/put the AUX_IO power domain for the main
> > link on DDI ports.
> >
> > While at it clarify the corresponding code comment.
> >
> > No functional change.
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c | 84 ++--
> >  1 file changed, 51 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 00b577a5b9a76..7453772d2073d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -846,26 +846,63 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > *encoder,
> >  }
> >  
> >  static enum intel_display_power_domain
> > -intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port)
> > +intel_ddi_main_link_aux_domain(struct intel_digital_port *dig_port,
> > +  const struct intel_crtc_state *crtc_state)
> >  {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > +   enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> >  
> > -   /* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
> > +   /*
> > +* ICL+ HW requires corresponding AUX IOs to be powered up for PSR with
> >  * DC states enabled at the same time, while for driver initiated AUX
> >  * transfers we need the same AUX IOs to be powered but with DC states
> > -* disabled. Accordingly use the AUX power domain here which leaves DC
> > -* states enabled.
> > -* However, for non-A AUX ports the corresponding non-EDP transcoders
> > -* would have already enabled power well 2 and DC_OFF. This means we can
> > -* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
> > -* specific AUX_IO reference without powering up any extra wells.
> > -* Note that PSR is enabled only on Port A even though this function
> > -* returns the correct domain for other ports too.
> > +* disabled. Accordingly use the AUX_IO_ power domain here which
> > +* leaves DC states enabled.
> > +*
> > +* Before MTL all DP ports and HDMI ports on TypeC PHYs also require
> > +* AUX IO to be enabled, but all these require DC_OFF to be enabled as
> > +* well, so we can acquire a wider AUX_ power domain reference
> > +* instead of a specific AUX_IO_ reference without powering up any
> > +* extra wells.
> >  */
> > if (intel_dp_is_edp(&dig_port->dp))
> > return intel_display_power_aux_io_domain(i915, 
> > dig_port->aux_ch);
> > -   else
> > +   else if (intel_crtc_has_dp_encoder(crtc_state) ||
> > +intel_phy_is_tc(i915, phy))
> > return intel_aux_power_domain(dig_port);
> > +   else
> > +   return POWER_DOMAIN_INVALID;
> > +}
> > +
> > +static void
> > +get_aux_power_for_main_link(struct intel_digital_port *dig_port,
> > +   const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > +   enum intel_display_power_domain domain =
> > +   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
> > +
> > +   drm_WARN_ON(&i915->drm, dig_port->aux_wakeref);
> > +
> > +   if (domain == POWER_DOMAIN_INVALID)
> > +   return;
> > +
> > +   dig_port->aux_wakeref = intel_display_power_get(i915, domain);
> > +}
> > +
> > +static void
> > +put_aux_power_for_main_link(struct intel_digital_port *dig_port,
> > +   const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > +   intel_wakeref_t wf = fetch_and_zero(&dig_port->aux_wakeref);
> > +   enum intel_display_power_domain domain =
> > +   intel_ddi_main_link_aux_domain(dig_port, crtc_state);
> > +
> > +   if (!wf)
> > +   return;
> > +
> > +   intel_display_power_put(i915, domain, wf);
> >  }
> 
> Nitpick, I think foo_get()/foo_put() are much more common in the driver
> than get_foo()/put_foo().

Ok, can rename these.

> >  static void intel_ddi_get_power_domains(struct intel_encoder *encoder,
> > @@ -873,7 +910,6 @@ static void intel_ddi_get_power_domains(struct 
> > intel_encoder *encoder,
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_digital_port *dig_port;
> > -   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> >  
> > /*
> >  * TODO: Add support for MST encoders. Atm, the following should never
> > @@ -892,17 +928,7 @@ static void intel_ddi_get_power_domains(struct 
> > intel_encoder *encoder,
> >
> > dig_port->ddi_io_power_domain);
> > }
> >  
> > -   /*
> > -* AUX power is only needed for (e)DP mode, and for HDMI mode on TC
> > -* ports.
> >

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Allocate power domain set wakerefs dynamically

[Imre Deak]

On Wed, Nov 02, 2022 at 08:57:21PM +0200, Jani Nikula wrote:
> On Wed, 02 Nov 2022, Imre Deak  wrote:
> > Since the intel_display_power_domain_set struct, currently its current
> > size close 1kB, can be allocated on the stack, it's better to allocate
> > the per-domain wakeref pointer array - used for debugging - within the
> > struct dynamically, so do this.
> >
> > The memory freeing is guaranteed by the fact that the acquired domain
> > references tracked by struct can't be leaked either.
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  .../drm/i915/display/intel_display_power.c| 61 ---
> >  .../drm/i915/display/intel_display_power.h|  2 +-
> >  2 files changed, 53 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 4c1de91e56ff9..e2da91c2a9638 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -830,19 +830,58 @@ void intel_display_power_put_unchecked(struct 
> > drm_i915_private *dev_priv,
> >  }
> >  #endif
> >  
> > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > +static intel_wakeref_t *
> > +get_debug_wakerefs(struct drm_i915_private *i915,
> > +  struct intel_display_power_domain_set *power_domain_set)
> > +{
> > +   if (power_domain_set->wakerefs)
> > +   return power_domain_set->wakerefs;
> > +
> > +   power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> > +
> > sizeof(*power_domain_set->wakerefs),
> > +GFP_KERNEL);
> > +
> > +   drm_WARN_ON_ONCE(&i915->drm, !power_domain_set->wakerefs);
> 
> The rule of thumb is not to warn or log on allocation failures.

Ok, will drop this.

> 
> > +
> > +   return power_domain_set->wakerefs;
> > +}
> > +
> > +static void
> > +free_empty_debug_wakerefs(struct intel_display_power_domain_set 
> > *power_domain_set)
> > +{
> > +   if (power_domain_set->wakerefs &&
> > +   bitmap_empty(power_domain_set->mask.bits, POWER_DOMAIN_NUM))
> > +   kfree(fetch_and_zero(&power_domain_set->wakerefs));
> 
> FWIW, I'm really not happy about fetch_and_zero() or its use anywhere. I
> kind of get the point, but the impression of any kind of atomicity the
> naming gives is totally misleading. And it's our own thing in
> i915_utils.h, and not a global thing like the name suggests.

Ok, here zeroing the pointer separately is clearer, will do that. For
intel_wakeref_t pointers fetch_and_zero() denotes that the ownership of
the reference is moved, which should never happen with a simple copy to
another pointer. Imo for that the use of it is justified.

> > +}
> > +#else
> > +static intel_wakeref_t *
> > +get_debug_wakerefs(struct drm_i915_private *i915,
> > +  struct intel_display_power_domain_set *power_domain_set)
> > +{
> > +   return NULL;
> > +}
> > +
> > +static void
> > +free_empty_debug_wakerefs(struct intel_display_power_domain_set 
> > *power_domain_set)
> > +{
> > +}
> > +#endif
> 
> get/free is an odd pairing of names.
> 
> > +
> >  void
> >  intel_display_power_get_in_set(struct drm_i915_private *i915,
> >struct intel_display_power_domain_set 
> > *power_domain_set,
> >enum intel_display_power_domain domain)
> >  {
> > intel_wakeref_t __maybe_unused wf;
> > +   intel_wakeref_t *debug_wakerefs = get_debug_wakerefs(i915, 
> > power_domain_set);
> >  
> > drm_WARN_ON(&i915->drm, test_bit(domain, power_domain_set->mask.bits));
> >  
> > wf = intel_display_power_get(i915, domain);
> > -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> > -   power_domain_set->wakerefs[domain] = wf;
> > -#endif
> > +   if (debug_wakerefs)
> > +   debug_wakerefs[domain] = wf;
> > +
> 
> If you abstracted setting the debug wakeref for a domain, it could
> handle the allocation internally without any of the local vars etc.
> here. And it would only be a single line in the entire function.

Things here could be simplified by abstracting adding both the domain
and the wakeref to power_domain_set, can do that (calling
add_domain_to_set() here and remove_domain_from_set() in the *_put()
functions).

> 
> > set_bit(domain, power_domain_set->mask.bits);
> >  }
> >  
> > @@ -852,6 +891,7 @@ intel_display_power_get_in_set_if_enabled(struct 
> > drm_i915_private *i915,
> >   enum intel_display_power_domain 
> > domain)
> >  {
> > intel_wakeref_t wf;
> > +   intel_wakeref_t *debug_wakerefs = get_debug_wakerefs(i915, 
> > power_domain_set);
> >  
> > drm_WARN_ON(&i915->drm, test_bit(domain, power_domain_set->mask.bits));
> >  
> > @@ -859,9 +899,9 @@ intel_display_power_get_in_set_if_enabled(struct 
> > drm_i915_private *i915,
> > if (!wf)
> > return false;
> >  
> > -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Don't deadlock busyness stats vs reset

[Tvrtko Ursulin]

On 02/11/2022 19:21, john.c.harri...@intel.com wrote:

From: John Harrison 

The engine busyness stats has a worker function to do things like
64bit extend the 32bit hardware counters. The GuC's reset prepare
function flushes out this worker function to ensure no corruption
happens during the reset. Unforunately, the worker function has an
infinite wait for active resets to finish before doing its work. Thus
a deadlock would occur if the worker function had actually started
just as the reset starts.

The function being used to lock the reset-in-progress mutex is called
intel_gt_reset_trylock(). However, as noted it does not follow
standard 'trylock' conventions and exit if already locked. So rename
the current _trylock function to intel_gt_reset_lock_interruptible(),
which is the behaviour it actually provides. In addition, add a new
implementation of _trylock and call that from the busyness stats
worker instead.

v2: Rename existing trylock to interruptible rather than trying to
preserve the existing (confusing) naming scheme (review comments from
Tvrtko).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  2 +-
  drivers/gpu/drm/i915/gt/intel_reset.c  | 18 --
  drivers/gpu/drm/i915/gt/intel_reset.h  |  1 +
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c  |  4 +++-
  4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index e63329bc80659..c29efdef8313a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -330,7 +330,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
if (ret)
goto err_rpm;
  
-	ret = intel_gt_reset_trylock(ggtt->vm.gt, &srcu);

+   ret = intel_gt_reset_lock_interruptible(ggtt->vm.gt, &srcu);
if (ret)
goto err_pages;
  
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c

index 3159df6cdd492..24736ebee17c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1407,15 +1407,19 @@ void intel_gt_handle_error(struct intel_gt *gt,
intel_runtime_pm_put(gt->uncore->rpm, wakeref);
  }
  
-int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)

+static int _intel_gt_reset_lock(struct intel_gt *gt, int *srcu, bool retry)
  {
might_lock(>->reset.backoff_srcu);
-   might_sleep();
+   if (retry)
+   might_sleep();
  
  	rcu_read_lock();

while (test_bit(I915_RESET_BACKOFF, >->reset.flags)) {
rcu_read_unlock();
  
+		if (!retry)

+   return -EBUSY;
+
if (wait_event_interruptible(gt->reset.queue,
 !test_bit(I915_RESET_BACKOFF,
   >->reset.flags)))
@@ -1429,6 +1433,16 @@ int intel_gt_reset_trylock(struct intel_gt *gt, int 
*srcu)
return 0;
  }
  
+int intel_gt_reset_trylock(struct intel_gt *gt, int *srcu)

+{
+   return _intel_gt_reset_lock(gt, srcu, false);
+}
+
+int intel_gt_reset_lock_interruptible(struct intel_gt *gt, int *srcu)
+{
+   return _intel_gt_reset_lock(gt, srcu, true);
+}
+
  void intel_gt_reset_unlock(struct intel_gt *gt, int tag)
  __releases(>->reset.backoff_srcu)
  {
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h 
b/drivers/gpu/drm/i915/gt/intel_reset.h
index adc734e673870..25c975b6e8fc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -39,6 +39,7 @@ int __intel_engine_reset_bh(struct intel_engine_cs *engine,
  void __i915_request_reset(struct i915_request *rq, bool guilty);
  
  int __must_check intel_gt_reset_trylock(struct intel_gt *gt, int *srcu);

+int __must_check intel_gt_reset_lock_interruptible(struct intel_gt *gt, int 
*srcu);
  void intel_gt_reset_unlock(struct intel_gt *gt, int tag);
  
  void intel_gt_set_wedged(struct intel_gt *gt);

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 941613be3b9dd..92e514061d20b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1401,7 +1401,9 @@ static void guc_timestamp_ping(struct work_struct *wrk)
  
  	/*

 * Synchronize with gt reset to make sure the worker does not
-* corrupt the engine/guc stats.
+* corrupt the engine/guc stats. NB: can't actually block waiting
+* for a reset to complete as the reset requires flushing out
+* this worker thread if started. So waiting would deadlock.
 */
ret = intel_gt_reset_trylock(gt, &srcu);
if (ret)


LGTM but I don't remember fully how ping worker and reset interact so 
I'll let Umesh r-b. Like is it okay to skip the ping or we'd need to 
re-schedule it ASAP due wrap issues? Mayb

Re: [Intel-gfx] [v3] drm/i915/pps: improve eDP power on flow

[Lee, Shawn C]

On Thursday, November 3, 2022 7:00 PM, Jani Nikula 
 wrote:
>On Thu, 03 Nov 2022, Lee Shawn C  wrote:
>> After i915 dirver initialized, a panel power off cycle delay always 
>> append before turn eDP on. If eDP display did not power on before. 
>> With this change, power off duration might longer than power cycle 
>> delay. So driver can save power cycle delay to speed up driver 
>> initialization time.
>>
>> v2: fix commit messages
>> v3: refine panel_power_off_time default value and modify
>> commit messages
>>
>> Cc: Shankar Uma 
>> Cc: Jani Nikula 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Lee Shawn C 
>> ---
>>  drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
>> b/drivers/gpu/drm/i915/display/intel_pps.c
>> index 21944f5bf3a8..a394bb1c92d0 100644
>> --- a/drivers/gpu/drm/i915/display/intel_pps.c
>> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
>> @@ -1098,7 +1098,7 @@ bool intel_pps_have_panel_power_or_vdd(struct 
>> intel_dp *intel_dp)
>>  
>>  static void pps_init_timestamps(struct intel_dp *intel_dp)  {
>> -intel_dp->pps.panel_power_off_time = ktime_get_boottime();
>> +intel_dp->pps.panel_power_off_time = 0;
>
>So this is just copy-paste from [1] where we discuss the problems with this 
>approach, specifically module reload ignoring the power off time.
>Why would you post this without even mentioning the problem?
>

OK, we will stop commit any patch until we have proper solution. Could you 
please share your opinion about next step? Thanks!

Best regards,
Shawn

>
>BR,
>Jani.
>
>
>[1] https://gitlab.freedesktop.org/drm/intel/-/issues/7417#note_1619118
>
>>  intel_dp->pps.last_power_on = jiffies;
>>  intel_dp->pps.last_backlight_off = jiffies;  }
>
>--
>Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915/module_load: restore gem_sanitycheck for discrete

[Das, Nirmoy]

Reviewed-by: Nirmoy Das 

On 11/3/2022 12:10 PM, Das, Nirmoy wrote:

Reviewed-by: nirmoy@intel.com

On 11/2/2022 4:05 PM, Matthew Auld wrote:

This looks to be recently broken in: 5389b3f3
("tests/i915/i915_module_load: Use GEM_BUSY instead of SET_CACHE for
sanity check").

Which fails on discrete platforms, since we switched over to the
gem_busy ioctl, from the set_caching ioctl, which no longer gives
-ENODEV as the expected error.

Signed-off-by: Matthew Auld 
Cc: Janga Rahul Kumar 
Cc: Priyanka Dandamudi 
---
  tests/i915/i915_module_load.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/i915/i915_module_load.c 
b/tests/i915/i915_module_load.c

index eebb3167..d3a86b11 100644
--- a/tests/i915/i915_module_load.c
+++ b/tests/i915/i915_module_load.c
@@ -228,7 +228,7 @@ static void gem_sanitycheck(void)
  {
  struct drm_i915_gem_busy args = {};
  int i915 = __drm_open_driver(DRIVER_INTEL);
-    int expected = gem_has_lmem(i915) ? -ENODEV : -ENOENT;
+    int expected = -ENOENT;
  int err;
    err = 0;

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915/module_load: restore gem_sanitycheck for discrete

[Das, Nirmoy]

Reviewed-by: nirmoy@intel.com

On 11/2/2022 4:05 PM, Matthew Auld wrote:

This looks to be recently broken in: 5389b3f3
("tests/i915/i915_module_load: Use GEM_BUSY instead of SET_CACHE for
sanity check").

Which fails on discrete platforms, since we switched over to the
gem_busy ioctl, from the set_caching ioctl, which no longer gives
-ENODEV as the expected error.

Signed-off-by: Matthew Auld 
Cc: Janga Rahul Kumar 
Cc: Priyanka Dandamudi 
---
  tests/i915/i915_module_load.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/i915/i915_module_load.c b/tests/i915/i915_module_load.c
index eebb3167..d3a86b11 100644
--- a/tests/i915/i915_module_load.c
+++ b/tests/i915/i915_module_load.c
@@ -228,7 +228,7 @@ static void gem_sanitycheck(void)
  {
struct drm_i915_gem_busy args = {};
int i915 = __drm_open_driver(DRIVER_INTEL);
-   int expected = gem_has_lmem(i915) ? -ENODEV : -ENOENT;
+   int expected = -ENOENT;
int err;
  
  	err = 0;

Re: [Intel-gfx] [v3] drm/i915/pps: improve eDP power on flow

[Jani Nikula]

On Thu, 03 Nov 2022, Lee Shawn C  wrote:
> After i915 dirver initialized, a panel power off cycle delay
> always append before turn eDP on. If eDP display did not
> power on before. With this change, power off duration might
> longer than power cycle delay. So driver can save power cycle
> delay to speed up driver initialization time.
>
> v2: fix commit messages
> v3: refine panel_power_off_time default value and modify
> commit messages
>
> Cc: Shankar Uma 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 21944f5bf3a8..a394bb1c92d0 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1098,7 +1098,7 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp 
> *intel_dp)
>  
>  static void pps_init_timestamps(struct intel_dp *intel_dp)
>  {
> - intel_dp->pps.panel_power_off_time = ktime_get_boottime();
> + intel_dp->pps.panel_power_off_time = 0;

So this is just copy-paste from [1] where we discuss the problems with
this approach, specifically module reload ignoring the power off
time. Why would you post this without even mentioning the problem?


BR,
Jani.


[1] https://gitlab.freedesktop.org/drm/intel/-/issues/7417#note_1619118

>   intel_dp->pps.last_power_on = jiffies;
>   intel_dp->pps.last_backlight_off = jiffies;
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center