On Tue, Dec 16, 2014 at 11:27:48AM +0000, Arnd Bergmann wrote:
On Monday 15 December 2014 19:18:16 Al Stone wrote:
TODO List for ACPI on arm64:
- Define how Aarch64 OS identifies itself to firmware.
- Problem:
- _OSI method is demonstrably unreliable. On x86 Linux claims to be Windows
- Proposal to use _OSC method as replacement is complicated and creates an explosion of combinations
- Solution:
- Draft and propose OS identification rules to ABST and ASWG for inclusion in ACPI spec.
- Draft and propose recommended practice for current ACPI 5.1 spec platforms.
- Status: Little progress, still under investigation
I must have missed the problem with _OSC, it sounded like it was good enough, but I have no clue about the details.
Neither do I. It's also not entirely clear whether per-device _OSC are arbitrary or vendors need to go through some kind of approving process (as with the new _DSD process).
- Linux must choose DT booting by default when offered both ACPI and DT on arm64
- DONE
I'm fine with this but just a clarification note here. We can't have acpi=off in the absence of DT because the system may not be able to report the error (no PC standard with some fixed 8250 port to fall back to). That's unless we print the error from the EFI_STUB before exiting boot services (e.g. "No Device Tree and no acpi=on; cannot boot").
- Set clear expectations for those providing ACPI for use with Linux
- Problem:
- Hardware/Firmware vendors can and will create ACPI tables that cannot be used by Linux without some guidance
- Kernel developers cannot determine whether the kernel or firmware is broken without knowing what the firmware should do
- Solution: document the expectations, and iterate as needed. Enforce when we must.
- Status: initial kernel text available; AMD has offered to make their guidance document generic; firmware summit planned for deeper discussions.
After seeing the AMD patches, I would add to this point that we need to find a way to come up with shared bindings for common hardware such as the ARM pl011/pl022/pl061/pl330 IP blocks or the designware i2c/spi/usb3/ahci blocks.
What I remember from this item on your list is actually a different problem: We need to define more clearly what kinds of machines we would expect ACPI support for and which machines we would not.
Fine-grained clock support is one such example: if anybody needs to expose that through a clock driver in the kernel, we need to be very clear that we will not support that kind of machine through ACPI, so we don't get developers building BIOS images that will never be supported. Other examples would be non-compliant PCI hosts or machines that are not covered by SBSA.
Another example is SMP booting. The ACPI 5.1 spec mentions the parking protocol but I can't find a reference to the latest document. In the meantime, we stick to PSCI.
From a recent more private discussion I learnt that hardware or firmware
people are not keen on reading a Linux arm-acpi.txt document, probably thinking it is too Linux specific. The proposal is to (longer term) move parts of this document (which are not Linux specific) into SBBR or maybe a new document for run-time requirements. Linux will still keep a statement about compliance with such documents and other Linux-specific aspects.
- Why is ACPI required?
- Problem:
- arm64 maintainers still haven't been convinced that ACPI is necessary.
- Why do hardware and OS vendors say ACPI is required?
- Status: Al & Grant collecting statements from OEMs to be posted publicly early in the new year; firmware summit for broader discussion planned.
I was particularly hoping to see better progress on this item. It really shouldn't be that hard to explain why someone wants this feature.
It's an "industry standard", you shouldn't question any further ;).