Hi Heinrich, On Mon, 25 Nov 2019 at 18:12, Heinrich Schuchardt <xypron.g...@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.g...@gmx.de> > > wrote: > >> > >> On 11/25/19 3:42 AM, Steven Hao wrote:> 获取 Outlook for iOS > >> <https://aka.ms/o0ukef> > >>> ------------------------------------------------------------------------ > >>> *发件人:* Bin Meng <bmeng...@gmail.com> > >>> *发送时间:* Monday, November 25, 2019 10:13:40 AM > >>> *收件人:* Steven Hao <steven_hao5...@outlook.com> > >>> *抄送:* xypron.g...@gmx.de <xypron.g...@gmx.de>; liu...@phytium.com.cn > >>> <liu...@phytium.com.cn>; ag...@csgraf.de <ag...@csgraf.de>; > >>> ja...@amarulasolutions.com <ja...@amarulasolutions.com>; > >>> marek.va...@gmail.com <marek.va...@gmail.com>; s...@denx.de > >>> <s...@denx.de>; > >>> patrice.chot...@st.com <patrice.chot...@st.com>; a...@ti.com > >>> <a...@ti.com>; horatiu.vul...@microchip.com > >>> <horatiu.vul...@microchip.com>; narmstr...@baylibre.com > >>> <narmstr...@baylibre.com>; ryder....@mediatek.com > >>> <ryder....@mediatek.com>; igor.opan...@gmail.com > >>> <igor.opan...@gmail.com>; patrick.delau...@st.com > >>> <patrick.delau...@st.com>; eugen.hris...@microchip.com > >>> <eugen.hris...@microchip.com>; s...@chromium.org <s...@chromium.org>; > >>> judge.pack...@gmail.com <judge.pack...@gmail.com>; > >>> yamada.masah...@socionext.com <yamada.masah...@socionext.com>; > >>> swar...@nvidia.com <swar...@nvidia.com>; michal.si...@xilinx.com > >>> <michal.si...@xilinx.com>; u-boot@lists.denx.de <u-boot@lists.denx.de>; > >>> Andy Shevchenko <andriy.shevche...@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_hao5...@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 > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
