From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Date: Mon, 2 Mar 2020 22:47:10 +0200 Subject: [PATCH v1] x86: acpi: Refactor XSDT handling in acpi_add_table() In-Reply-To: References: <20200227140051.75072-1-andriy.shevchenko@linux.intel.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Mar 2, 2020 at 9:47 PM Simon Glass wrote: > On Fri, 28 Feb 2020 at 01:47, Andy Shevchenko wrote: > > On Fri, Feb 28, 2020 at 1:41 AM Simon Glass wrote: > > > On Thu, 27 Feb 2020 at 06:00, Andy Shevchenko > > > wrote: > > > > > Could you take a look at the ACPI series? > > > > > > It was sent out about a month ago and has a refactor to this function. > > > > > > u-boot-dm/coral-working > > > > There are tons of changes. Care to point what changes are more > > important (generic to all x86)? > > I'm not quite sure about that...but x86 patches have an x86: tag, so > perhaps that helps? Okay, some like 50 of them or even more? I really don't want to spend time on the board related patches like "x86: apl:". > > P.S. Briefly looking at the last ~30 patches I can say that the idea > > looks good, implementation needs more work. For example, there is > > 'linux,name' property. Shouldn't be referred at all. Linux names and > > other type of enumerations is utterly opaque to the outside world. > > How do we add the required linux,name ACPI property into the ACPI > tables for a device? There must not be Linux device names or anything Linux related (like hardcoded GPIO numbers) in the ACPI table. > > On top of that, I think we rather need to have a conversion layer than > > putting some names inside DT, like \_SB_.GPO0 should be generated > > automatically from DT node. That said, I don't like DT being polluted > > with non-DT stuff. > > Well DT is the configuration mechanism for U-Boot. > > \_SB_.GPO0 is a special case since it actually refers to pinctrl (ACPI > seems to make no distinction between pinctrl and GPIO) and this node > is inside p2sb: > > pci { > p2sb at d,0 { > n { > gpio-n { > > So the automatically generated path would have p2sb in it. The same > work-around is in coreboot. It's not a coreboot, we may do better, right? So, generation can strip p2sb (special case) from all p2sb devices. However, I'm not sure I understand how p2sb is involved in GPIO enumeration, > > Also, I'm not sure how your rework helps ARM (or any other > > architecture) people with their approach to ACPI enabling (most of the > > files are under x86). > > I kept x86-specific tables in the x86 directories. Of course I might > be wrong about this. But then, people who use ACPI on ARM (ick!) Haven't you seen the series to introduce ACPI for ARM in U-Boot recently? > probably have a better idea on what is needed. The core DM support and > tests are there. I think with a such big rework it's not big deal to simple move it outside of arch/x86 to the lib/acpi or so. -- With Best Regards, Andy Shevchenko