On Fri, 17 Nov 2023, Lucas De Marchi <lucas.demar...@intel.com> wrote: > On Mon, Jan 30, 2023 at 03:38:05PM +0530, Chaitanya Kumar Borah wrote: >>Separate out RPLU device ids and add them to both RPL and >>newly created RPL-U subplatforms. >> >>v2: (Matt) >> - Sort PCI-IDs numerically >> - Name the sub-platform to accurately depict what it is for >> - Make RPL-U part of RPL subplatform >> >>v3: revert to RPL-U subplatform (Jani) >> >>v4: (Jani) >> - Add RPL-U ids to RPL-P platform > > humn... > >>diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h >>index 4a4c190f7698..5824e1d7d162 100644 >>--- a/include/drm/i915_pciids.h >>+++ b/include/drm/i915_pciids.h >>@@ -684,14 +684,18 @@ >> INTEL_VGA_DEVICE(0xA78A, info), \ >> INTEL_VGA_DEVICE(0xA78B, info) >> >>+/* RPL-U */ >>+#define INTEL_RPLU_IDS(info) \ >>+ INTEL_VGA_DEVICE(0xA721, info), \ >>+ INTEL_VGA_DEVICE(0xA7A1, info), \ >>+ INTEL_VGA_DEVICE(0xA7A9, info) >>+ >> /* RPL-P */ >> #define INTEL_RPLP_IDS(info) \ >>+ INTEL_RPLU_IDS(info), \ > > drive by comment while reviewing other stuff. Why was U added to the > P macro? That looks odd. Adding it to the rpl subplatform, together with P > would > be ok, but in this macro it looks wrong. Doing it the other way I think the > only affected place would be the early-quirks, which would need a separate > entry, > but admitedly they should had been INTEL_RPL_IDS() with all the > variants.
It's been 10 months, I have no recollection, but this is what I found in old mails [1]. BR, Jani. [1] https://lore.kernel.org/r/87mt686m1o....@intel.com > > > Lucas De Marchi -- Jani Nikula, Intel
