All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	"Kevin Brodsky" <kevin.brodsky@arm.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
Date: Tue, 20 Jun 2023 20:41:10 +0300	[thread overview]
Message-ID: <ZJHkthMktY83pwvy@smile.fi.intel.com> (raw)
In-Reply-To: <amgwl5mthhqgvgkqnor6tjfcr3x3pgwvpqin5efwwjfpdhvvpa@vhzhiq5mzsdg>

On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> > > >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> > > >> >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8()  macros to create
> > > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
> > > >> >> >> BIT_U16() and BIT_U8().

> > > >> >> > Why?
> > > >> >>
> > > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit
> > > >> >> builds.
> > > >> >
> > > >> > When needed GENMASK_ULL() can be used (with respective castings perhaps)
> > > >> > and BIT_ULL(), no?
> > > >>
> > > >> How does that help with making them the same 32-bit size on both 32 and
> > > >> 64 bit builds?
> > > >
> > > > 	u32 x = GENMASK();
> > > > 	u64 y = GENMASK_ULL();
> > > >
> > > > No? Then use in your code either x or y. Note that I assume that the parameters
> > > > to GENMASK*() are built-time constants. Is it the case for you?
> > > 
> > > What's wrong with wanting to define macros with specific size, depending
> > > on e.g. hardware registers instead of build size?
> > 
> > Nothing, but I think the problem is smaller than it's presented.
> 
> not sure about big/small problem you are talking about. It's a problem
> for when the *device* register is a 32b fixed width, which is
> independent from the CPU you are running on. We also have registers that
> are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
> mistakes like below. Just to use one example, the diff below builds
> fine on my 64b machine, yet it's obviously wrong:
> 
> 	$ git diff 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	index 0b414eae1683..692a0ad9a768 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	@@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt *gt,
> 			 * No need to save old steering reg value.
> 			 */
> 			intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
> 	-                                     REG_FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	-                                     REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 	+                                     FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	+                                     FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 					      (rw_flag == FW_REG_READ ? GEN11_MCR_MULTICAST : 0));
> 		} else if (GRAPHICS_VER(uncore->i915) >= 11) {
> 			mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
> 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	index 718cb2c80f79..c42bc2900c6a 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	@@ -80,8 +80,8 @@
> 	 #define   GEN11_MCR_SLICE_MASK                 GEN11_MCR_SLICE(0xf)
> 	 #define   GEN11_MCR_SUBSLICE(subslice)         (((subslice) & 0x7) << 24)
> 	 #define   GEN11_MCR_SUBSLICE_MASK              GEN11_MCR_SUBSLICE(0x7)
> 	-#define   MTL_MCR_GROUPID                      REG_GENMASK(11, 8)
> 	-#define   MTL_MCR_INSTANCEID                   REG_GENMASK(3, 0)
> 	+#define   MTL_MCR_GROUPID                      GENMASK(32, 8)
> 	+#define   MTL_MCR_INSTANCEID                   GENMASK(3, 0)
> 	 	 #define IPEIR_I965                             _MMIO(0x2064)
> 	 #define IPEHR_I965                             _MMIO(0x2068)
> 
> If the driver didn't support 32b CPUs, this would even go unnoticed.

So, what does prevent you from using GENMASK_ULL()?

Another point, you may teach GENMASK() to issue a warning if hi and/or lo
bigger than BITS_PER_LONG.

I still don't see the usefulness of that churn.

> Lucas De Marchi
> 
> > And there are already header for bitfields with a lot of helpers
> > for (similar) cases if not yours.
> > 
> > > What would you use for printk format if you wanted to to print
> > > GENMASK()?
> > 
> > %lu, no?

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	"Kevin Brodsky" <kevin.brodsky@arm.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
Date: Tue, 20 Jun 2023 20:41:10 +0300	[thread overview]
Message-ID: <ZJHkthMktY83pwvy@smile.fi.intel.com> (raw)
In-Reply-To: <amgwl5mthhqgvgkqnor6tjfcr3x3pgwvpqin5efwwjfpdhvvpa@vhzhiq5mzsdg>

On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> > > >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> > > >> >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8()  macros to create
> > > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
> > > >> >> >> BIT_U16() and BIT_U8().

> > > >> >> > Why?
> > > >> >>
> > > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit
> > > >> >> builds.
> > > >> >
> > > >> > When needed GENMASK_ULL() can be used (with respective castings perhaps)
> > > >> > and BIT_ULL(), no?
> > > >>
> > > >> How does that help with making them the same 32-bit size on both 32 and
> > > >> 64 bit builds?
> > > >
> > > > 	u32 x = GENMASK();
> > > > 	u64 y = GENMASK_ULL();
> > > >
> > > > No? Then use in your code either x or y. Note that I assume that the parameters
> > > > to GENMASK*() are built-time constants. Is it the case for you?
> > > 
> > > What's wrong with wanting to define macros with specific size, depending
> > > on e.g. hardware registers instead of build size?
> > 
> > Nothing, but I think the problem is smaller than it's presented.
> 
> not sure about big/small problem you are talking about. It's a problem
> for when the *device* register is a 32b fixed width, which is
> independent from the CPU you are running on. We also have registers that
> are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
> mistakes like below. Just to use one example, the diff below builds
> fine on my 64b machine, yet it's obviously wrong:
> 
> 	$ git diff 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	index 0b414eae1683..692a0ad9a768 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	@@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt *gt,
> 			 * No need to save old steering reg value.
> 			 */
> 			intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
> 	-                                     REG_FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	-                                     REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 	+                                     FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	+                                     FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 					      (rw_flag == FW_REG_READ ? GEN11_MCR_MULTICAST : 0));
> 		} else if (GRAPHICS_VER(uncore->i915) >= 11) {
> 			mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
> 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	index 718cb2c80f79..c42bc2900c6a 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	@@ -80,8 +80,8 @@
> 	 #define   GEN11_MCR_SLICE_MASK                 GEN11_MCR_SLICE(0xf)
> 	 #define   GEN11_MCR_SUBSLICE(subslice)         (((subslice) & 0x7) << 24)
> 	 #define   GEN11_MCR_SUBSLICE_MASK              GEN11_MCR_SUBSLICE(0x7)
> 	-#define   MTL_MCR_GROUPID                      REG_GENMASK(11, 8)
> 	-#define   MTL_MCR_INSTANCEID                   REG_GENMASK(3, 0)
> 	+#define   MTL_MCR_GROUPID                      GENMASK(32, 8)
> 	+#define   MTL_MCR_INSTANCEID                   GENMASK(3, 0)
> 	 	 #define IPEIR_I965                             _MMIO(0x2064)
> 	 #define IPEHR_I965                             _MMIO(0x2068)
> 
> If the driver didn't support 32b CPUs, this would even go unnoticed.

So, what does prevent you from using GENMASK_ULL()?

Another point, you may teach GENMASK() to issue a warning if hi and/or lo
bigger than BITS_PER_LONG.

I still don't see the usefulness of that churn.

> Lucas De Marchi
> 
> > And there are already header for bitfields with a lot of helpers
> > for (similar) cases if not yours.
> > 
> > > What would you use for printk format if you wanted to to print
> > > GENMASK()?
> > 
> > %lu, no?

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	intel-gfx@lists.freedesktop.org,
	"Kevin Brodsky" <kevin.brodsky@arm.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Christian König" <christian.koenig@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros
Date: Tue, 20 Jun 2023 20:41:10 +0300	[thread overview]
Message-ID: <ZJHkthMktY83pwvy@smile.fi.intel.com> (raw)
In-Reply-To: <amgwl5mthhqgvgkqnor6tjfcr3x3pgwvpqin5efwwjfpdhvvpa@vhzhiq5mzsdg>

On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> > > >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> > > >> >> On Fri, 12 May 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > >> >> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > >> >> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8()  macros to create
> > > >> >> >> masks for fixed-width types and also the corresponding BIT_U32(),
> > > >> >> >> BIT_U16() and BIT_U8().

> > > >> >> > Why?
> > > >> >>
> > > >> >> The main reason is that GENMASK() and BIT() size varies for 32/64 bit
> > > >> >> builds.
> > > >> >
> > > >> > When needed GENMASK_ULL() can be used (with respective castings perhaps)
> > > >> > and BIT_ULL(), no?
> > > >>
> > > >> How does that help with making them the same 32-bit size on both 32 and
> > > >> 64 bit builds?
> > > >
> > > > 	u32 x = GENMASK();
> > > > 	u64 y = GENMASK_ULL();
> > > >
> > > > No? Then use in your code either x or y. Note that I assume that the parameters
> > > > to GENMASK*() are built-time constants. Is it the case for you?
> > > 
> > > What's wrong with wanting to define macros with specific size, depending
> > > on e.g. hardware registers instead of build size?
> > 
> > Nothing, but I think the problem is smaller than it's presented.
> 
> not sure about big/small problem you are talking about. It's a problem
> for when the *device* register is a 32b fixed width, which is
> independent from the CPU you are running on. We also have registers that
> are u16 and u64. Having fixed-width GENMASK and BIT helps avoiding
> mistakes like below. Just to use one example, the diff below builds
> fine on my 64b machine, yet it's obviously wrong:
> 
> 	$ git diff 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	index 0b414eae1683..692a0ad9a768 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> 	@@ -261,8 +261,8 @@ static u32 rw_with_mcr_steering_fw(struct intel_gt *gt,
> 			 * No need to save old steering reg value.
> 			 */
> 			intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
> 	-                                     REG_FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	-                                     REG_FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 	+                                     FIELD_PREP(MTL_MCR_GROUPID, group) |
> 	+                                     FIELD_PREP(MTL_MCR_INSTANCEID, instance) |
> 					      (rw_flag == FW_REG_READ ? GEN11_MCR_MULTICAST : 0));
> 		} else if (GRAPHICS_VER(uncore->i915) >= 11) {
> 			mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
> 	diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	index 718cb2c80f79..c42bc2900c6a 100644
> 	--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> 	@@ -80,8 +80,8 @@
> 	 #define   GEN11_MCR_SLICE_MASK                 GEN11_MCR_SLICE(0xf)
> 	 #define   GEN11_MCR_SUBSLICE(subslice)         (((subslice) & 0x7) << 24)
> 	 #define   GEN11_MCR_SUBSLICE_MASK              GEN11_MCR_SUBSLICE(0x7)
> 	-#define   MTL_MCR_GROUPID                      REG_GENMASK(11, 8)
> 	-#define   MTL_MCR_INSTANCEID                   REG_GENMASK(3, 0)
> 	+#define   MTL_MCR_GROUPID                      GENMASK(32, 8)
> 	+#define   MTL_MCR_INSTANCEID                   GENMASK(3, 0)
> 	 	 #define IPEIR_I965                             _MMIO(0x2064)
> 	 #define IPEHR_I965                             _MMIO(0x2068)
> 
> If the driver didn't support 32b CPUs, this would even go unnoticed.

So, what does prevent you from using GENMASK_ULL()?

Another point, you may teach GENMASK() to issue a warning if hi and/or lo
bigger than BITS_PER_LONG.

I still don't see the usefulness of that churn.

> Lucas De Marchi
> 
> > And there are already header for bitfields with a lot of helpers
> > for (similar) cases if not yours.
> > 
> > > What would you use for printk format if you wanted to to print
> > > GENMASK()?
> > 
> > %lu, no?

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-06-20 17:41 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  5:14 [Intel-gfx] [PATCH 0/3] Fixed-width mask/bit helpers Lucas De Marchi
2023-05-09  5:14 ` Lucas De Marchi
2023-05-09  5:14 ` Lucas De Marchi
2023-05-09  5:14 ` [Intel-xe] " Lucas De Marchi
2023-05-09  5:14 ` [Intel-gfx] [PATCH 1/3] drm/amd: Remove wrapper macros over get_u{32, 16, 8} Lucas De Marchi
2023-05-09  5:14   ` [PATCH 1/3] drm/amd: Remove wrapper macros over get_u{32,16,8} Lucas De Marchi
2023-05-09  5:14   ` Lucas De Marchi
2023-05-09  5:14   ` [Intel-xe] [PATCH 1/3] drm/amd: Remove wrapper macros over get_u{32, 16, 8} Lucas De Marchi
2023-05-09  5:14 ` [Intel-gfx] [PATCH 2/3] linux/bits.h: Add fixed-width GENMASK and BIT macros Lucas De Marchi
2023-05-09  5:14   ` Lucas De Marchi
2023-05-09  5:14   ` Lucas De Marchi
2023-05-09  5:14   ` [Intel-xe] " Lucas De Marchi
2023-05-09 14:00   ` [Intel-gfx] " Gustavo Sousa
2023-05-09 14:00     ` Gustavo Sousa
2023-05-09 14:00     ` Gustavo Sousa
2023-05-09 21:34     ` [Intel-gfx] " Lucas De Marchi
2023-05-09 21:34       ` Lucas De Marchi
2023-05-09 21:34       ` Lucas De Marchi
2023-05-10 12:18   ` [Intel-gfx] " kernel test robot
2023-05-10 12:18     ` kernel test robot
2023-05-10 12:18     ` kernel test robot
2023-05-10 12:18     ` [Intel-xe] " kernel test robot
2023-05-12 11:14   ` [Intel-gfx] " Andy Shevchenko
2023-05-12 11:14     ` Andy Shevchenko
2023-05-12 11:14     ` Andy Shevchenko
2023-05-12 11:14     ` [Intel-xe] " Andy Shevchenko
2023-05-12 11:25     ` [Intel-gfx] " Jani Nikula
2023-05-12 11:25       ` Jani Nikula
2023-05-12 11:25       ` Jani Nikula
2023-05-12 11:25       ` [Intel-xe] " Jani Nikula
2023-05-12 11:32       ` [Intel-gfx] " Andy Shevchenko
2023-05-12 11:32         ` Andy Shevchenko
2023-05-12 11:32         ` Andy Shevchenko
2023-05-12 11:32         ` [Intel-xe] " Andy Shevchenko
2023-05-12 11:45         ` [Intel-gfx] " Jani Nikula
2023-05-12 11:45           ` Jani Nikula
2023-05-12 11:45           ` Jani Nikula
2023-05-12 11:45           ` [Intel-xe] " Jani Nikula
2023-06-15 15:53           ` [Intel-gfx] " Andy Shevchenko
2023-06-15 15:53             ` Andy Shevchenko
2023-06-15 15:53             ` Andy Shevchenko
2023-06-15 15:53             ` [Intel-xe] " Andy Shevchenko
2023-06-20 14:47             ` [Intel-gfx] " Jani Nikula
2023-06-20 14:47               ` Jani Nikula
2023-06-20 14:47               ` Jani Nikula
2023-06-20 14:47               ` [Intel-xe] " Jani Nikula
2023-06-20 14:55               ` [Intel-gfx] " Andy Shevchenko
2023-06-20 14:55                 ` Andy Shevchenko
2023-06-20 14:55                 ` Andy Shevchenko
2023-06-20 14:55                 ` [Intel-xe] " Andy Shevchenko
2023-06-20 17:25                 ` [Intel-gfx] " Lucas De Marchi
2023-06-20 17:25                   ` Lucas De Marchi
2023-06-20 17:25                   ` Lucas De Marchi
2023-06-20 17:41                   ` Andy Shevchenko [this message]
2023-06-20 17:41                     ` Andy Shevchenko
2023-06-20 17:41                     ` Andy Shevchenko
2023-06-20 18:02                     ` [Intel-gfx] " Lucas De Marchi
2023-06-20 18:02                       ` Lucas De Marchi
2023-06-20 18:02                       ` Lucas De Marchi
2023-06-20 18:19                     ` [Intel-gfx] " Jani Nikula
2023-06-20 18:19                       ` Jani Nikula
2023-06-20 18:19                       ` Jani Nikula
2023-05-12 16:29     ` [Intel-gfx] " Lucas De Marchi
2023-05-12 16:29       ` Lucas De Marchi
2023-05-12 16:29       ` Lucas De Marchi
2023-05-12 16:29       ` [Intel-xe] " Lucas De Marchi
2023-06-15 15:58       ` [Intel-gfx] " Andy Shevchenko
2023-06-15 15:58         ` Andy Shevchenko
2023-06-15 15:58         ` Andy Shevchenko
2023-06-15 15:58         ` [Intel-xe] " Andy Shevchenko
2023-06-22  2:20   ` [Intel-gfx] " Yury Norov
2023-06-22  2:20     ` Yury Norov
2023-06-22  2:20     ` Yury Norov
2023-06-22  2:20     ` [Intel-xe] " Yury Norov
2023-06-22  6:15     ` [Intel-gfx] " Lucas De Marchi
2023-06-22  6:15       ` Lucas De Marchi
2023-06-22  6:15       ` Lucas De Marchi
2023-06-22  6:15       ` [Intel-xe] " Lucas De Marchi
2023-06-22 14:59       ` [Intel-gfx] " Yury Norov
2023-06-22 14:59         ` Yury Norov
2023-06-22 14:59         ` Yury Norov
2023-06-22 14:59         ` [Intel-xe] " Yury Norov
2024-01-18 20:42     ` Lucas De Marchi
2024-01-18 20:42       ` Lucas De Marchi
2024-01-18 21:48       ` Yury Norov
2024-01-18 21:48         ` Yury Norov
2024-01-18 23:25         ` Lucas De Marchi
2024-01-18 23:25           ` Lucas De Marchi
2024-01-19  2:01           ` Yury Norov
2024-01-19  2:01             ` Yury Norov
2024-01-19 15:07             ` Lucas De Marchi
2024-01-19 15:07               ` Lucas De Marchi
2023-05-09  5:14 ` [Intel-gfx] [PATCH 3/3] drm/i915: Temporary conversion to new GENMASK/BIT macros Lucas De Marchi
2023-05-09  5:14   ` Lucas De Marchi
2023-05-09  5:14   ` Lucas De Marchi
2023-05-09  5:14   ` [Intel-xe] " Lucas De Marchi
2023-05-09  7:57   ` [Intel-gfx] " Jani Nikula
2023-05-09  7:57     ` Jani Nikula
2023-05-09  7:57     ` Jani Nikula
2023-05-09  7:57     ` [Intel-xe] " Jani Nikula
2023-05-09  8:15     ` [Intel-gfx] " Lucas De Marchi
2023-05-09  8:15       ` Lucas De Marchi
2023-05-09  8:15       ` Lucas De Marchi
2023-05-09  8:15       ` [Intel-xe] " Lucas De Marchi
2023-05-09  5:17 ` [Intel-xe] ✓ CI.Patch_applied: success for Fixed-width mask/bit helpers Patchwork
2023-05-09  5:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2023-05-09  5:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-05-09  6:00 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-05-09 15:56 ` [Intel-xe] ✓ CI.Patch_applied: success for Fixed-width mask/bit helpers (rev2) Patchwork
2023-05-09 15:58 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-09 16:01 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-09 16:27 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-06-22  3:53 ` [Intel-xe] ✗ CI.Patch_applied: failure for Fixed-width mask/bit helpers (rev3) Patchwork
2023-06-27 20:01 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Fixed-width mask/bit helpers (rev2) Patchwork

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=ZJHkthMktY83pwvy@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=masahiroy@kernel.org \
    --cc=tglx@linutronix.de \
    /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.