[Intel-xe] [PATCH 0/6] Begin adding GMD_ID support for Xe

[Lucas De Marchi]

On Mon, Apr 03, 2023 at 01:16:56PM -0700, Matt Roper wrote:
>As Intel GPUs move toward chiplet-based designs with disaggregated IP
>blocks, it's no longer considered correct to determine platform IP
>versions and most of the behavior/capabilities based on a simple PCI
>devid/revid lookup.  From Meteor Lake onward, the driver is instead
>expected to identify the specific IP blocks present on the platform by
>reading GMD_ID registers that provide the version/stepping of each unit.
>PCI IDs should only be used in the rare cases where the driver needs to
>identify the SoC and its characteristics.  Going forward, we could
>theoretically see products mixing and matching chiplets in ways that
>cross the traditional platform boundaries (e.g., it would be possible
>for a "MTL" to show up with a future graphics and/or media IP chiplet,
>or it would be possible for some future platform to directly reuse a
>graphics and/or media chiplet from MTL).  In the long term we can no
>longer rely on PCI IDs to properly reflect these types of cases.

humn... I'm not sure about this reasoning since the platform would still
be called SOMETHING and that SOMETHING could have display 14.0,
graphics 18.0, media 16.0, etc (number are just example, not a future
anything). It's still a platform that needs to have unique PCI ID.

>
>This series provides the initial framework for GMD_ID matching.  The
>xe_device_desc structures used to describe platforms are broken up so
>that most of the important characteristics now reside in separate
>xe_graphics_desc and xe_media_desc structures for each IP rather than in
>the platform-level structure.  PCI devid matching will still happen at
>probe and will operate mostly unchanged on pre-MTL platforms where the
>xe_device_desc will point directly at the appropriate xe_graphics_desc
>and xe_media_desc descriptors.  However on MTL and beyond, the
>xe_device_desc structure associated with a PCI ID will initially just
>point at generic pair of descriptors with no real feature flags set,
>indicating that true matching needs to happen based on GMD_ID readout.


one thing that will be good here is to be able to pass 0 as the arg in
the pciidlist. By doing that we basically allow binding to a device
without requiring the driver_data to point to memory address, which
means we can bind via sysfs.  I think this would even give the
opportunity to sunset force_probe and provide a better way for
experimental platform support.



>The driver will then read the appropriate GMD_ID registers and select
>the corresponding set of feature flags to use, independently of the base
>platform.
>
>MTL still isn't loading and running properly on the Xe driver, so this
>is only lightly tested; with these patches the driver seems to identify
>the IP versions correctly (already more correctly than the old
>PCI-matching code did) and pick the correct set of feature flags before
>the load fails for other pre-existing reasons.
>
>Note that there's still more work to be done in this area after this
>series:
> - Most subplatform matching (e.g., MTL-M vs MTL-P) should also be tied
>   to GMD_ID rather than PCI ID.
> - Graphics/Media stepping information also comes from GMD_ID; PCI revid
>   should only be used to identify the SoC stepping (which is seldom
>   used by the driver).
> - Various places in the driver that match a platform directly will need
>   to be updated to match on the IP version instead.  Some examples
>   would be places like GuC firmware loading or workaround definition,
>   where we only care about the graphics chiplet, not the base platform
>   it happens to be plugged into.

this is what bothers me. If we try to retrofit this into e.g. DG2, I
think we are going to make it harder to read. The WAs are defined per
platform. It's harder to get a platform definition, decode on what is
the DISPLAY/GRAPHICS/etc it's using, based on what is the register it
needs to set or what are the WA details, just to write it based on IP
rather the platform

> - i915 has basic GMD_ID support for version identification, but needs
>   similar reworks to select feature flags based on the GMD_ID.  Since

since we are plumbing the next platforms here, why  bother with i915
now?

>   Xe recycles i915's display code, these i915 updates will be needed to
>   fully handle display IP matching properly.

but it's only the display part....

Anyway, just wanted to give a general feedback on the cover. I'm yet to
read the patches.

thanks
Lucas De Marchi

>
>
>Matt Roper (6):
>  drm/xe: Start splitting xe_device_desc into graphics/media structures
>  drm/xe: Set require_force_probe in each platform's description
>  drm/xe: Move most platform traits to graphics IP
>  drm/xe: Move engine masks into IP descriptor structures
>  drm/xe: Clarify GT counting logic
>  drm/xe: Select graphics/media descriptors from GMD_ID
>
> drivers/gpu/drm/xe/regs/xe_gt_regs.h |   6 +
> drivers/gpu/drm/xe/xe_pci.c          | 432 ++++++++++++++++++---------
> 2 files changed, 300 insertions(+), 138 deletions(-)
>
>-- 
>2.39.2
>