Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Chauhan, Shekhar" <shekhar.chauhan@intel.com>
To: Matt Atwood <matthew.s.atwood@intel.com>,
	<igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH] lib: sync intel PCI ID macros with kernel
Date: Wed, 29 Jan 2025 09:34:59 +0530	[thread overview]
Message-ID: <d9470a0c-0011-4b25-b06f-1e7c96a7fc87@intel.com> (raw)
In-Reply-To: <20250129003155.91475-1-matthew.s.atwood@intel.com>


On 1/29/2025 6:01, Matt Atwood wrote:
> lib: sync PCI ID macros with kernel
>
> Sync with kernel commit:
> 16016ade13f6 ("drm/xe/ptl: Update the PTL pci id table")

Can we have a simpler commit description, something like: "Sync PCI IDs 
of various platforms with the Xe-KMD."

Reason being: The structural modifications below aren't really a part of 
the kernel commit mentioned.

>
> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
> ---
>   lib/pciids.h | 73 ++++++++++++++++++++++++++++++++++++++--------------
>   1 file changed, 53 insertions(+), 20 deletions(-)
>
> diff --git a/lib/pciids.h b/lib/pciids.h
> index 7883384ac..4736ea525 100644
> --- a/lib/pciids.h
> +++ b/lib/pciids.h
> @@ -717,37 +717,66 @@
>   	MACRO__(0xA7AB, ## __VA_ARGS__)
>   
>   /* DG2 */
> -#define INTEL_DG2_G10_IDS(MACRO__, ...) \
> -	MACRO__(0x5690, ## __VA_ARGS__), \
> -	MACRO__(0x5691, ## __VA_ARGS__), \
> -	MACRO__(0x5692, ## __VA_ARGS__), \
> +#define INTEL_DG2_G10_D_IDS(MACRO__, ...) \
>   	MACRO__(0x56A0, ## __VA_ARGS__), \
>   	MACRO__(0x56A1, ## __VA_ARGS__), \
> -	MACRO__(0x56A2, ## __VA_ARGS__), \
> +	MACRO__(0x56A2, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G10_E_IDS(MACRO__, ...) \
>   	MACRO__(0x56BE, ## __VA_ARGS__), \
>   	MACRO__(0x56BF, ## __VA_ARGS__)
>   
> -#define INTEL_DG2_G11_IDS(MACRO__, ...) \
> -	MACRO__(0x5693, ## __VA_ARGS__), \
> -	MACRO__(0x5694, ## __VA_ARGS__), \
> -	MACRO__(0x5695, ## __VA_ARGS__), \
> +#define INTEL_DG2_G10_M_IDS(MACRO__, ...) \
> +	MACRO__(0x5690, ## __VA_ARGS__), \
> +	MACRO__(0x5691, ## __VA_ARGS__), \
> +	MACRO__(0x5692, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G10_IDS(MACRO__, ...) \
> +	INTEL_DG2_G10_D_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G10_E_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G10_M_IDS(MACRO__, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G11_D_IDS(MACRO__, ...) \
>   	MACRO__(0x56A5, ## __VA_ARGS__), \
>   	MACRO__(0x56A6, ## __VA_ARGS__), \
>   	MACRO__(0x56B0, ## __VA_ARGS__), \
> -	MACRO__(0x56B1, ## __VA_ARGS__), \
> +	MACRO__(0x56B1, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G11_E_IDS(MACRO__, ...) \
>   	MACRO__(0x56BA, ## __VA_ARGS__), \
>   	MACRO__(0x56BB, ## __VA_ARGS__), \
>   	MACRO__(0x56BC, ## __VA_ARGS__), \
>   	MACRO__(0x56BD, ## __VA_ARGS__)
>   
> -#define INTEL_DG2_G12_IDS(MACRO__, ...) \
> -	MACRO__(0x5696, ## __VA_ARGS__), \
> -	MACRO__(0x5697, ## __VA_ARGS__), \
> +#define INTEL_DG2_G11_M_IDS(MACRO__, ...) \
> +	MACRO__(0x5693, ## __VA_ARGS__), \
> +	MACRO__(0x5694, ## __VA_ARGS__), \
> +	MACRO__(0x5695, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G11_IDS(MACRO__, ...) \
> +	INTEL_DG2_G11_D_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G11_E_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G11_M_IDS(MACRO__, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G12_D_IDS(MACRO__, ...) \
>   	MACRO__(0x56A3, ## __VA_ARGS__), \
>   	MACRO__(0x56A4, ## __VA_ARGS__), \
>   	MACRO__(0x56B2, ## __VA_ARGS__), \
>   	MACRO__(0x56B3, ## __VA_ARGS__)
>   
> +#define INTEL_DG2_G12_M_IDS(MACRO__, ...) \
> +	MACRO__(0x5696, ## __VA_ARGS__), \
> +	MACRO__(0x5697, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_G12_IDS(MACRO__, ...) \
> +	INTEL_DG2_G12_D_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G12_M_IDS(MACRO__, ## __VA_ARGS__)
> +
> +#define INTEL_DG2_D_IDS(MACRO__, ...) \
> +	INTEL_DG2_G10_D_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G11_D_IDS(MACRO__, ## __VA_ARGS__), \
> +	INTEL_DG2_G12_D_IDS(MACRO__, ## __VA_ARGS__)
> +
>   #define INTEL_DG2_IDS(MACRO__, ...) \
>   	INTEL_DG2_G10_IDS(MACRO__, ## __VA_ARGS__), \
>   	INTEL_DG2_G11_IDS(MACRO__, ## __VA_ARGS__), \
Although the DG2 IDs look clean to me, but mind explaining me why are we 
creating these sub-defines for DG2_D / DG2_E / DG2_M
> @@ -782,9 +811,12 @@
>   	INTEL_ARL_S_IDS(MACRO__, ## __VA_ARGS__)
>   
>   /* MTL */
> -#define INTEL_MTL_IDS(MACRO__, ...) \
> +#define INTEL_MTL_U_IDS(MACRO__, ...) \
>   	MACRO__(0x7D40, ## __VA_ARGS__), \
> -	MACRO__(0x7D45, ## __VA_ARGS__), \
> +	MACRO__(0x7D45, ## __VA_ARGS__)
> +
> +#define INTEL_MTL_IDS(MACRO__, ...) \
> +	INTEL_MTL_U_IDS(MACRO__, ## __VA_ARGS__), \
>   	MACRO__(0x7D55, ## __VA_ARGS__), \
>   	MACRO__(0x7D60, ## __VA_ARGS__), \
>   	MACRO__(0x7DD5, ## __VA_ARGS__)

Following up on my last comment, if we are creating sub-defines, the 
design isn't followed here in MTL. MTL_IDS extends to MTL_U_IDS and a 
bunch of singletons. Or, if there's a reason behind doing so, please 
help me understand.

> @@ -817,19 +849,20 @@
>   	MACRO__(0xE20B, ## __VA_ARGS__), \
>   	MACRO__(0xE20C, ## __VA_ARGS__), \
>   	MACRO__(0xE20D, ## __VA_ARGS__), \
> -	MACRO__(0xE212, ## __VA_ARGS__)
> +	MACRO__(0xE210, ## __VA_ARGS__), \
> +	MACRO__(0xE212, ## __VA_ARGS__), \
> +	MACRO__(0xE215, ## __VA_ARGS__), \
> +	MACRO__(0xE216, ## __VA_ARGS__)
>   
>   /* PTL */
>   #define INTEL_PTL_IDS(MACRO__, ...) \
>   	MACRO__(0xB080, ## __VA_ARGS__), \
>   	MACRO__(0xB081, ## __VA_ARGS__), \
>   	MACRO__(0xB082, ## __VA_ARGS__), \
> +	MACRO__(0xB083, ## __VA_ARGS__), \
> +	MACRO__(0xB08F, ## __VA_ARGS__), \
>   	MACRO__(0xB090, ## __VA_ARGS__), \
> -	MACRO__(0xB091, ## __VA_ARGS__), \
> -	MACRO__(0xB092, ## __VA_ARGS__), \
>   	MACRO__(0xB0A0, ## __VA_ARGS__), \
> -	MACRO__(0xB0A1, ## __VA_ARGS__), \
> -	MACRO__(0xB0A2, ## __VA_ARGS__), \
>   	MACRO__(0xB0B0, ## __VA_ARGS__)
>   
>   #endif /* __PCIIDS_H__ */

-- 
-shekhar


  parent reply	other threads:[~2025-01-29  4:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29  0:31 [PATCH] lib: sync intel PCI ID macros with kernel Matt Atwood
2025-01-29  1:57 ` ✓ Xe.CI.BAT: success for " Patchwork
2025-01-29  2:10 ` ✓ i915.CI.BAT: " Patchwork
2025-01-29  4:04 ` Chauhan, Shekhar [this message]
2025-01-29  9:33   ` [PATCH] " Jani Nikula
2025-01-29 11:20     ` Kamil Konieczny
2025-01-29 12:43       ` Jani Nikula
2025-01-29 13:52 ` ✗ i915.CI.Full: failure for " Patchwork
2025-01-29 15:50 ` ✗ Xe.CI.Full: " 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=d9470a0c-0011-4b25-b06f-1e7c96a7fc87@intel.com \
    --to=shekhar.chauhan@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=matthew.s.atwood@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox