Clarify and illustrate use of vendor-defined data in ACPI graph link description
Closed this issue · 1 comments
The use of vendor-defined data in the ACPI graph Link descriptor is permitted by the current version of the implementation guide, but lacks clarity or details. There is at least one related specification from Arm (see document number DEN0067), where vendor-defined data is being defined and used.
The guide lacks details on how such vendor-defined data could be used in actual practice.
This change request provides clarifying text required to Sections 3.3.1 and 3.3.2 to address this lack of information:
Change 1: Section 3.3.1
Existing text:
"A Link Package may be extended with additional vendor defined data.
The Graph specification determines how that data is to be interpreted."
to:
"A Link Package may be extended with additional vendor defined data.
The Graph specification determines how that data is to be interpreted.
Package () {
SourcePortAddress, // Integer
DestinationPortAddress, // Integer
DestinationDeviceName, // Reference to another
// device in the name space
}
It is up to the device driver to interpret and use the additional data using
the vendor provided specification."
Change 2: Section 3.3.2
From:
"DevicesABC, GHI and JKL are interconnected in a second graph
topology."
to:
"Devices ABC, GHI and JKL are interconnected in a second graph
topology. The links in the second graph require specifying a
latency parameter associated with the link."
Change 3: Section 3.3.2
From:
"
Scope (_SB) {
Device (ABC) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),
Package() {
0, // Revision
2, // NumberOfGraphs
Package() {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch’’),
2, // Number of links
Package (3) {0,3,_SB.DEF},
Package (3) {1,10,_SB.GHI}
},
Package() {
2, // GraphID - Graph 2
ToUUID(‘‘UUID_For_Graph_Arch’’),
1, // Number of links
Package (3) {2,380,_SB.JKL}
}
},
})
...
Device (DEF) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),
Package() {
0, // Revision
1, // NumberOfGraphs
Package() {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch’’),
1, // Number of links
Package (3) {5,20,\_SB.GHI}
}
}
})
...
}
Device (GHI) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),Package() {
0, // Revision
2, // NumberOfGraphs
Package () {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch’’),
1, // Number of links
Package (3) {10,1,\_SB.ABC}
},
Package() {
2, // GraphID - Graph 2
ToUUID(‘‘UUID_For_Graph_Arch’’),
1, // Number of links
Package (3) {30,210,\_SB.JKL}
}
}
})
...
}
}
"
to:
"
Scope (_SB) {
Device (ABC) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),
Package() {
0, // Revision
2, // NumberOfGraphs
Package() {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch_1’’),
2, // Number of links
Package (3) {0,3,_SB.DEF},
Package (3) {1,10,_SB.GHI}
},
Package() {
2, // GraphID - Graph 2
ToUUID(‘‘UUID_For_Graph_Arch_2’’),
1, // Number of links
Package (3) {2,380,_SB.JKL, L1} // Latency L1
}
},
})
...
Device (DEF) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),
Package() {
0, // Revision
1, // NumberOfGraphs
Package() {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch_1’’),
1, // Number of links
Package (3) {5,20,\_SB.GHI}
}
}
})
...
}
Device (GHI) {
...
Name (_DSD, Package () {
ToUUID("ab02a46b-74c7-45a2-bd68-f7d344ef2153"),Package() {
0, // Revision
2, // NumberOfGraphs
Package () {
1, // GraphID - Graph 1
ToUUID(‘‘UUID_For_Graph_Arch_1’’),
1, // Number of links
Package (3) {10,1,\_SB.ABC}
},
Package() {
2, // GraphID - Graph 2
ToUUID(‘‘UUID_For_Graph_Arch_2’’),
1, // Number of links
Package (3) {30,210,\_SB.JKL, L2} // Latency L2
}
}
})
...
}
}
"
Change 4: Updated Figure showing the example graph described by the ASL code
Please see attached image file.
This was approved by ASWG on 5/5 meeting. Merging and closing the issue.