All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: "Chris Wilson" <chris.p.wilson@intel.com>,
	"Bruce Chang" <yu.bruce.chang@intel.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"John Harrison" <John.C.Harrison@intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Matt Roper" <matthew.d.roper@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tejas Upadhyay" <tejaskumarx.surendrakumar.upadhyay@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Umesh Nerlige Ramappa" <umesh.nerlige.ramappa@intel.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	"Mika Kuoppala" <mika.kuoppala@linux.intel.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH v3 1/2] drm/i915/gt: Serialize GRDOM access between multiple engine resets
Date: Wed, 6 Jul 2022 12:51:31 +0200	[thread overview]
Message-ID: <YsVpM1f86FAIEO8i@alfio.lan> (raw)
In-Reply-To: <ccc54757d89d38af35e5c5885edfb980c7b227f6.1656921701.git.mchehab@kernel.org>

Hi Mauro and Chris,

On Mon, Jul 04, 2022 at 09:09:28AM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson <chris.p.wilson@intel.com>
> 
> Don't allow two engines to be reset in parallel, as they would both
> try to select a reset bit (and send requests to common registers)
> and wait on that register, at the same time. Serialize control of
> the reset requests/acks using the uncore->lock, which will also ensure
> that no other GT state changes at the same time as the actual reset.
> 
> Cc: stable@vger.kernel.org # Up to 4.4
> Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@intel.com>
> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

sorry for the delay but I wanted to understand what has been
agreed between you and Tvrtko about the Cc'ing the stable list.

Anyway, I confirm my review here.

