[PATCH v3] arm: add acpi support for the arm
Simon Glass
sjg at chromium.org
Sun Mar 29 04:13:40 CEST 2020
+U-Boot Mailing List
Hi Steven,
On Thu, 19 Mar 2020 at 21:08, Steven Hao <steven_hao5189 at outlook.com> wrote:
>
> Hi Simon:
>
> Most acpi table have no difference between x86 and arm.
> For example, RSDP,XSDT,DSDT,SSDT,SPCR,FADT,MADT,GTDT,MCFG is same.
> But FACS,IORT table may be different.
>
> I have a idea that the same apci tables should be defined in /include/acpi_table folder,
> and the different tables may be defined in /include/acpi_table/x86 folder or /include/acpi_table/arm folder.
Yes I have added almost all the structs to the generic acpi_table.h,
except NHLT.
(please can you avoid top-posting?)
Regards,
Simon
>
> Regards
> Steven Hao
> 2020-03-20
>
>
>
> ________________________________
> 发件人: Simon Glass <sjg at chromium.org>
> 发送时间: 2020年3月20日 0:18
> 收件人: Steven Hao <steven_hao5189 at outlook.com>
> 抄送: U-Boot Mailing List <u-boot at lists.denx.de>
> 主题: Re: [PATCH v3] arm: add acpi support for the arm
>
> Hi Steven,
>
> On Wed, 18 Mar 2020 at 00:46, Steven Hao <steven_hao5189 at outlook.com> wrote:
> >
> > Hi Simon:
> >
> > Nowdays I get that you are updating the acpi in uboot. I want to ask for that
> > could you support the arm platform or keep out a interface for adding arm-acpi.
> > For example, the acpi_table.h file may be put in include folder, instead of arch/x86/include/asm folder.
> >
>
> It is hard for me to know what ACPI bits ARM uses. Do you know? It
> should be easy enough to move the code later if needed.
>
> Regards,
> Simon
>
>
> > Steven Hao
> > 2020-03-18
> > ________________________________
> > 发件人: Simon Glass <sjg at chromium.org>
> > 发送时间: 2019年12月28日 0:41
> > 收件人: Steven Hao <steven_hao5189 at outlook.com>
> > 抄送: Bin Meng <bmeng.cn at gmail.com>; Heinrich Schuchardt <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>; 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,
> >
> > On Sun, 15 Dec 2019 at 18:54, Steven Hao <steven_hao5189 at outlook.com> wrote:
> > >
> > > This problem seems like lay aside.
> > >
> > > ________________________________
> > > 发件人: Bin Meng <bmeng.cn at gmail.com>
> > > 发送时间: 2019年11月27日 14:04
> > > 收件人: Simon Glass <sjg at chromium.org>
> > > 抄送: Heinrich Schuchardt <xypron.glpk at gmx.de>; Steven Hao <steven_hao5189 at outlook.com>; 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>; 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 Simon,
> > >
> > > On Wed, Nov 27, 2019 at 11:42 AM Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > 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>
> > > > > >>> ------------------------------------------------------------------------
> > > > > >>> *主题:* 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.
> > > >
> > >
> > > Yes, this approach makes sense to me, for dynamic ACPI table generation.
> >
> > Just an update on this...I have some basic code for APL and am making
> > progress. I expect to send patches by the end of January.
> >
> > Regards,
> > Simon
More information about the U-Boot
mailing list