On 2020-06-30 14:04, Hanjun Guo wrote:
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by their ACPI parent device. Do you see/Have you
found any issue with this approach ?
The spec says "Describes the IO relationships between devices
represented in the ACPI namespace.", and in section 3.1.1.3 Named
component node, it says:
PCI devices aren't necessarily described in the ACPI namespace and we
still use IORT to describe them - through the RC node.
"Named component nodes are used to describe devices that are also
included in the Differentiated System Description Table (DSDT). See
[ACPI]."
So from my understanding, the IORT spec for now, can only do ID
translations for devices in the DSDT.
I think you can read this multiple ways but this patch does not
change this concept. What changes, is applying parent's node IORT
mapping to child nodes with no associated DSDT nodes, it is the
same thing we do with PCI and the _DMA method - we could update
the wording in the specs if that clarifies but I don't think this
deliberately disregards the specifications.
I agree, but it's better to update the wording of the spec.
For a platform device, if I use its parent's full path name for
its named component entry, then it will match, but this will violate
the IORT spec.
Can you elaborate on this please I don't get the point you
are making.
For example, device A is not described in DSDT so can't represent
as a NC node in IORT. Device B can be described in DSDT and it
is the parent of device A, so device B can be represented in IORT
with memory access properties and node flags with Substream width
and Stall supported info.
When we trying to translate device A's ID, we reuse all the memory
access properties and node flags from its parent (device B), but
will it the same?
I assume so why wouldn't it be ? Why would be describe them in
a parent-child relationship if that's not how the system looks like
in HW ?
The point I'm making is that I'm not sure all the memory access and
stall properties are the same for the parent and the device itself.
Is that even a valid case though? The principal thing we want to
accommodate here is when device B *is* the one accessing memory, either
because it is a bridge with device A sat behind it, or because device A
is actually just some logical function or subset of physical device B.
If the topology is such that device A is a completely independent device
with its own path to memory such that it could have different
properties, I would expect that it *should* be described in DSDT, and I
can't easily think of a good reason why it wouldn't be. I'm also
struggling to imagine how it might even have an ID that had to be
interpreted in the context of device B if it wasn't one of the cases
above :/
I don't doubt that people could - or maybe even have - come up with crap
DSDT bindings that don't represent the hardware sufficiently accurately,
but I'm not sure that should be IORT's problem...
Robin.
Do you have a specific example in mind that we should be aware of ?
So the IORT spec don't support this, at least it's pretty vague
I think.
I think that's a matter of wording, it can be updated if it needs be,
reach out if you see any issue with the current approach please.
If the all the properties for parent and device itself are the same,
I have no strong opinion for this patch, but it's better to update
the wording of the spec as well.
Thanks
Hanjun
