Thread (103 messages) 103 messages, 19 authors, 2015-01-16

[Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

From: catalin.marinas@arm.com (Catalin Marinas)
Date: 2015-01-06 14:11:46
Also in: linux-acpi, lkml

On Tue, Jan 06, 2015 at 01:59:27PM +0000, Arnd Bergmann wrote:
On Tuesday 06 January 2015 11:20:01 Catalin Marinas wrote:
quoted
On Mon, Jan 05, 2015 at 08:16:30PM +0000, Arnd Bergmann wrote:
quoted
On Monday 05 January 2015 13:13:02 Catalin Marinas wrote:
quoted
quoted
since passing no DT tables to OS but
acpi=force is missing is a corner case, we can do a follow up patch to
fix that, does it make sense?
Not entirely. Why would no dtb and no acpi=force be a corner case? I
thought this should be the default when only ACPI tables are passed, no
need for an additional acpi=force argument.
We don't really support the case of only ACPI tables for now. The expectation
is that you always have working DT support, at least for the next few years
as ACPI features are ramping up, and without acpi=force it should not try
to use ACPI at all.
So if both DT and ACPI are present, just use DT unless acpi=force is
passed. So far I think we agree but what I want to avoid is always
mandating acpi=force even when the DT tables are missing (in the long
run).

Now, what's preventing a vendor firmware from providing only ACPI
tables? Do we enforce it in some way (arm-acpi.txt, kernel warning etc.)
that both DT and ACPI are supported, or at least that dts files are
merged in the kernel first?
We have no way of enforcing what a board vendor ships, so if they want
to have ACPI-only machines for MS Windows, they just won't work by
default on Linux.
What do you mean by "won't work by default on Linux"? Assuming no
additional drivers are needed (i.e. a few devices mentioned in SBSA and
the rest on a PCIe bus, using existing drivers without further
modifications), do you still want mainline to fail to boot on such
ACPI-only systems?
Once ACPI support is mature enough, we can also have a whitelist or a
different default for using it automatically when no DT is present.
Having a white-list requires some for of SoC identification. Does ACPI
provide such thing (like "model" or "compatible" strings in the top DT
node)?
For drivers merged upstream, I would insist that every driver merged
for an ARM64 platform has a documented DT binding that is used in the
driver.
That's fine by me. I just hope that for hardware aimed at ACPI we won't
need many non-PCIe drivers.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help