On Mon, Feb 10, 2025 at 10:02:58PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 10, 2025 at 12:10:56PM -0600, Lucas De Marchi wrote:
> > On Mon, Feb 10, 2025 at 06:16:58PM +0200, Ville Syrjälä wrote:
> > >On Fri, Feb 07, 2025 at 04:41:11PM -0600, Lucas De Marchi wrote:
> > >> On Fri, Feb 07, 2025 at 11:54:03PM +0200, Ville Syrjälä wrote:
> > >> >From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > >> >
> > >> >Something has changed in the hardware on LNL/BMG because
> > >> >HDMI outputs no longer have the extra scanline offset.
> > >> >
> > >> >I confirmed that MTL still has the old behaviour, which
> > >> >is a bit weird since both MTL and BMG have display ver 14
> > >> >vs. LNL is version 20. But can't argue with actual
> > >> >hardware behaviour.
> > >>
> > >> <6>[ 210.368608] xe 0000:03:00.0: [drm] Found battlemage (device ID e20b) discrete display version 14.01 stepping B0
> > >> vs
> > >> <6>[ 412.999204] i915 0000:00:02.0: [drm] Found meteorlake (device ID 7d55) integrated display version 14.00 stepping C0
> > >>
> > >> So 14.01 vs 14.00. In the driver:
> > >>
> > >> static const struct {
> > >> u16 ver;
> > >> u16 rel;
> > >> const struct intel_display_device_info *display;
> > >> } gmdid_display_map[] = {
> > >> { 14, 0, &xe_lpdp_display },
> > >> { 14, 1, &xe2_hpd_display },
> > >> ...
> > >> }
> > >>
> > >> So maybe we need to check for the full version >= 1401 instead?
> > >
> > >Just another pointless detail I don't want to have to remember.
> >
> > we don't need the pointless update to the driver X months/years from now
> > when another platform uses the same IP.
>
> We have no idea if details like this have anything to do with the
> IP version. And in fact we have no idea idea about that for most
> details since the spec doesn't actually specify any of that.
> The only thing you can really trust when reding bspec is the
> platform.
This all fundamentally changed with MTL and its related IP blocks (not
just at the driver level, but across the whole Intel organization
workflow). Aside from some special cases that are tied to the SoC
rather than display design, display hardware changes are no longer
designed and defined against specific platforms. Instead the whole
process happens on a specific IP branch, identified by a number like
14.00, 14.01, or 20.00. The binding of IP branches to specific
platform(s) (or SKUs) is something that happens separately and may or
may not change over time as new platforms/SKUs come out; some which may
or may not use a new branch vs reuse an existing one.
If you dig into it, the pages and various changes in the bspec aren't
truly tagged to platforms anymore; instead they're tagged with something
that only ties back to the IP branch and version number. For historical
reasons the bspec tool tries to be "helpful" by attempting to do a
mapping of IP -> platform when it shows the labels, although the reality
is that this "helpful" part seems to just cause more confusion than it's
worth given the modern mix-and-match way IPs get used in platforms.
Supposedly the bspec is eventually supposed to start showing/filtering
based on IP rather than platform, which will more accurately reflect how
drivers are actually supposed to be implemented these days.
The special cases that are still tied to a specific platform's SoC tend
to be the physical/electrical characteristics like memory bandwidth,
voltage levels, etc.
Matt
>
> You can try to work backwards by first checking basically
> all the platforms, and then trying to see if there's some common
> IP version among them, and no other platform has that same
> IP version. But it'll still be just a guess, and based on past
> experience it's probably going to break as soon as the next
> random derivative platform comes along.
>
> > >Also it's already a huge pain in the backside trying to figure out
> > >what new platform has what display ip. Someone really needs to at
> > >least document this properly. Or perhaps we should just put the
> > >expected display ip version back into the platform definition and
> > >then just double check that the version we read from the GMD thing
> > >matches our expectations.
> >
> > there's this indirection with gmdid_display_map and name of the IP, but
> > other than that it's pretty much discoverable. From the bspec pov it's
> > all in the configuration page for the platform and you don't even need
> > the IP name. Example: 70821.
>
> But you can't even filter on the IP version number, and filtering
> is the only way to make any sense of anything these days. Ie.
> the only thing you can actually trust is the platform name.
>
> Also no one wants to have to open up all those pages for most
> platforms every time just to figure out which platforms have
> which IP version. We should just keep that information in the
> code so that you don't have to go through all that pain every
> single time.
>
> >
> > >
> > >Until the hardware people get their act together and the display ip
> > >version actually has some real meaning we shouldn't use it outside
> > >the major version IMO.
> >
> > it already does.
>
> As I said, the spec doesn't tell us anything about what's supported
> and/or broken on each IP version number. So it's all just guesswork.
>
> > ver.rel is what we need from the gmdid here. And it's
> > used on the graphics/media side as well:
> >
> > git grep VERx100 -- drivers/gpu/drm/xe
>
> Every time I see that crap I get super annoyed. I know which
> platorm I'm working on, I don't want to have to figure out
> all the different minor IP versions that it may or may not have,
> or what other platforms may or may not have those as well.
>
> Major numbers I think we can sort of use because those generally
> do map fairly well to actual features (though there are tons of
> exceptions to that rule all over the place as well).
>
> --
> Ville Syrjälä
> Intel
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
