XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..ab5041db731a 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -109,7 +109,7 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM 0x00000000, // Granularity 0x5f800000, // Min Base Address 0x5fffffff, // Max Base Address - 0x5f800000, // Translate + 0x00000000, // Translate 0x00800000 // Length ) }) // Name(RBUF)
The ACPI spec predates the AARCH64 architecture by 5 versions, so there is no point in supporting anything below v5.0. So set the PCD that controls the ACPI table generation to the appropriate value.
Based on the commit e0692789058e ("ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher") in the upstream TianoCore by Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/ArmJuno.dsc | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc index aef4c2167a1e..d961fd41be18 100644 --- a/Platforms/ARM/Juno/ArmJuno.dsc +++ b/Platforms/ARM/Juno/ArmJuno.dsc @@ -173,6 +173,8 @@ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20 + [PcdsPatchableInModule] # Console Resolution (Full HD) gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
The ACPI spec predates the AARCH64 architecture by 5 versions, so there is no point in supporting anything below v5.0. So set the PCD that controls the ACPI table generation to the appropriate value.
Based on the commit e0692789058e ("ArmVirtPkg/ArmVirtQemu: limit ACPI support to v5.0 and higher") in the upstream TianoCore by Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Reviewed-by: Ard Biesheuvel ard.biesheuvel@linaro.org
Platforms/ARM/Juno/ArmJuno.dsc | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc index aef4c2167a1e..d961fd41be18 100644 --- a/Platforms/ARM/Juno/ArmJuno.dsc +++ b/Platforms/ARM/Juno/ArmJuno.dsc @@ -173,6 +173,8 @@ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
- gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
[PcdsPatchableInModule] # Console Resolution (Full HD) gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920 -- 1.9.1
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate method to describe processor idle states.
LPI extensions leverages the processor container device(again introduced in ACPI 6.0) allowing to express which parts of the system are affected by a given LPI state. It defines the local power states for each node in a hierarchical processor topology. The OSPM can use _LPI object to select a local power state for each level of processor hierarchy in the system.
This patch adds LPI support on Juno.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/AcpiTables/Dsdt.asl | 232 ++++++++++++++++++++++++++++++--- 1 file changed, 213 insertions(+), 19 deletions(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/Dsdt.asl b/Platforms/ARM/Juno/AcpiTables/Dsdt.asl index c80f46a4ce64..3247e6b12aa5 100644 --- a/Platforms/ARM/Juno/AcpiTables/Dsdt.asl +++ b/Platforms/ARM/Juno/AcpiTables/Dsdt.asl @@ -19,29 +19,223 @@ DefinitionBlock("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_O // // A57x2-A53x4 Processor declaration // - Device(CPU0) { // A53-0: Cluster 1, Cpu 0 - Name(_HID, "ACPI0007") - Name(_UID, 0) + Method (_OSC, 4, Serialized) { // _OSC: Operating System Capabilities + CreateDWordField (Arg3, 0x00, STS0) + CreateDWordField (Arg3, 0x04, CAP0) + If ((Arg0 == ToUUID ("0811b06e-4a27-44f9-8d60-3cbbc22e7b48") /* Platform-wide Capabilities */)) { + If (!(Arg1 == One)) { + STS0 &= ~0x1F + STS0 |= 0x0A + } Else { + If ((CAP0 & 0x100)) { + CAP0 &= ~0x100 /* No support for OS Initiated LPI */ + STS0 &= ~0x1F + STS0 |= 0x12 + } + } + } Else { + STS0 &= ~0x1F + STS0 |= 0x06 + } + Return (Arg3) } - Device(CPU1) { // A53-1: Cluster 1, Cpu 1 - Name(_HID, "ACPI0007") + Device (CLU0) { // Cluster0 state + Name(_HID, "ACPI0010") Name(_UID, 1) + Name (_LPI, Package() { + 0, // Version + 0, // Level Index + 1, // Count + Package() { // Power Gating state for Cluster + 2500, // Min residency (uS) + 1150, // Wake latency (uS) + 1, // Flags + 1, // Arch Context Flags + 100, //Residency Counter Frequency + 0, // No Parent State + 0x01000000, // Integer Entry method + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "CluPwrDn" + }, + }) + Name(PLPI, Package() { + 0, // Version + 1, // Level Index + 2, // Count + Package() { // WFI for CPU + 1, // Min residency (uS) + 1, // Wake latency (uS) + 1, // Flags + 0, // Arch Context Flags + 100, //Residency Counter Frequency + 0, // No parent state + ResourceTemplate () { + // Register Entry method + Register (FFixedHW, + 0x20, // Bit Width + 0x00, // Bit Offset + 0xFFFFFFFF, // Address + 0x03, // Access Size + ) + }, + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "WFI", + }, + Package() { // Power Gating state for CPU + 150, // Min residency (uS) + 350, // Wake latency (uS) + 1, // Flags + 1, // Arch Context Flags + 100, //Residency Counter Frequency + 1, // Parent node can be in any state + ResourceTemplate () { + // Register Entry method + Register (FFixedHW, + 0x20, // Bit Width + 0x00, // Bit Offset + 0x00010000, // Address + 0x03, // Access Size + ) + }, + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "CorePwrDn" + }, + }) + Device(CPU0) { // A57-0: Cluster 0, Cpu 0 + Name(_HID, "ACPI0007") + Name(_UID, 4) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } + Device(CPU1) { // A57-1: Cluster 0, Cpu 1 + Name(_HID, "ACPI0007") + Name(_UID, 5) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } } - Device(CPU2) { // A53-2: Cluster 1, Cpu 2 - Name(_HID, "ACPI0007") + Device (CLU1) { // Cluster1 state + Name(_HID, "ACPI0010") Name(_UID, 2) - } - Device(CPU3) { // A53-3: Cluster 1, Cpu 3 - Name(_HID, "ACPI0007") - Name(_UID, 3) - } - Device(CPU4) { // A57-0: Cluster 0, Cpu 0 - Name(_HID, "ACPI0007") - Name(_UID, 4) - } - Device(CPU5) { // A57-1: Cluster 0, Cpu 1 - Name(_HID, "ACPI0007") - Name(_UID, 5) + Name (_LPI, Package() { + 0, // Version + 0, // Level Index + 1, // Count + Package() { // Power Gating state for Cluster + 2500, // Min residency (uS) + 1150, // Wake latency (uS) + 1, // Flags + 1, // Arch Context Flags + 100, //Residency Counter Frequency + 0, // No Parent State + 0x01000000, // Integer Entry method + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "CluPwrDn" + }, + }) + Name(PLPI, Package() { + 0, // Version + 1, // Level Index + 2, // Count + Package() { // WFI for CPU + 1, // Min residency (uS) + 1, // Wake latency (uS) + 1, // Flags + 0, // Arch Context Flags + 100, //Residency Counter Frequency + 0, // No parent state + ResourceTemplate () { + // Register Entry method + Register (FFixedHW, + 0x20, // Bit Width + 0x00, // Bit Offset + 0xFFFFFFFF, // Address + 0x03, // Access Size + ) + }, + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "WFI", + }, + Package() { // Power Gating state for CPU + 150, // Min residency (uS) + 350, // Wake latency (uS) + 1, // Flags + 1, // Arch Context Flags + 100, //Residency Counter Frequency + 1, // Parent node can be in any state + ResourceTemplate () { + // Register Entry method + Register (FFixedHW, + 0x20, // Bit Width + 0x00, // Bit Offset + 0x00010000, // Address + 0x03, // Access Size + ) + }, + ResourceTemplate() { // Null Residency Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + ResourceTemplate() { // Null Usage Counter + Register (SystemMemory, 0, 0, 0, 0) + }, + "CorePwrDn" + }, + }) + Device(CPU2) { // A53-0: Cluster 1, Cpu 0 + Name(_HID, "ACPI0007") + Name(_UID, 0) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } + Device(CPU3) { // A53-1: Cluster 1, Cpu 1 + Name(_HID, "ACPI0007") + Name(_UID, 1) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } + Device(CPU4) { // A53-2: Cluster 1, Cpu 2 + Name(_HID, "ACPI0007") + Name(_UID, 2) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } + Device(CPU5) { // A53-3: Cluster 1, Cpu 3 + Name(_HID, "ACPI0007") + Name(_UID, 3) + Method (_LPI, 0, NotSerialized) { + return(PLPI) + } + } }
//
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate method to describe processor idle states.
LPI extensions leverages the processor container device(again introduced in ACPI 6.0) allowing to express which parts of the system are affected by a given LPI state. It defines the local power states for each node in a hierarchical processor topology. The OSPM can use _LPI object to select a local power state for each level of processor hierarchy in the system.
This patch adds LPI support on Juno.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
As for patch #1, I cannot review or test this.
Platforms/ARM/Juno/AcpiTables/Dsdt.asl | 232 ++++++++++++++++++++++++++++++--- 1 file changed, 213 insertions(+), 19 deletions(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/Dsdt.asl b/Platforms/ARM/Juno/AcpiTables/Dsdt.asl index c80f46a4ce64..3247e6b12aa5 100644 --- a/Platforms/ARM/Juno/AcpiTables/Dsdt.asl +++ b/Platforms/ARM/Juno/AcpiTables/Dsdt.asl @@ -19,29 +19,223 @@ DefinitionBlock("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_O // // A57x2-A53x4 Processor declaration //
- Device(CPU0) { // A53-0: Cluster 1, Cpu 0
Name(_HID, "ACPI0007")Name(_UID, 0)
- Method (_OSC, 4, Serialized) { // _OSC: Operating System Capabilities
CreateDWordField (Arg3, 0x00, STS0)CreateDWordField (Arg3, 0x04, CAP0)If ((Arg0 == ToUUID ("0811b06e-4a27-44f9-8d60-3cbbc22e7b48") /* Platform-wide Capabilities */)) {If (!(Arg1 == One)) {STS0 &= ~0x1FSTS0 |= 0x0A} Else {If ((CAP0 & 0x100)) {CAP0 &= ~0x100 /* No support for OS Initiated LPI */STS0 &= ~0x1FSTS0 |= 0x12}}} Else {STS0 &= ~0x1FSTS0 |= 0x06}Return (Arg3)
- Device(CPU1) { // A53-1: Cluster 1, Cpu 1
Name(_HID, "ACPI0007")
- Device (CLU0) { // Cluster0 state
Name(_HID, "ACPI0010") Name(_UID, 1)Name (_LPI, Package() {0, // Version0, // Level Index1, // CountPackage() { // Power Gating state for Cluster2500, // Min residency (uS)1150, // Wake latency (uS)1, // Flags1, // Arch Context Flags100, //Residency Counter Frequency0, // No Parent State0x01000000, // Integer Entry methodResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"CluPwrDn"},})Name(PLPI, Package() {0, // Version1, // Level Index2, // CountPackage() { // WFI for CPU1, // Min residency (uS)1, // Wake latency (uS)1, // Flags0, // Arch Context Flags100, //Residency Counter Frequency0, // No parent stateResourceTemplate () {// Register Entry methodRegister (FFixedHW,0x20, // Bit Width0x00, // Bit Offset0xFFFFFFFF, // Address0x03, // Access Size)},ResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"WFI",},Package() { // Power Gating state for CPU150, // Min residency (uS)350, // Wake latency (uS)1, // Flags1, // Arch Context Flags100, //Residency Counter Frequency1, // Parent node can be in any stateResourceTemplate () {// Register Entry methodRegister (FFixedHW,0x20, // Bit Width0x00, // Bit Offset0x00010000, // Address0x03, // Access Size)},ResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"CorePwrDn"},})Device(CPU0) { // A57-0: Cluster 0, Cpu 0Name(_HID, "ACPI0007")Name(_UID, 4)Method (_LPI, 0, NotSerialized) {return(PLPI)}}Device(CPU1) { // A57-1: Cluster 0, Cpu 1Name(_HID, "ACPI0007")Name(_UID, 5)Method (_LPI, 0, NotSerialized) {return(PLPI)}}
- Device(CPU2) { // A53-2: Cluster 1, Cpu 2
Name(_HID, "ACPI0007")
- Device (CLU1) { // Cluster1 state
Name(_HID, "ACPI0010") Name(_UID, 2)
- }
- Device(CPU3) { // A53-3: Cluster 1, Cpu 3
Name(_HID, "ACPI0007")Name(_UID, 3)- }
- Device(CPU4) { // A57-0: Cluster 0, Cpu 0
Name(_HID, "ACPI0007")Name(_UID, 4)- }
- Device(CPU5) { // A57-1: Cluster 0, Cpu 1
Name(_HID, "ACPI0007")Name(_UID, 5)
Name (_LPI, Package() {0, // Version0, // Level Index1, // CountPackage() { // Power Gating state for Cluster2500, // Min residency (uS)1150, // Wake latency (uS)1, // Flags1, // Arch Context Flags100, //Residency Counter Frequency0, // No Parent State0x01000000, // Integer Entry methodResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"CluPwrDn"},})Name(PLPI, Package() {0, // Version1, // Level Index2, // CountPackage() { // WFI for CPU1, // Min residency (uS)1, // Wake latency (uS)1, // Flags0, // Arch Context Flags100, //Residency Counter Frequency0, // No parent stateResourceTemplate () {// Register Entry methodRegister (FFixedHW,0x20, // Bit Width0x00, // Bit Offset0xFFFFFFFF, // Address0x03, // Access Size)},ResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"WFI",},Package() { // Power Gating state for CPU150, // Min residency (uS)350, // Wake latency (uS)1, // Flags1, // Arch Context Flags100, //Residency Counter Frequency1, // Parent node can be in any stateResourceTemplate () {// Register Entry methodRegister (FFixedHW,0x20, // Bit Width0x00, // Bit Offset0x00010000, // Address0x03, // Access Size)},ResourceTemplate() { // Null Residency CounterRegister (SystemMemory, 0, 0, 0, 0)},ResourceTemplate() { // Null Usage CounterRegister (SystemMemory, 0, 0, 0, 0)},"CorePwrDn"},})Device(CPU2) { // A53-0: Cluster 1, Cpu 0Name(_HID, "ACPI0007")Name(_UID, 0)Method (_LPI, 0, NotSerialized) {return(PLPI)}}Device(CPU3) { // A53-1: Cluster 1, Cpu 1Name(_HID, "ACPI0007")Name(_UID, 1)Method (_LPI, 0, NotSerialized) {return(PLPI)}}Device(CPU4) { // A53-2: Cluster 1, Cpu 2Name(_HID, "ACPI0007")Name(_UID, 2)Method (_LPI, 0, NotSerialized) {return(PLPI)}}Device(CPU5) { // A53-3: Cluster 1, Cpu 3Name(_HID, "ACPI0007")Name(_UID, 3)Method (_LPI, 0, NotSerialized) {return(PLPI)}}}
//
-- 1.9.1
On 20/04/16 08:42, Ard Biesheuvel wrote:
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate method to describe processor idle states.
LPI extensions leverages the processor container device(again introduced in ACPI 6.0) allowing to express which parts of the system are affected by a given LPI state. It defines the local power states for each node in a hierarchical processor topology. The OSPM can use _LPI object to select a local power state for each level of processor hierarchy in the system.
This patch adds LPI support on Juno.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
As for patch #1, I cannot review or test this.
This currently can't be tested with mainline kernel yet. The patches to support this are still under review
On Wed, Apr 20, 2016 at 09:18:38AM +0100, Sudeep Holla wrote:
On 20/04/16 08:42, Ard Biesheuvel wrote:
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate method to describe processor idle states.
LPI extensions leverages the processor container device(again introduced in ACPI 6.0) allowing to express which parts of the system are affected by a given LPI state. It defines the local power states for each node in a hierarchical processor topology. The OSPM can use _LPI object to select a local power state for each level of processor hierarchy in the system.
This patch adds LPI support on Juno.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
As for patch #1, I cannot review or test this.
This currently can't be tested with mainline kernel yet. The patches to support this are still under review
So, should it be merged anyway, or will that break something? Regardless, sounds like it should be split from the preceding two patches.
/ Leif
On 22/04/16 17:51, Leif Lindholm wrote:
On Wed, Apr 20, 2016 at 09:18:38AM +0100, Sudeep Holla wrote:
On 20/04/16 08:42, Ard Biesheuvel wrote:
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate method to describe processor idle states.
LPI extensions leverages the processor container device(again introduced in ACPI 6.0) allowing to express which parts of the system are affected by a given LPI state. It defines the local power states for each node in a hierarchical processor topology. The OSPM can use _LPI object to select a local power state for each level of processor hierarchy in the system.
This patch adds LPI support on Juno.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
As for patch #1, I cannot review or test this.
This currently can't be tested with mainline kernel yet. The patches to support this are still under review
So, should it be merged anyway, or will that break something? Regardless, sounds like it should be split from the preceding two patches.
There's no urgency as the Linux patches are still under review. But I posted just to point people at examples for _LPI tables.
On 19 April 2016 at 17:11, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
I can't review or test this. Leif, Ryan?
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..ab5041db731a 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -109,7 +109,7 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM 0x00000000, // Granularity 0x5f800000, // Min Base Address 0x5fffffff, // Max Base Address
0x5f800000, // Translate
0x00000000, // Translate 0x00800000 // Length ) }) // Name(RBUF)-- 1.9.1
Jeremy - could you comment on this series?
On 19 April 2016 at 16:11, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..ab5041db731a 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -109,7 +109,7 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM 0x00000000, // Granularity 0x5f800000, // Min Base Address 0x5fffffff, // Max Base Address
0x5f800000, // Translate
0x00000000, // Translate 0x00800000 // Length ) }) // Name(RBUF)-- 1.9.1
On Tue, Apr 19, 2016 at 04:11:54PM +0100, Sudeep Holla wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..ab5041db731a 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -109,7 +109,7 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM 0x00000000, // Granularity 0x5f800000, // Min Base Address 0x5fffffff, // Max Base Address
0x5f800000, // Translate
0x00000000, // Translate 0x00800000 // Length ) }) // Name(RBUF)
I suspect the correct form here is
0x00000000, // Granularity 0x00000000, // Min Base Address 0x00ffffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length
In my understanding Min/Max are in terms of the IO ports and translation address is where in physical memory that set of IO ports is mapped.
Thanks
Graeme
On 20/04/16 14:34, Graeme Gregory wrote:
On Tue, Apr 19, 2016 at 04:11:54PM +0100, Sudeep Holla wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..ab5041db731a 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -109,7 +109,7 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM 0x00000000, // Granularity 0x5f800000, // Min Base Address 0x5fffffff, // Max Base Address
0x5f800000, // Translate
0x00000000, // Translate 0x00800000 // Length ) }) // Name(RBUF)I suspect the correct form here is
0x00000000, // Granularity 0x00000000, // Min Base Address 0x00ffffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length
In my understanding Min/Max are in terms of the IO ports and translation address is where in physical memory that set of IO ports is mapped.
Yes that makes sense. I recall now that I wanted to check what you are suggesting above after reading some private discussion on this. I never got around that and totally forgot.
I will give it a try. Thanks for reminding me.
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..5ff267fe5124 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,8 +107,8 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity - 0x5f800000, // Min Base Address - 0x5fffffff, // Max Base Address + 0x00000000, // Min Base Address + 0x000fffff, // Max Base Address 0x5f800000, // Translate 0x00800000 // Length )
On 20 April 2016 at 16:09, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v1->v2: - Made changes as suggested by Graeme & Tomasz
You may want to update the commit log as well
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..5ff267fe5124 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,8 +107,8 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity
0x5f800000, // Min Base Address0x5fffffff, // Max Base Address
0x00000000, // Min Base Address0x000fffff, // Max Base Address 0x5f800000, // Translate 0x00800000 // Length )-- 1.9.1
On 20/04/16 15:10, Ard Biesheuvel wrote:
On 20 April 2016 at 16:09, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initialises the root complex with the same source and target address for IO window which makes translate offset 0.
This patch fixes the translate offset for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v1->v2: - Made changes as suggested by Graeme & Tomasz
You may want to update the commit log as well
Ah right in fact $subject too :), it was stupid of me.
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v2->v3: - Fixed $subject and the commit log v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..5ff267fe5124 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,8 +107,8 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity - 0x5f800000, // Min Base Address - 0x5fffffff, // Max Base Address + 0x00000000, // Min Base Address + 0x000fffff, // Max Base Address 0x5f800000, // Translate 0x00800000 // Length )
On 20 April 2016 at 15:30, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
I have not tested it but diff looks good to me.
Reviewed-by: Graeme Gregory graeme.gregory@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v2->v3: - Fixed $subject and the commit log v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..5ff267fe5124 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,8 +107,8 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity
0x5f800000, // Min Base Address0x5fffffff, // Max Base Address
0x00000000, // Min Base Address0x000fffff, // Max Base Address 0x5f800000, // Translate 0x00800000 // Length )-- 1.9.1
On 20/04/16 15:39, G Gregory wrote:
On 20 April 2016 at 15:30, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
I have not tested it but diff looks good to me.
Ah crap, something really wrong today with me, I failed to notice that error UEFI is throwing with this change :(
uefi/Build/ArmJuno/RELEASE_GCC49/AARCH64/OpenPlatformPkg/Platforms/ARM/Juno/AcpiTables/AcpiTables/OUTPUT/./AcpiSsdtRootPci.iiii 60: 0x00800000 Error 6049 Length is larger than Min/Max window ^
On 04/20/2016 09:39 AM, G Gregory wrote:
On 20 April 2016 at 15:30, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
I have not tested it but diff looks good to me.
Reviewed-by: Graeme Gregory graeme.gregory@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
v2->v3: - Fixed $subject and the commit log v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..5ff267fe5124 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,8 +107,8 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity
0x5f800000, // Min Base Address0x5fffffff, // Max Base Address
0x00000000, // Min Base Address0x000fffff, // Max Base Address 0x5f800000, // Translate 0x00800000 // Length )
I believe you also need to specify type translate to indicate that the secondary side of the bridge is I/O. This part of the specification is entirely unclear and disagrees with itself depending on which version/paragraph of the specification you read. But the intent of that bit for both DwordMemory and DwordIO seems to indicate that an io/memory transaction is changing types when it crosses the bridge. That is true for ARM devices which are writing a MMIO and a PCIe IO transaction is being generated.
Also, are you sure that the length and min/max range should be different?
-- 1.9.1
edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
On 20/04/16 16:13, Jeremy Linton wrote:
On 04/20/2016 09:39 AM, G Gregory wrote:
On 20 April 2016 at 15:30, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
[...]
I believe you also need to specify type translate to indicate that the secondary side of the bridge is I/O. This part of the specification is entirely unclear and disagrees with itself depending on which version/paragraph of the specification you read. But the intent of that bit for both DwordMemory and DwordIO seems to indicate that an io/memory transaction is changing types when it crosses the bridge. That is true for ARM devices which are writing a MMIO and a PCIe IO transaction is being generated.
True, so what do you suggest ? How do we proceed on this then ?
Also, are you sure that the length and min/max range should be different?
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
On 20/04/16 16:13, Jeremy Linton wrote:
On 04/20/2016 09:39 AM, G Gregory wrote:
On 20 April 2016 at 15:30, Sudeep Holla sudeep.holla@arm.com wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table.
[...]
I believe you also need to specify type translate to indicate that the secondary side of the bridge is I/O. This part of the specification is entirely unclear and disagrees with itself depending on which version/paragraph of the specification you read. But the intent of that bit for both DwordMemory and DwordIO seems to indicate that an io/memory transaction is changing types when it crosses the bridge. That is true for ARM devices which are writing a MMIO and a PCIe IO transaction is being generated.
True, so what do you suggest ? How do we proceed on this then ?
Also, are you sure that the length and min/max range should be different?
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , , TypeTranslation )
Does that work with your tests? Its what I've been running on my machine for a couple months now, but I haven't really focused on testing it.
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation
... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
On 20/04/16 16:54, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
I must have seen spec before replying to you :( It states:
"TranslationType is an optional argument that specifies whether the resource type on the secondary side of the bus is different (TypeTranslation) from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the secondary side of the bus is Memory. If TypeStatic is specified, then the secondary side of the bus is I/O. If nothing is specified, then TypeStatic is assumed."
So IIUC it's wrong to have TypeTranslation. OTH, don't we need that for memory window ?
On 04/20/2016 11:00 AM, Sudeep Holla wrote:
On 20/04/16 16:54, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
I must have seen spec before replying to you :( It states:
"TranslationType is an optional argument that specifies whether the resource type on the secondary side of the bus is different (TypeTranslation) from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the secondary side of the bus is Memory. If TypeStatic is specified, then the secondary side of the bus is I/O. If nothing is specified, then TypeStatic is assumed."
See table 6-214, it disagrees. Also older spec's seem to say something different.
On Wed, Apr 20, 2016 at 11:06:28AM -0500, Jeremy Linton wrote:
On 04/20/2016 11:00 AM, Sudeep Holla wrote:
On 20/04/16 16:54, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
I must have seen spec before replying to you :( It states:
"TranslationType is an optional argument that specifies whether the resource type on the secondary side of the bus is different (TypeTranslation) from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the secondary side of the bus is Memory. If TypeStatic is specified, then the secondary side of the bus is I/O. If nothing is specified, then TypeStatic is assumed."
See table 6-214, it disagrees. Also older spec's seem to say something different.
From memory the conclusion on ASWG was that TypeTranslation was correct but it
was so misused in past due to misleading spec that most OSes ignore it.
Graeme
On 20.04.2016 18:11, G Gregory wrote:
On Wed, Apr 20, 2016 at 11:06:28AM -0500, Jeremy Linton wrote:
On 04/20/2016 11:00 AM, Sudeep Holla wrote:
On 20/04/16 16:54, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
I must have seen spec before replying to you :( It states:
"TranslationType is an optional argument that specifies whether the resource type on the secondary side of the bus is different (TypeTranslation) from that on the primary side of the bus or the same (TypeStatic). If TypeTranslation is specified, then the secondary side of the bus is Memory. If TypeStatic is specified, then the secondary side of the bus is I/O. If nothing is specified, then TypeStatic is assumed."
See table 6-214, it disagrees. Also older spec's seem to say something different.
From memory the conclusion on ASWG was that TypeTranslation was correct but it was so misused in past due to misleading spec that most OSes ignore it.
Exactly, please see: https://lkml.org/lkml/2015/11/6/209
Thanks, Tomasz
On 04/20/2016 10:54 AM, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
That is your call, but I believe that TypeTranslation is correct, if you read table 6-214 in ACPI6 (I/O Resource Flag (resource Type=1) Definitions). That table to be the clearest statement of intent for the field and the one I would refer to.
On 20/04/16 17:04, Jeremy Linton wrote:
On 04/20/2016 10:54 AM, Sudeep Holla wrote:
On 20/04/16 16:44, Jeremy Linton wrote:
On 04/20/2016 10:35 AM, Sudeep Holla wrote:
[...]
Yes I got bitten by that and I failed to notice it :). I have fixed it locally and tested correctly now.
DWordIo ( // IO window ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, // Granularity 0x00000000, // Min Base Address 0x007fffff, // Max Base Address 0x5f800000, // Translate 0x00800000, // Length , , ,
This is exactly what I have now after fixing the length and works fine, but ...
TypeTranslation... this is TypeStatic which I assume is default when not specified.
I tried TypeTranslation too and it works fine. It adds DenseTranslation by default. Do you want me to add TypeTranslation?
That is your call, but I believe that TypeTranslation is correct, if you read table 6-214 in ACPI6 (I/O Resource Flag (resource Type=1) Definitions). That table to be the clearest statement of intent for the field and the one I would refer to.
Agreed, I didn't see that table.
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table. It also adds 'TypeTranslation' to the IO window
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com --- Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
v3->v4: - Fixed the max to match the length and added TypeTranslation v2->v3: - Fixed $subject and the commit log v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..969c42398f18 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,10 +107,11 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity - 0x5f800000, // Min Base Address - 0x5fffffff, // Max Base Address + 0x00000000, // Min Base Address + 0x007fffff, // Max Base Address 0x5f800000, // Translate - 0x00800000 // Length + 0x00800000, // Length + ,,,TypeTranslation ) }) // Name(RBUF)
On Wed, Apr 20, 2016 at 06:35:06PM +0100, Sudeep Holla wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table. It also adds 'TypeTranslation' to the IO window
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Would anyone like to add any ACKs/Reviewed-bys?
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
v3->v4:
- Fixed the max to match the length and added TypeTranslation
v2->v3:
- Fixed $subject and the commit log
v1->v2:
- Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..969c42398f18 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,10 +107,11 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity
0x5f800000, // Min Base Address0x5fffffff, // Max Base Address
0x00000000, // Min Base Address0x007fffff, // Max Base Address 0x5f800000, // Translate
0x00800000 // Length
0x00800000, // Length,,,TypeTranslation ) }) // Name(RBUF)1.9.1
On 22 April 2016 at 15:26, Leif Lindholm leif.lindholm@linaro.org wrote:
On Wed, Apr 20, 2016 at 06:35:06PM +0100, Sudeep Holla wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table. It also adds 'TypeTranslation' to the IO window
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Would anyone like to add any ACKs/Reviewed-bys?
Reviewed-by: Graeme Gregory graeme.gregory@linaro.org
Graeme
Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
v3->v4: - Fixed the max to match the length and added TypeTranslation v2->v3: - Fixed $subject and the commit log v1->v2: - Made changes as suggested by Graeme & Tomasz
diff --git a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl index 800d2cb3b2fb..969c42398f18 100644 --- a/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl +++ b/Platforms/ARM/Juno/AcpiTables/AcpiSsdtRootPci.asl @@ -107,10 +107,11 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_OEM PosDecode, EntireRange, 0x00000000, // Granularity
0x5f800000, // Min Base Address0x5fffffff, // Max Base Address
0x00000000, // Min Base Address0x007fffff, // Max Base Address 0x5f800000, // Translate
0x00800000 // Length
0x00800000, // Length,,,TypeTranslation ) }) // Name(RBUF)-- 1.9.1
On 22 April 2016 at 17:17, G Gregory graeme.gregory@linaro.org wrote:
On 22 April 2016 at 15:26, Leif Lindholm leif.lindholm@linaro.org wrote:
On Wed, Apr 20, 2016 at 06:35:06PM +0100, Sudeep Holla wrote:
XPress-RICH3 PCIe driver initializes the root complex with the source and target address for IO window. The root complex resources in SSDT should match these settings.
This patch fixes the min/max base address for the IO window in Juno PCIe root complex ACPI table. It also adds 'TypeTranslation' to the IO window
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Leif Lindholm leif.lindholm@linaro.org Cc: Tomasz Nowicki tn@semihalf.com Cc: Graeme Gregory graeme.gregory@linaro.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com
Would anyone like to add any ACKs/Reviewed-bys?
Reviewed-by: Graeme Gregory graeme.gregory@linaro.org
Huh, Jeremy just pointed out that I hadn't pushed this patch. That has now been addressed - thanks and apologies.
Pushed as fdcd817. (Subject line slightly trimmed to fit)
Regards,
Leif
-
Ard Biesheuvel -
G Gregory -
Graeme Gregory
-
Jeremy Linton -
Leif Lindholm -
Sudeep Holla -
Tomasz Nowicki