All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/53] drm/i915: Add "release id" version
Date: Fri, 2 Jul 2021 13:33:50 +0100	[thread overview]
Message-ID: <e15c0271-8663-6122-f7af-80c642fd2a4f@linux.intel.com> (raw)
In-Reply-To: <20210701202427.1547543-2-matthew.d.roper@intel.com>


On 01/07/2021 21:23, Matt Roper wrote:
> From: Lucas De Marchi <lucas.demarchi@intel.com>
> 
> Besides the arch version returned by GRAPHICS_VER(), new platforms
> contain a "release id" to make clear the difference from one platform to
> another. Although for the first ones we may use them as if they were a

What does "first ones" refer to here?

> major/minor version, that is not true for all platforms: we may have a
> `release_id == n` that is closer to `n - 2` than to `n - 1`.

Hm this is a bit confusing. Is the sentence simply trying to say that, 
as the release id number is growing, hw capabilities are not simply 
accumulating but can be removed as well? Otherwise I am not sure how the 
user of these macros is supposed to act on this sentence.

> However the release id number is not defined by hardware until we start
> using the GMD_ID register. For the platforms before that register is
> useful we will set the values in software and we can set them as we
> please. So the plan is to set them so we can group different features
> under a single GRAPHICS_VER_FULL() check.
> 
> After GMD_ID is used, the usefulness of a "full version check" will be
> greatly reduced and will be mostly used for deciding workarounds and a
> few code paths. So it makes sense to keep it as a separate field from
> graphics_ver.
> 
> Also, currently there is not much use for the release id in media and
> display, so keep them out.
> 
> This is a mix of 2 independent changes: one by me and the other by Matt
> Roper.
> 
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_drv.h          | 6 ++++++
>   drivers/gpu/drm/i915/intel_device_info.c | 2 ++
>   drivers/gpu/drm/i915/intel_device_info.h | 2 ++
>   3 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6dff4ca01241..9639800485b9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1258,11 +1258,17 @@ static inline struct drm_i915_private *pdev_to_i915(struct pci_dev *pdev)
>    */
>   #define IS_GEN(dev_priv, n)		(GRAPHICS_VER(dev_priv) == (n))
>   
> +#define IP_VER(ver, release)		((ver) << 8 | (release))
> +
>   #define GRAPHICS_VER(i915)		(INTEL_INFO(i915)->graphics_ver)
> +#define GRAPHICS_VER_FULL(i915)		IP_VER(INTEL_INFO(i915)->graphics_ver, \
> +					       INTEL_INFO(i915)->graphics_ver_release)
>   #define IS_GRAPHICS_VER(i915, from, until) \
>   	(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
>   
>   #define MEDIA_VER(i915)			(INTEL_INFO(i915)->media_ver)
> +#define MEDIA_VER_FULL(i915)		IP_VER(INTEL_INFO(i915)->media_ver, \
> +					       INTEL_INFO(i915)->media_ver_release)
>   #define IS_MEDIA_VER(i915, from, until) \
>   	(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
>   
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
> index 7eaa92fee421..e8ad14f002c1 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -97,7 +97,9 @@ void intel_device_info_print_static(const struct intel_device_info *info,
>   				    struct drm_printer *p)
>   {
>   	drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
> +	drm_printf(p, "graphics_ver_release: %u\n", info->graphics_ver_release);

I get the VER and VER_FULL in the macros but could 'ver' and 
'ver_release' here and in the code simply be renamed to 'ver'/'version' 
and 'release'? Maybe it is just me but don't think I encountered the 
term "version release" before.

Regards,

Tvrtko

>   	drm_printf(p, "media_ver: %u\n", info->media_ver);
> +	drm_printf(p, "media_ver_release: %u\n", info->media_ver_release);
>   	drm_printf(p, "display_ver: %u\n", info->display.ver);
>   	drm_printf(p, "gt: %d\n", info->gt);
>   	drm_printf(p, "iommu: %s\n", iommu_name());
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> index b326aff65cd6..944a5ff4df49 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -162,7 +162,9 @@ enum intel_ppgtt_type {
>   
>   struct intel_device_info {
>   	u8 graphics_ver;
> +	u8 graphics_ver_release;
>   	u8 media_ver;
> +	u8 media_ver_release;
>   
>   	u8 gt; /* GT number, 0 if undefined */
>   	intel_engine_mask_t platform_engine_mask; /* Engines supported by the HW */
> 

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/53] drm/i915: Add "release id" version
Date: Fri, 2 Jul 2021 13:33:50 +0100	[thread overview]
Message-ID: <e15c0271-8663-6122-f7af-80c642fd2a4f@linux.intel.com> (raw)
In-Reply-To: <20210701202427.1547543-2-matthew.d.roper@intel.com>


On 01/07/2021 21:23, Matt Roper wrote:
> From: Lucas De Marchi <lucas.demarchi@intel.com>
> 
> Besides the arch version returned by GRAPHICS_VER(), new platforms
> contain a "release id" to make clear the difference from one platform to
> another. Although for the first ones we may use them as if they were a

What does "first ones" refer to here?

> major/minor version, that is not true for all platforms: we may have a
> `release_id == n` that is closer to `n - 2` than to `n - 1`.

Hm this is a bit confusing. Is the sentence simply trying to say that, 
as the release id number is growing, hw capabilities are not simply 
accumulating but can be removed as well? Otherwise I am not sure how the 
user of these macros is supposed to act on this sentence.

> However the release id number is not defined by hardware until we start
> using the GMD_ID register. For the platforms before that register is
> useful we will set the values in software and we can set them as we
> please. So the plan is to set them so we can group different features
> under a single GRAPHICS_VER_FULL() check.
> 
> After GMD_ID is used, the usefulness of a "full version check" will be
> greatly reduced and will be mostly used for deciding workarounds and a
> few code paths. So it makes sense to keep it as a separate field from
> graphics_ver.
> 
> Also, currently there is not much use for the release id in media and
> display, so keep them out.
> 
> This is a mix of 2 independent changes: one by me and the other by Matt
> Roper.
> 
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_drv.h          | 6 ++++++
>   drivers/gpu/drm/i915/intel_device_info.c | 2 ++
>   drivers/gpu/drm/i915/intel_device_info.h | 2 ++
>   3 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6dff4ca01241..9639800485b9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1258,11 +1258,17 @@ static inline struct drm_i915_private *pdev_to_i915(struct pci_dev *pdev)
>    */
>   #define IS_GEN(dev_priv, n)		(GRAPHICS_VER(dev_priv) == (n))
>   
> +#define IP_VER(ver, release)		((ver) << 8 | (release))
> +
>   #define GRAPHICS_VER(i915)		(INTEL_INFO(i915)->graphics_ver)
> +#define GRAPHICS_VER_FULL(i915)		IP_VER(INTEL_INFO(i915)->graphics_ver, \
> +					       INTEL_INFO(i915)->graphics_ver_release)
>   #define IS_GRAPHICS_VER(i915, from, until) \
>   	(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
>   
>   #define MEDIA_VER(i915)			(INTEL_INFO(i915)->media_ver)
> +#define MEDIA_VER_FULL(i915)		IP_VER(INTEL_INFO(i915)->media_ver, \
> +					       INTEL_INFO(i915)->media_ver_release)
>   #define IS_MEDIA_VER(i915, from, until) \
>   	(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
>   
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
> index 7eaa92fee421..e8ad14f002c1 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -97,7 +97,9 @@ void intel_device_info_print_static(const struct intel_device_info *info,
>   				    struct drm_printer *p)
>   {
>   	drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
> +	drm_printf(p, "graphics_ver_release: %u\n", info->graphics_ver_release);

I get the VER and VER_FULL in the macros but could 'ver' and 
'ver_release' here and in the code simply be renamed to 'ver'/'version' 
and 'release'? Maybe it is just me but don't think I encountered the 
term "version release" before.

Regards,

Tvrtko

>   	drm_printf(p, "media_ver: %u\n", info->media_ver);
> +	drm_printf(p, "media_ver_release: %u\n", info->media_ver_release);
>   	drm_printf(p, "display_ver: %u\n", info->display.ver);
>   	drm_printf(p, "gt: %d\n", info->gt);
>   	drm_printf(p, "iommu: %s\n", iommu_name());
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> index b326aff65cd6..944a5ff4df49 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -162,7 +162,9 @@ enum intel_ppgtt_type {
>   
>   struct intel_device_info {
>   	u8 graphics_ver;
> +	u8 graphics_ver_release;
>   	u8 media_ver;
> +	u8 media_ver_release;
>   
>   	u8 gt; /* GT number, 0 if undefined */
>   	intel_engine_mask_t platform_engine_mask; /* Engines supported by the HW */
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-07-02 12:33 UTC|newest]

Thread overview: 173+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01 20:23 [PATCH 00/53] Begin enabling Xe_HP SDV and DG2 platforms Matt Roper
2021-07-01 20:23 ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 01/53] drm/i915: Add "release id" version Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-02 12:33   ` Tvrtko Ursulin [this message]
2021-07-02 12:33     ` Tvrtko Ursulin
2021-07-05 11:52     ` Jani Nikula
2021-07-05 11:52       ` Jani Nikula
2021-07-06 21:09       ` Lucas De Marchi
2021-07-06 21:09         ` Lucas De Marchi
2021-07-07  8:34         ` Jani Nikula
2021-07-07  8:34           ` Jani Nikula
2021-07-07 15:40           ` Lucas De Marchi
2021-07-07 15:40             ` Lucas De Marchi
2021-07-06 20:57     ` Lucas De Marchi
2021-07-06 20:57       ` Lucas De Marchi
2021-07-01 20:23 ` [PATCH 02/53] drm/i915: Add XE_HP initial definitions Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 03/53] drm/i915: Fork DG1 interrupt handler Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-02  9:21   ` Daniel Vetter
2021-07-02  9:21     ` [Intel-gfx] " Daniel Vetter
2021-07-06 22:48     ` Lucas De Marchi
2021-07-06 22:48       ` Lucas De Marchi
2021-07-07  7:39       ` Daniel Vetter
2021-07-07  7:39         ` Daniel Vetter
2021-07-07 15:53         ` Lucas De Marchi
2021-07-07 15:53           ` Lucas De Marchi
2021-07-01 20:23 ` [PATCH 04/53] drm/i915/xehp: VDBOX/VEBOX fusing registers are enable-based Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 22:06   ` Lucas De Marchi
2021-07-01 22:06     ` [Intel-gfx] " Lucas De Marchi
2021-07-01 20:23 ` [PATCH 05/53] drm/i915/gen12: Use fuse info to enable SFC Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 22:19   ` Lucas De Marchi
2021-07-01 22:19     ` Lucas De Marchi
2021-07-02 12:08   ` Tvrtko Ursulin
2021-07-02 12:08     ` Tvrtko Ursulin
2021-07-01 20:23 ` [PATCH 06/53] drm/i915/selftests: Allow for larger engine counts Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 22:33   ` Lucas De Marchi
2021-07-01 22:33     ` [Intel-gfx] " Lucas De Marchi
2021-07-01 20:23 ` [PATCH 07/53] drm/i915/xehp: Extra media engines - Part 1 (engine definitions) Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-02 12:22   ` Tvrtko Ursulin
2021-07-02 12:22     ` Tvrtko Ursulin
2021-07-07 22:17     ` [Intel-gfx] [PATCH v2] " Matt Roper
2021-07-01 20:23 ` [PATCH 08/53] drm/i915/xehp: Extra media engines - Part 2 (interrupts) Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-02 12:42   ` Tvrtko Ursulin
2021-07-02 12:42     ` Tvrtko Ursulin
2021-07-06 21:15     ` Lucas De Marchi
2021-07-06 21:15       ` Lucas De Marchi
2021-07-07  7:46       ` Tvrtko Ursulin
2021-07-07  7:46         ` Tvrtko Ursulin
2021-07-01 20:23 ` [PATCH 09/53] drm/i915/xehp: Extra media engines - Part 3 (reset) Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 10/53] drm/i915/xehp: Xe_HP forcewake support Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 11/53] drm/i915/xehp: Define multicast register ranges Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 12/53] drm/i915/xehp: Handle new device context ID format Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 13/53] drm/i915/xehp: New engine context offsets Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 14/53] drm/i915/xehp: handle new steering options Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 15/53] drm/i915/xehp: Loop over all gslices for INSTDONE processing Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 16/53] drm/i915/xehpsdv: add initial XeHP SDV definitions Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 21:41   ` Rodrigo Vivi
2021-07-01 21:41     ` [Intel-gfx] " Rodrigo Vivi
2021-07-02  7:57   ` Jani Nikula
2021-07-02  7:57     ` [Intel-gfx] " Jani Nikula
2021-07-07 22:20     ` [Intel-gfx] [PATCH v2] " Matt Roper
2021-07-01 20:23 ` [PATCH 17/53] drm/i915/xehp: Changes to ss/eu definitions Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 18/53] drm/i915/xehpsdv: Add maximum sseu limits Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 19/53] drm/i915/xehpsdv: Add compute DSS type Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 20/53] drm/i915/xehpsdv: Define steering tables Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 21/53] drm/i915/xehpsdv: Define MOCS table for XeHP SDV Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 22/53] drm/i915/xehpsdv: factor out function to read RP_STATE_CAP Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 23/53] drm/i915/xehpsdv: Read correct RP_STATE_CAP register Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 21:41   ` Rodrigo Vivi
2021-07-01 21:41     ` [Intel-gfx] " Rodrigo Vivi
2021-07-01 20:23 ` [PATCH 24/53] drm/i915/dg2: add DG2 platform info Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:23 ` [PATCH 25/53] drm/i915/dg2: DG2 uses the same sseu limits as XeHP SDV Matt Roper
2021-07-01 20:23   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 26/53] drm/i915/dg2: Add forcewake table Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 27/53] drm/i915/dg2: Update LNCF steering ranges Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 28/53] drm/i915/dg2: Add SQIDI steering Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 29/53] drm/i915/dg2: Add new LRI reg offsets Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 30/53] drm/i915/dg2: Maintain backward-compatible nested batch behavior Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 31/53] drm/i915/dg2: Report INSTDONE_GEOM values in error state Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-02  8:57   ` Lionel Landwerlin
2021-07-02  8:57     ` [Intel-gfx] " Lionel Landwerlin
2021-07-01 20:24 ` [PATCH 32/53] drm/i915/dg2: Define MOCS table for DG2 Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 33/53] drm/i915/dg2: Add fake PCH Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-06 21:47   ` Lucas De Marchi
2021-07-06 21:47     ` [Intel-gfx] " Lucas De Marchi
2021-07-01 20:24 ` [PATCH 34/53] drm/i915/dg2: Add cdclk table and reference clock Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 35/53] drm/i915/dg2: Skip shared DPLL handling Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 36/53] drm/i915/dg2: Don't wait for AUX power well enable ACKs Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 37/53] drm/i915/dg2: Setup display outputs Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 38/53] drm/i915/dg2: Add dbuf programming Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 39/53] drm/i915/dg2: Don't program BW_BUDDY registers Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 40/53] drm/i915/dg2: Don't read DRAM info Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 41/53] drm/i915/dg2: DG2 has fixed memory bandwidth Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 42/53] drm/i915/dg2: Add MPLLB programming for SNPS PHY Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 43/53] drm/i915/dg2: Add MPLLB programming for HDMI Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 44/53] drm/i915/dg2: Add vswing programming for SNPS phys Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-02  8:14   ` Jani Nikula
2021-07-02  8:14     ` [Intel-gfx] " Jani Nikula
2021-07-01 20:24 ` [PATCH 45/53] drm/i915/dg2: Update modeset sequences Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-02  8:16   ` Jani Nikula
2021-07-02  8:16     ` Jani Nikula
2021-07-07 22:22     ` [Intel-gfx] [PATCH v2] " Matt Roper
2021-07-09 18:25       ` Lucas De Marchi
2021-07-01 20:24 ` [PATCH 46/53] drm/i915/dg2: Classify DG2 PHY types Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 47/53] drm/i915/dg2: Wait for SNPS PHY calibration during display init Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 48/53] drm/i915/dg2: Update lane disable power state during PSR Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 49/53] drm/i915/dg2: Add DG2 to the PSR2 defeature list Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-02  8:19   ` Jani Nikula
2021-07-02  8:19     ` [Intel-gfx] " Jani Nikula
2021-08-23  5:42     ` Kulkarni, Vandita
2021-08-23  5:42       ` [Intel-gfx] " Kulkarni, Vandita
2021-07-01 20:24 ` [PATCH 51/53] drm/i915/display/dsc: Set BPP in the kernel Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-01 20:24 ` [PATCH 52/53] drm/i915/dg2: Update to bigjoiner path Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-09  0:11   ` Navare, Manasi
2021-07-09  0:11     ` [Intel-gfx] " Navare, Manasi
2021-07-01 20:24 ` [PATCH 53/53] drm/i915/dg2: Configure PCON in DP pre-enable path Matt Roper
2021-07-01 20:24   ` [Intel-gfx] " Matt Roper
2021-07-02  1:55 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Begin enabling Xe_HP SDV and DG2 platforms Patchwork
2021-07-02  1:57 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-07-02  2:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-07-02  8:49 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-07-07 22:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Begin enabling Xe_HP SDV and DG2 platforms (rev4) 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=e15c0271-8663-6122-f7af-80c642fd2a4f@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@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.