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.
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
