[U-Boot] [PATCH v3] arm: add acpi support for the arm

[Simon Glass]

Hi Heinrich,

On Mon, 25 Nov 2019 at 18:12, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 11/26/19 12:40 AM, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 25 Nov 2019 at 15:57, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> On 11/25/19 3:42 AM, Steven Hao wrote:> 获取 Outlook for iOS
> >> <https://aka.ms/o0ukef>
> >>> ------------------------------------------------------------------------
> >>> *发件人:* Bin Meng <bmeng.cn at gmail.com>
> >>> *发送时间:* Monday, November 25, 2019 10:13:40 AM
> >>> *收件人:* Steven Hao <steven_hao5189 at outlook.com>
> >>> *抄送:* xypron.glpk at gmx.de <xypron.glpk at gmx.de>; liuhao at phytium.com.cn
> >>> <liuhao at phytium.com.cn>; agraf at csgraf.de <agraf at csgraf.de>;
> >>> jagan at amarulasolutions.com <jagan at amarulasolutions.com>;
> >>> marek.vasut at gmail.com <marek.vasut at gmail.com>; sr at denx.de <sr at denx.de>;
> >>> patrice.chotard at st.com <patrice.chotard at st.com>; afd at ti.com
> >>> <afd at ti.com>; horatiu.vultur at microchip.com
> >>> <horatiu.vultur at microchip.com>; narmstrong at baylibre.com
> >>> <narmstrong at baylibre.com>; ryder.lee at mediatek.com
> >>> <ryder.lee at mediatek.com>; igor.opaniuk at gmail.com
> >>> <igor.opaniuk at gmail.com>; patrick.delaunay at st.com
> >>> <patrick.delaunay at st.com>; eugen.hristev at microchip.com
> >>> <eugen.hristev at microchip.com>; sjg at chromium.org <sjg at chromium.org>;
> >>> judge.packham at gmail.com <judge.packham at gmail.com>;
> >>> yamada.masahiro at socionext.com <yamada.masahiro at socionext.com>;
> >>> swarren at nvidia.com <swarren at nvidia.com>; michal.simek at xilinx.com
> >>> <michal.simek at xilinx.com>; u-boot at lists.denx.de <u-boot at lists.denx.de>;
> >>> Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> >>> *主题:* Re: [PATCH v3] arm: add acpi support for the arm
> >>> Hi Steven,
> >>>
> >>> On Mon, Nov 25, 2019 at 10:09 AM Steven Hao <steven_hao5189 at outlook.com>
> >>> wrote:
> >>>>
> >>>> Dear Bin：
> >>>>
> >>>> Firstly：
> >>>> I know that acpi about x86 is existing. And it is usefull for x86
> >> platfporm. If it  is used to arm platform，some modification may have to
> >> do. For example，facs table is useless for arm.
> >>>>
> >>>> In adition，The acpi table is writed statically and then modified
> >> dynamically in my patch. It is a new method.
> >>>>
> >>>> I want to consult that whether my method is helpful or not.
> >>>>
> >>>> Secondly：
> >>>> If i want to reuse the x86-acpi. I will overwrite the
> >> write_acpi_tables function. But the definition about acpi strcuture is
> >> placed in arch/x86/include/asm directory. It can not be used to arm
> >> plateform. If the acpi library need to surport for all platform，i  think
> >> it should move to /include directory.
> >>>>
> >>>
> >>> Yes, we all are aware that modifications are needed to the existing
> >>> x86 ACPI support to support ARM. We don't want to create 2 ACP
> >>> implementation in U-Boot.
> >>>
> >>> Regards,
> >>> Bin> Dear Bin：
> >>>
> >>> I have a suggetion that the acpi specification definition such as all
> >>> acpi table structure definition  should be place in /include directory.
> >>> and write_acpi_tables function can be placed in platform directory.
> >>>    Creating acpi table mothod  can be diffrent between x86 and arm.
> >>>
> >>> Thank you
> >>> Steven Hao
> >>>
> >>
> >> Currently we are using CPU specific C files generating ACPI tables, e.g.
> >> arch/x86/cpu/tangier/acpi.c.
> >>
> >> I would prefer if we would generate the ACPI tables and definition
> >> blocks completely from text files instead of using C code. This would
> >> avoid any architecture specific code.
> >
> > I am finding with Apollo Lake that this isn't possible - we need to
> > insert run-time information into the tables set up with .asl files.
>
> For device trees we generate the binary form with a compiler. Then we
> patch the device tree with runtime information in image_setup_libfdt().
>
> Couldn't we go a similar way for ACPI?

Yes that's my goal, except that some tables are generated wholesale
from code (equivalent to entire nodes in DT).

I had a bit of a look at how this is done in coreboot. It is pretty
hard to follow as there are weak functions and the code jumps back and
forth between generic code and SoC-specific code. But every device has
ACPI operation and I think that makes sense.

My current idea is to add a new optional acpi_ops struct pointer into
each struct driver, to handle the ACPI table generation and other
things needed by ACPI. Then devices that want to do ACPI things can do
so. Then we need a new drivers/core/acpi.c file to handle things.

Regards,
Simon

>
> >
> >>
> >> Such table generation is already in use in the Windows world. See:
> >> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/generate-acpi-tables-by-using-acpigenfx
> >
> > That looks like a programmatic way to create ACPI tables. If so, I'm
> > trying to bring something similar over from coreboot.
> >
> > Regards,
> > Simon
> >
>