Andi

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
> See [PATCH v3 0/2] at: https://lore.kernel.org/all/cover.1656921701.git.mchehab@kernel.org/
> 
>  drivers/gpu/drm/i915/gt/intel_reset.c | 37 ++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index a5338c3fde7a..c68d36fb5bbd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -300,9 +300,9 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
>  	return err;
>  }
>  
> -static int gen6_reset_engines(struct intel_gt *gt,
> -			      intel_engine_mask_t engine_mask,
> -			      unsigned int retry)
> +static int __gen6_reset_engines(struct intel_gt *gt,
> +				intel_engine_mask_t engine_mask,
> +				unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	u32 hw_mask;
> @@ -321,6 +321,20 @@ static int gen6_reset_engines(struct intel_gt *gt,
>  	return gen6_hw_domain_reset(gt, hw_mask);
>  }
>  
> +static int gen6_reset_engines(struct intel_gt *gt,
> +			      intel_engine_mask_t engine_mask,
> +			      unsigned int retry)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +	ret = __gen6_reset_engines(gt, engine_mask, retry);
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
> +	return ret;
> +}
> +
>  static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct intel_engine_cs *engine)
>  {
>  	int vecs_id;
> @@ -487,9 +501,9 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
>  	rmw_clear_fw(uncore, sfc_lock.lock_reg, sfc_lock.lock_bit);
>  }
>  
> -static int gen11_reset_engines(struct intel_gt *gt,
> -			       intel_engine_mask_t engine_mask,
> -			       unsigned int retry)
> +static int __gen11_reset_engines(struct intel_gt *gt,
> +				 intel_engine_mask_t engine_mask,
> +				 unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	intel_engine_mask_t tmp;
> @@ -583,8 +597,11 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	struct intel_engine_cs *engine;
>  	const bool reset_non_ready = retry >= 1;
>  	intel_engine_mask_t tmp;
> +	unsigned long flags;
>  	int ret;
>  
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +
>  	for_each_engine_masked(engine, gt, engine_mask, tmp) {
>  		ret = gen8_engine_reset_prepare(engine);
>  		if (ret && !reset_non_ready)
> @@ -612,17 +629,19 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	 * This is best effort, so ignore any error from the initial reset.
>  	 */
>  	if (IS_DG2(gt->i915) && engine_mask == ALL_ENGINES)
> -		gen11_reset_engines(gt, gt->info.engine_mask, 0);
> +		__gen11_reset_engines(gt, gt->info.engine_mask, 0);
>  
>  	if (GRAPHICS_VER(gt->i915) >= 11)
> -		ret = gen11_reset_engines(gt, engine_mask, retry);
> +		ret = __gen11_reset_engines(gt, engine_mask, retry);
>  	else
> -		ret = gen6_reset_engines(gt, engine_mask, retry);
> +		ret = __gen6_reset_engines(gt, engine_mask, retry);
>  
>  skip_reset:
>  	for_each_engine_masked(engine, gt, engine_mask, tmp)
>  		gen8_engine_reset_cancel(engine);
>  
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
>  	return ret;
>  }
>  
> -- 
> 2.36.1

WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Chris Wilson" <chris.p.wilson@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"David Airlie" <airlied@linux.ie>,
	"Umesh Nerlige Ramappa" <umesh.nerlige.ramappa@intel.com>,
	dri-devel@lists.freedesktop.org,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	linux-kernel@vger.kernel.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Mika Kuoppala" <mika.kuoppala@linux.intel.com>,
	"Bruce Chang" <yu.bruce.chang@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	stable@vger.kernel.org,
	"Tejas Upadhyay" <tejaskumarx.surendrakumar.upadhyay@intel.com>,
	intel-gfx@lists.freedesktop.org,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [PATCH v3 1/2] drm/i915/gt: Serialize GRDOM access between multiple engine resets
Date: Wed, 6 Jul 2022 12:51:31 +0200	[thread overview]
Message-ID: <YsVpM1f86FAIEO8i@alfio.lan> (raw)
In-Reply-To: <ccc54757d89d38af35e5c5885edfb980c7b227f6.1656921701.git.mchehab@kernel.org>

Hi Mauro and Chris,

On Mon, Jul 04, 2022 at 09:09:28AM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson <chris.p.wilson@intel.com>
> 
> Don't allow two engines to be reset in parallel, as they would both
> try to select a reset bit (and send requests to common registers)
> and wait on that register, at the same time. Serialize control of
> the reset requests/acks using the uncore->lock, which will also ensure
> that no other GT state changes at the same time as the actual reset.
> 
> Cc: stable@vger.kernel.org # Up to 4.4
> Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@intel.com>
> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

sorry for the delay but I wanted to understand what has been
agreed between you and Tvrtko about the Cc'ing the stable list.

Anyway, I confirm my review here.

Andi

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
> See [PATCH v3 0/2] at: https://lore.kernel.org/all/cover.1656921701.git.mchehab@kernel.org/
> 
>  drivers/gpu/drm/i915/gt/intel_reset.c | 37 ++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index a5338c3fde7a..c68d36fb5bbd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -300,9 +300,9 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
>  	return err;
>  }
>  
> -static int gen6_reset_engines(struct intel_gt *gt,
> -			      intel_engine_mask_t engine_mask,
> -			      unsigned int retry)
> +static int __gen6_reset_engines(struct intel_gt *gt,
> +				intel_engine_mask_t engine_mask,
> +				unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	u32 hw_mask;
> @@ -321,6 +321,20 @@ static int gen6_reset_engines(struct intel_gt *gt,
>  	return gen6_hw_domain_reset(gt, hw_mask);
>  }
>  
> +static int gen6_reset_engines(struct intel_gt *gt,
> +			      intel_engine_mask_t engine_mask,
> +			      unsigned int retry)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +	ret = __gen6_reset_engines(gt, engine_mask, retry);
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
> +	return ret;
> +}
> +
>  static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct intel_engine_cs *engine)
>  {
>  	int vecs_id;
> @@ -487,9 +501,9 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
>  	rmw_clear_fw(uncore, sfc_lock.lock_reg, sfc_lock.lock_bit);
>  }
>  
> -static int gen11_reset_engines(struct intel_gt *gt,
> -			       intel_engine_mask_t engine_mask,
> -			       unsigned int retry)
> +static int __gen11_reset_engines(struct intel_gt *gt,
> +				 intel_engine_mask_t engine_mask,
> +				 unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	intel_engine_mask_t tmp;
> @@ -583,8 +597,11 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	struct intel_engine_cs *engine;
>  	const bool reset_non_ready = retry >= 1;
>  	intel_engine_mask_t tmp;
> +	unsigned long flags;
>  	int ret;
>  
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +
>  	for_each_engine_masked(engine, gt, engine_mask, tmp) {
>  		ret = gen8_engine_reset_prepare(engine);
>  		if (ret && !reset_non_ready)
> @@ -612,17 +629,19 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	 * This is best effort, so ignore any error from the initial reset.
>  	 */
>  	if (IS_DG2(gt->i915) && engine_mask == ALL_ENGINES)
> -		gen11_reset_engines(gt, gt->info.engine_mask, 0);
> +		__gen11_reset_engines(gt, gt->info.engine_mask, 0);
>  
>  	if (GRAPHICS_VER(gt->i915) >= 11)
> -		ret = gen11_reset_engines(gt, engine_mask, retry);
> +		ret = __gen11_reset_engines(gt, engine_mask, retry);
>  	else
> -		ret = gen6_reset_engines(gt, engine_mask, retry);
> +		ret = __gen6_reset_engines(gt, engine_mask, retry);
>  
>  skip_reset:
>  	for_each_engine_masked(engine, gt, engine_mask, tmp)
>  		gen8_engine_reset_cancel(engine);
>  
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
>  	return ret;
>  }
>  
> -- 
> 2.36.1

WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: "Chris Wilson" <chris.p.wilson@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"David Airlie" <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	linux-kernel@vger.kernel.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	stable@vger.kernel.org,
	"Tejas Upadhyay" <tejaskumarx.surendrakumar.upadhyay@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Serialize GRDOM access between multiple engine resets
Date: Wed, 6 Jul 2022 12:51:31 +0200	[thread overview]
Message-ID: <YsVpM1f86FAIEO8i@alfio.lan> (raw)
In-Reply-To: <ccc54757d89d38af35e5c5885edfb980c7b227f6.1656921701.git.mchehab@kernel.org>

Hi Mauro and Chris,

On Mon, Jul 04, 2022 at 09:09:28AM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson <chris.p.wilson@intel.com>
> 
> Don't allow two engines to be reset in parallel, as they would both
> try to select a reset bit (and send requests to common registers)
> and wait on that register, at the same time. Serialize control of
> the reset requests/acks using the uncore->lock, which will also ensure
> that no other GT state changes at the same time as the actual reset.
> 
> Cc: stable@vger.kernel.org # Up to 4.4
> Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Reviewed-by: Andi Shyti <andi.shyti@intel.com>
> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

sorry for the delay but I wanted to understand what has been
agreed between you and Tvrtko about the Cc'ing the stable list.

Anyway, I confirm my review here.

Andi

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
> See [PATCH v3 0/2] at: https://lore.kernel.org/all/cover.1656921701.git.mchehab@kernel.org/
> 
>  drivers/gpu/drm/i915/gt/intel_reset.c | 37 ++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index a5338c3fde7a..c68d36fb5bbd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -300,9 +300,9 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
>  	return err;
>  }
>  
> -static int gen6_reset_engines(struct intel_gt *gt,
> -			      intel_engine_mask_t engine_mask,
> -			      unsigned int retry)
> +static int __gen6_reset_engines(struct intel_gt *gt,
> +				intel_engine_mask_t engine_mask,
> +				unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	u32 hw_mask;
> @@ -321,6 +321,20 @@ static int gen6_reset_engines(struct intel_gt *gt,
>  	return gen6_hw_domain_reset(gt, hw_mask);
>  }
>  
> +static int gen6_reset_engines(struct intel_gt *gt,
> +			      intel_engine_mask_t engine_mask,
> +			      unsigned int retry)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +	ret = __gen6_reset_engines(gt, engine_mask, retry);
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
> +	return ret;
> +}
> +
>  static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct intel_engine_cs *engine)
>  {
>  	int vecs_id;
> @@ -487,9 +501,9 @@ static void gen11_unlock_sfc(struct intel_engine_cs *engine)
>  	rmw_clear_fw(uncore, sfc_lock.lock_reg, sfc_lock.lock_bit);
>  }
>  
> -static int gen11_reset_engines(struct intel_gt *gt,
> -			       intel_engine_mask_t engine_mask,
> -			       unsigned int retry)
> +static int __gen11_reset_engines(struct intel_gt *gt,
> +				 intel_engine_mask_t engine_mask,
> +				 unsigned int retry)
>  {
>  	struct intel_engine_cs *engine;
>  	intel_engine_mask_t tmp;
> @@ -583,8 +597,11 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	struct intel_engine_cs *engine;
>  	const bool reset_non_ready = retry >= 1;
>  	intel_engine_mask_t tmp;
> +	unsigned long flags;
>  	int ret;
>  
> +	spin_lock_irqsave(&gt->uncore->lock, flags);
> +
>  	for_each_engine_masked(engine, gt, engine_mask, tmp) {
>  		ret = gen8_engine_reset_prepare(engine);
>  		if (ret && !reset_non_ready)
> @@ -612,17 +629,19 @@ static int gen8_reset_engines(struct intel_gt *gt,
>  	 * This is best effort, so ignore any error from the initial reset.
>  	 */
>  	if (IS_DG2(gt->i915) && engine_mask == ALL_ENGINES)
> -		gen11_reset_engines(gt, gt->info.engine_mask, 0);
> +		__gen11_reset_engines(gt, gt->info.engine_mask, 0);
>  
>  	if (GRAPHICS_VER(gt->i915) >= 11)
> -		ret = gen11_reset_engines(gt, engine_mask, retry);
> +		ret = __gen11_reset_engines(gt, engine_mask, retry);
>  	else
> -		ret = gen6_reset_engines(gt, engine_mask, retry);
> +		ret = __gen6_reset_engines(gt, engine_mask, retry);
>  
>  skip_reset:
>  	for_each_engine_masked(engine, gt, engine_mask, tmp)
>  		gen8_engine_reset_cancel(engine);
>  
> +	spin_unlock_irqrestore(&gt->uncore->lock, flags);
> +
>  	return ret;
>  }
>  
> -- 
> 2.36.1

  reply	other threads:[~2022-07-06 10:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04  8:09 [PATCH v3 0/2] Fix TLB invalidate issues with Broadwell Mauro Carvalho Chehab
2022-07-04 15:20 ` Mauro Carvalho Chehab
2022-07-04 15:20 ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-04 15:20 ` Mauro Carvalho Chehab
2022-07-04  8:09 ` Mauro Carvalho Chehab
2022-07-04  8:09 ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-04  8:09 ` [PATCH v3 1/2] drm/i915/gt: Serialize GRDOM access between multiple engine resets Mauro Carvalho Chehab
2022-07-04 15:20   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-04 15:20   ` Mauro Carvalho Chehab
2022-07-04 15:20   ` Mauro Carvalho Chehab
2022-07-04  8:09   ` Mauro Carvalho Chehab
2022-07-04  8:09   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-06 10:51   ` Andi Shyti [this message]
2022-07-06 10:51     ` Andi Shyti
2022-07-06 10:51     ` Andi Shyti
2022-07-07 21:27   ` [Intel-gfx] " Andrzej Hajda
2022-07-07 21:27     ` Andrzej Hajda
2022-07-04  8:09 ` [PATCH v3 2/2] drm/i915/gt: Serialize TLB invalidates with GT resets Mauro Carvalho Chehab
2022-07-04 15:20   ` Mauro Carvalho Chehab
2022-07-04 15:20   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-04 15:20   ` Mauro Carvalho Chehab
2022-07-04  8:09   ` [Intel-gfx] " Mauro Carvalho Chehab
2022-07-04  8:09   ` Mauro Carvalho Chehab
2022-07-06 10:50   ` Andi Shyti
2022-07-06 10:50     ` [Intel-gfx] " Andi Shyti
2022-07-06 10:50     ` Andi Shyti
2022-07-07 21:28   ` [Intel-gfx] " Andrzej Hajda
2022-07-07 21:28     ` Andrzej Hajda
2022-07-04 19:35 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix TLB invalidate issues with Broadwell (rev3) Patchwork
2022-07-04 19:36 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-07-04 19:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-07-05  0:53 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-07-07 14:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix TLB invalidate issues with Broadwell (rev4) Patchwork
2022-07-08 14:27   ` Rodrigo Vivi
2022-07-07 14:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-07-08 14:29   ` Rodrigo Vivi
2022-07-11  6:16     ` Mauro Carvalho Chehab
2022-07-07 15:06 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-07-08  6:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-07-08 14:31   ` Rodrigo Vivi
2022-07-11  6:31     ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YsVpM1f86FAIEO8i@alfio.lan \
    --to=andi.shyti@linux.intel.com \
    --cc=John.C.Harrison@intel.com \
    --cc=airlied@linux.ie \
    --cc=chris.p.wilson@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=mchehab@kernel.org \
    --cc=mika.kuoppala@linux.intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=tejaskumarx.surendrakumar.upadhyay@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=umesh.nerlige.ramappa@intel.com \
    --cc=yu.bruce.chang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.