Hi Andy,
On Sun, Jul 23, 2017 at 12:43 AM, Andy Shevchenko andy.shevchenko@gmail.com wrote:
On Sat, Jul 22, 2017 at 4:45 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Andy,
On Sat, Jul 22, 2017 at 3:32 AM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
If ACPI HW reduced bit in FADT is set we should ignore any ACPI hardware communications.
Signed-off-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
arch/x86/lib/acpi_table.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c index da6014fb41..3eb101105b 100644 --- a/arch/x86/lib/acpi_table.c +++ b/arch/x86/lib/acpi_table.c @@ -463,6 +463,10 @@ ulong write_acpi_tables(ulong start)
debug("ACPI: done\n");
/* Don't touch ACPI hardware on HW reduced platforms */if (fadt->flags & ACPI_FADT_HW_REDUCED_ACPI)return current;Reviewed-by: Bin Meng bmeng.cn@gmail.com
Thanks!
I assume this is needed on Intel Edison.
Actually it has very little with Edison, though I had stumbled over the bug on that platform.
ARM64 support, if any will come, or I even can suggest to try ASUS T100 transformer (Baytrail based HW reduced).
Just out of curiosity, if the ASUS T100 transformer is BayTrail based, why is that HW reduced? My understanding is that BayTrail has these ACPI registers.
If that's the case, will you support S3 resume on Edison? And if yes, I believe we will need update acpi_resume() to add the same check there?
It might affect any of HW reduced one, needs to be checked.
I fixed only one issue I found, I didn't look at every places where U-Boot goes to ACPI HW,
Regards, Bin