You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the acpi ROM generated by driver/acpi contains ambiguous IRQ-routing information on newer devices (t490s, StarLite tablet). Moreover, some routing information is even missing. I'm still far from understanding the realm of ACPI tables, yet my understanding of this issue is as follows:
PCI IRQ routing information is defined in _PRT methods.
The acpi driver currently parses the _PRT methods that are explicitly referenced by any sub-device (e.g. PCI0.*).
_PRT methods may also be defined for the parent device (e.g. PCI0) without being referenced by its sub-devices. These are currently ignored by the acpi driver.
When parsing the _PRT methods, the acpi driver merely extracts all the package data but ignores the control structures within the method. This leads to ambiguous routing information in the acpi ROM.
The same _PRT method may be referenced by multiple sub-devices. Since the acpi driver parses the _PRT for each reference, the acpi ROM may actually contain the same <routing>-entry multiple times.
I'm uncertain how to proceed with this issue. Due to the complexity that we would need to add to the acpi driver, I believe this issue would best be addressed in terms of the pre-boot ACPI discovery (cf. roadmap).
The text was updated successfully, but these errors were encountered:
I'm uncertain how to proceed with this issue. Due to the complexity that we would need to add to the acpi driver, I believe this issue would best be addressed in terms of the pre-boot ACPI discovery (cf. roadmap).
During my experiments I discovered that the dynamic nature of ACPI methods that may refer to other in-memory variables for conditionals goes far beyond the scope of the current acpi driver. For example, the simple discovery of basic PC devices like PS2 controller, RTC or PIT required the execution of dynamic AML code on recent systems. Therefore, I agree that this issue documents one shortcoming (_PRT info) of the current driver that should be addressed in the boot-time ACPI discovery.
I noticed that the acpi ROM generated by driver/acpi contains ambiguous IRQ-routing information on newer devices (t490s, StarLite tablet). Moreover, some routing information is even missing. I'm still far from understanding the realm of ACPI tables, yet my understanding of this issue is as follows:
_PRT
methods._PRT
methods that are explicitly referenced by any sub-device (e.g. PCI0.*)._PRT
methods may also be defined for the parent device (e.g. PCI0) without being referenced by its sub-devices. These are currently ignored by the acpi driver._PRT
methods, the acpi driver merely extracts all the package data but ignores the control structures within the method. This leads to ambiguous routing information in the acpi ROM._PRT
method may be referenced by multiple sub-devices. Since the acpi driver parses the_PRT
for each reference, the acpi ROM may actually contain the same<routing>
-entry multiple times.I'm uncertain how to proceed with this issue. Due to the complexity that we would need to add to the acpi driver, I believe this issue would best be addressed in terms of the pre-boot ACPI discovery (cf. roadmap).
The text was updated successfully, but these errors were encountered: