On Thu, Sep 07, 2023 at 05:57:19PM -0700, Matt Roper wrote:
On Thu, Sep 07, 2023 at 03:43:59PM -0500, Lucas De Marchi wrote:
On Thu, Sep 07, 2023 at 10:04:42AM -0700, Matt Roper wrote:
> On Thu, Sep 07, 2023 at 08:37:35AM -0700, Lucas De Marchi wrote:
> > From: Gustavo Sousa <gustavo.sousa@xxxxxxxxx>
> >
> > Xe2_LPD has sourth display on the same SOC. As such, define a new fake
>
> s/sourth/south/
>
> You might also want to drop the word "same" from the description here
> since NDE and SDE are technically on different dies in this case (NDE is
> on the compute die, whereas SDE is on the SoC die). To be 100% accurate
> we'd want to identify SDE behavior via the PICA's GMD_ID (since PICA
> also lives on the SoC die for this platform). But since we've just been
I'd not re-architect this based on where the PICA lives as it seems very
easy to change in future.... tying the SDE behavior to the PICA behavior
because they are on the same die, doesn't seem very future proof.
The point is that tying it to any one thing for every platform is
incorrect; figuring out a) which die is relevant to SDE behavior and b)
how to fingerprint the variant and stepping of that die is very platform
specific. Art specifically suggested using the PICA ID in cases where
the PICA lives on the die that we need to fingerprint but the NDE does
not. But again, that's not a silver bullet that can be used on every
single platform. Nor is using the ISA bus ID like we've done for a long
time. Nor is using the display version. Nor is using just the PCI ID.
There's no single answer here, which is why we need a major rethink of
this contradicts what you said above that "To be 100% accurate we'd want
to identify SDE behavior via the PICA's GMD_ID". That is not true because
if what you are using to fingerprint SDE's behavior change from platform
to platform, then you can't decide anymore on what to use to fingerprint
it. At that point we'd better request a SDE id to be added.
our strategy at some point in the future. But that overhaul can wait
for a future series; I just want to make sure that the commit messages
here aren't causing further confusion.
Here the real reason for the change is that from the SW perspective they
are under the same PCI device and there's no reason to look for a
different one. Maybe rewording it a "Xe2_LPD has south display on the
same PCI device" would be simpler?
No, that would be even less correct; PCI device isn't really related to
any of this. Obviously at the register level, everything our driver
cares about (NDE, SDE, GT, etc.) is accessed through the same PCI device
(e.g., 00:02.0 on an igpu). Under the hood the various pieces of that
PCI device (NDE, SDE, render GT, media GT, etc.) might be located
together on a single chip, or may be spread across different dies. When
spread across different dies, those dies can be mixed-and-matched in
various ways (and it seems like hardware design is trending toward more
flexibility in mix-and-match).
The register interface to the SDE (i.e., which registers exist and what
bitfields they have inside) hasn't had any meaningful changes in a long
time. And if it does change in the future, the _interface_ changes are
probably more tied to the display IP version than to anything else.
However there's some important SDE handling that the driver needs to do
that may vary based on the identity of the specific die that's
responsible for doing SDE I/O on a given platform. I.e., there may be
which only happens to be on the same die where PICA is. *On LNL*.
I/O-related defects+workarounds that require special SDE programming
when a certain die variant and/or stepping is present. There can also
be differences in how lanes are physically wired up, resulting in pin
mapping changes. In these cases we need to be able to fingerprint the
identity of the specific die handling the I/O (which might be a compute
die, an SoC die, and IOE die, a PCH die, etc.) and make our decisions
accordingly. If the SDE I/O happens on the same die as the north
display functionality, then using the display version might be an
effective way to fingerprint. If the SDE I/O happens on a different die
from the NDE, but on the same die the PICA lives on, the display
architects suggested using the PICA ID in that case. If neither of
those cases are true, then we may need to look at PCI IDs or something.
I think that's a different read of what was discussed. My read was more
in the lines of "if you really need that, you can use the PICA ID". With
no guarantee of this being future-proof. That's why we decided it made
no sense to change now.
In the past, the PCH was often where the SDE I/O responsibility was so
we needed a way to identify exactly which PCH variant was present. The
"PCH ID" that we try to match on during driver startup is entirely
unrelated to the SDE; it's just a random bus that we know was always
part of every PCH and always present in the same predictable PCI slot,
so it's handy for identification purposes. The fact that we're still
looking at the ISA bus on MTL today is 100% wrong because most (maybe
I agree here: MTL shouldn't be using that just like LNL is not.
all?) MTL platforms don't even have a PCH (so that ISA bus might be on a
different die that we really don't care about at all). For MTL I
believe the NDE and the SDE's I/O are both on the same SoC die, so we
should really just be making our decisions based on IP version and/or
graphics device ID. If I remember correctly, LNL moved the NDE display
to the compute die, but left the PICA on the SoC die. So assuming the
SoC die is still where the I/O happens (I don't have the platform docs
open at the moment), the PICA ID could potentially be used to
fingerprint the die for the purposes of die-specific workarounds. It
might even vary between different SKUs of LNL, MTL, etc. so we really
need to dig into the platform specs to figure out the right course of
action (the graphics bspec doesn't cover that high-level platform
layout).
That's where we disagree... you seem to prefer it more fine grained
while I'm perfectly happy with keeping it simpler and coarse until
the day we need it. For LNL we have Panel Control, GMBUS DDC, HPD, SDE
interrupts, GPSB, TCSS, PHYs and PICA on the SoC die, but those
IO interfaces could very well be on a separate die
I think we have to agree to disagree here and move on. What about the
following?
drm/i915/xe2lpd: Add fake PCH
Xe2_LPD doesn't have south display engine on a PCH, it's actually
on the SoC die (while north display engine is on compute die). As
such it makes no sense to go through the PCI devices looking for
an ISA bridge.
For the places we currently use a PCH check, it's enough for
now to just check the north display version. Use that to define
a fake PCH to be used across the driver.
Lucas De Marchi
