On 29 January 2015 at 15:19, Catalin Marinas [off-list ref] wrote:

On Wed, Jan 28, 2015 at 06:18:44PM +0000, Timur Tabi wrote:

quoted

On 01/28/2015 12:14 PM, Catalin Marinas wrote:

quoted

quoted

quoted

So it looks like there's a whole conversation about this already in
this thread that I didn't notice.  However, reading through all of it,
I still don't understand sure why the presence of ACPI tables is
insufficient to enable ACPI.

quoted

Because ACPI on arm64 is still experimental, no matter how many people
claim that it is production ready in their private setups.

Fair enough.  Does this mean that passing "acpi=force" on the kernel
command line is a requirement for ARM64 servers?

Please read my other email and ideally the whole sub-thread. The
acpi=force should only be required if the SoC is described (from
firmware) by both DT and ACPI.

quoted

quoted

quoted

quoted

In what situation would we want to ignore ACPI tables that are
present?

quoted

When DT tables are also present (and for the first platforms, that's
highly recommended, though not easily enforceable at the kernel level).

My understanding is that the EFI stub creates a device tree (and it
contains some important information), so I don't understand how we can
ever have an ACPI-only platform on ARM64 servers.

If EFI stub creates the DT itself (not passed by firmware), it will
write some information in the chosen node that the rest of the kernel
can make use of and take the appropriate decision on whether to use ACPI
or not. That's something that will be used by kexec and Xen as well
which may want to boot with ACPI tables outside an EFI environment.

If we are going with this solution, we should also mandate that an
ACPI enabled firmware should not supply a non-DT DTB, or we wouldn't
spot the difference. Not sure how likely this is, but I could imagine
a firmware setting up an initrd and hence populating the /chosen node
in an otherwise empty DTB. In this case, the stub would not add its
'I-created-an-empty-dtb' property.

-- 
Ard.