Hello,
I just took a quick look at the discussion about the DwordIO ACPI
translation, and I have a couple comments (I don't have the whole thread
available for some reason..).
First, the "secondary bus" referenced in the ACPI specification is the
processor side, rather than the PCI device side. So the minimum/max base
address are the MMIO mapped addresses. To get the actual IO address the
translation must be subtracted. This means AFAIK that the qemu table is
wrong in two ways for ARM64.
So that said, I will reference the juno DwordIo resource which I
recently added to the EDK.
DWordIo ( // IO window
ResourceProducer,
MinFixed,
MaxFixed,
PosDecode,
EntireRange,
0x00000000, // Granularity
0x5f800000, // Min Base Address
0x5fffffff, // Max Base Address
0x5f800000, // Translate
0x00800000 // Length
)
Which after reading the specification, I realized should be setting the
translation type to TypeTranslation. But that really doesn't matter for
ARM64 because ARM64 doesn't have a processor accessible IO address
range. AKA the TranslationType controls whether the processor is doing
an IN/OUT/etc to access the range or actual MMIO read/writes. Since on
ARM64 the only choice is MMIO, this field should be ignored, the only
behavior difference should possibly be a warning if someone leaves it
set to static.
Put another way, the setting of the TranslationType doesn't change the
way the "translation" is computed, only how its accessed. AKA it doesn't
affect the math..
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
