[v2,00/35] dm: Add programmatic generation of ACPI tables (part B)

Message ID 20200510203409.203520-1-sjg@chromium.org
Headers show
Series
  • dm: Add programmatic generation of ACPI tables (part B)
Related show

Message

Simon Glass May 10, 2020, 8:33 p.m.
NOTE: I have resent this as v1 to avoid confusion

This is split from the original series in an attempt to get things applied
in chunks.

This part includes:
- writing basic ACPI code for integers, strings, names, packages
- writing descriptors for GPIO, I2C, interrupts, SPI
- writing code to enable/disable ACPI peripherals via GPIOs
- writing SSDT and DSDT tables
- additional ways to determine ACPI device names

Much of this code is taken from coreboot and I have tried to avoid
changing the original code for no reason. Changes include:
- splitting the acpi_dp functions into their own file
- adding tests
- adding (lots of) comments
- using a context pointer instead of global variables
- tidying up some code where couldn't resist (e.g. acpigen_emit_namestring())

Changes in v2:
- Fix memset of I2C descriptor
- Fix memset of SPI descriptor

Changes in v1:
- Capitalise ACPI_OPS_PTR
- Split into more patches for review
- Add tests
- Rebase on top of common.h series
- Fix 'the an' typo
- Move header definitions into this patch
- Update sandbox driver slightly for testing
- Switch parameter order of _acpi_fill_ssdt() and make it static
- Fix 'sentinal' and 'METHOD_FILL_SDDT' typos
- Correct the commit subject
- Generalise the ACPI function recursion with acpi_recurse_method()
- Generalise the ACPI function recursion with acpi_recurse_method()
- Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR
- Update ACPI_DSTATUS enum
- Drop writing of coreboot tables
- Generalise the ACPI function recursion with acpi_recurse_method()
- Use acpi,ddn instead of acpi,desc
- Rename to acpi_device_infer_name()
- Update newly created sandbox tests

Simon Glass (35):
  dm: core: Add an ACPI name for the root node
  acpi: Add a function to get a device path and scope
  acpi: Add a way to check device status
  irq: Add a method to convert an interrupt to ACPI
  acpi: Support generation of ACPI code
  acpi: Support generation of interrupt descriptor
  gpio: Add a method to convert a GPIO to ACPI
  acpi: Support string output
  acpi: Support generation of GPIO descriptor
  acpi: Support generation of a GPIO/irq for a device
  acpi: Support generation of I2C descriptor
  acpi: Support generation of SPI descriptor
  acpigen: Support writing a length
  acpigen: Support writing a package
  acpi: Support writing an integer
  acpi: Support writing a string
  acpi: Support writing a name
  acpi: Support writing a UUID
  acpi: Support writing Device Properties objects via _DSD
  acpi: Support writing a GPIO
  acpi: Support copying properties from device tree to ACPI
  acpi: Add support for various misc ACPI opcodes
  acpi: Add support for writing a Power Resource
  acpi: Add support for writing a GPIO power sequence
  acpi: Add support for a generic power sequence
  acpi: Add support for SSDT generation
  x86: acpi: Move MADT down a bit
  acpi: Record the items added to SSDT
  acpi: Support ordering SSDT data by device
  x86: Allow devices to write an SSDT
  acpi: Add support for DSDT generation
  x86: Allow devices to write to DSDT
  pci: Avoid a crash in device_is_on_pci_bus()
  dm: acpi: Enhance acpi_get_name()
  acpi: Add an acpi split command

 arch/sandbox/dts/test.dts           |  14 +-
 arch/x86/lib/acpi_table.c           |  54 +-
 cmd/acpi.c                          |  15 +-
 doc/device-tree-bindings/chosen.txt |   9 +
 doc/device-tree-bindings/device.txt |  13 +
 drivers/core/acpi.c                 | 207 ++++++-
 drivers/core/root.c                 |  13 +
 drivers/gpio/gpio-uclass.c          |  21 +
 drivers/gpio/sandbox.c              |  86 +++
 drivers/i2c/sandbox_i2c.c           |   1 +
 drivers/misc/irq-uclass.c           |  18 +-
 drivers/misc/irq_sandbox.c          |  16 +
 drivers/rtc/sandbox_rtc.c           |  13 +
 drivers/spi/sandbox_spi.c           |   1 +
 include/acpi/acpi_device.h          | 401 +++++++++++++
 include/acpi/acpi_dp.h              | 283 +++++++++
 include/acpi/acpi_table.h           |   6 +
 include/acpi/acpigen.h              | 347 +++++++++++
 include/asm-generic/gpio.h          |  27 +
 include/dm/acpi.h                   |  63 ++
 include/dm/device.h                 |   2 +-
 include/irq.h                       |  43 ++
 include/spi.h                       |   4 +-
 include/test/ut.h                   |  17 +
 lib/acpi/Makefile                   |   3 +
 lib/acpi/acpi_device.c              | 812 ++++++++++++++++++++++++++
 lib/acpi/acpi_dp.c                  | 397 +++++++++++++
 lib/acpi/acpigen.c                  | 477 +++++++++++++++
 test/dm/Makefile                    |   2 +
 test/dm/acpi.c                      | 277 ++++++++-
 test/dm/acpi_dp.c                   | 511 +++++++++++++++++
 test/dm/acpigen.c                   | 861 ++++++++++++++++++++++++++++
 test/dm/gpio.c                      |  62 ++
 test/dm/irq.c                       |  23 +
 test/dm/pci.c                       |  14 +
 35 files changed, 5080 insertions(+), 33 deletions(-)
 create mode 100644 include/acpi/acpi_device.h
 create mode 100644 include/acpi/acpi_dp.h
 create mode 100644 include/acpi/acpigen.h
 create mode 100644 lib/acpi/acpi_device.c
 create mode 100644 lib/acpi/acpi_dp.c
 create mode 100644 lib/acpi/acpigen.c
 create mode 100644 test/dm/acpi_dp.c
 create mode 100644 test/dm/acpigen.c

Comments

Bin Meng May 12, 2020, 2:13 a.m. | #1
Hi Wolfgang, Andy,

On Mon, May 11, 2020 at 4:34 AM Simon Glass <sjg at chromium.org> wrote:
>
> NOTE: I have resent this as v1 to avoid confusion
>
> This is split from the original series in an attempt to get things applied
> in chunks.
>
> This part includes:
> - writing basic ACPI code for integers, strings, names, packages
> - writing descriptors for GPIO, I2C, interrupts, SPI
> - writing code to enable/disable ACPI peripherals via GPIOs
> - writing SSDT and DSDT tables
> - additional ways to determine ACPI device names
>
> Much of this code is taken from coreboot and I have tried to avoid
> changing the original code for no reason. Changes include:
> - splitting the acpi_dp functions into their own file
> - adding tests
> - adding (lots of) comments
> - using a context pointer instead of global variables
> - tidying up some code where couldn't resist (e.g. acpigen_emit_namestring())
>
> Changes in v2:
> - Fix memset of I2C descriptor
> - Fix memset of SPI descriptor
>
> Changes in v1:
> - Capitalise ACPI_OPS_PTR
> - Split into more patches for review
> - Add tests
> - Rebase on top of common.h series
> - Fix 'the an' typo
> - Move header definitions into this patch
> - Update sandbox driver slightly for testing
> - Switch parameter order of _acpi_fill_ssdt() and make it static
> - Fix 'sentinal' and 'METHOD_FILL_SDDT' typos
> - Correct the commit subject
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR
> - Update ACPI_DSTATUS enum
> - Drop writing of coreboot tables
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Use acpi,ddn instead of acpi,desc
> - Rename to acpi_device_infer_name()
> - Update newly created sandbox tests
>

Since you were involved a lot in the discussion in the part A series,
would you please let me know if you get some time to review this?

Regards,
Bin
Wolfgang Wallner May 12, 2020, 11:55 a.m. | #2
Hi Bin,

-----"Bin Meng" <bmeng.cn at gmail.com> schrieb: -----
> Betreff: Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables (part B)
> 
> Hi Wolfgang, Andy,
> 
> On Mon, May 11, 2020 at 4:34 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > NOTE: I have resent this as v1 to avoid confusion
> >
> > This is split from the original series in an attempt to get things applied
> > in chunks.
> >
> > This part includes:
> > - writing basic ACPI code for integers, strings, names, packages
> > - writing descriptors for GPIO, I2C, interrupts, SPI
> > - writing code to enable/disable ACPI peripherals via GPIOs
> > - writing SSDT and DSDT tables
> > - additional ways to determine ACPI device names
> >
> > Much of this code is taken from coreboot and I have tried to avoid
> > changing the original code for no reason. Changes include:
> > - splitting the acpi_dp functions into their own file
> > - adding tests
> > - adding (lots of) comments
> > - using a context pointer instead of global variables
> > - tidying up some code where couldn't resist (e.g. acpigen_emit_namestring())
> >
> > Changes in v2:
> > - Fix memset of I2C descriptor
> > - Fix memset of SPI descriptor
> >
> > Changes in v1:
> > - Capitalise ACPI_OPS_PTR
> > - Split into more patches for review
> > - Add tests
> > - Rebase on top of common.h series
> > - Fix 'the an' typo
> > - Move header definitions into this patch
> > - Update sandbox driver slightly for testing
> > - Switch parameter order of _acpi_fill_ssdt() and make it static
> > - Fix 'sentinal' and 'METHOD_FILL_SDDT' typos
> > - Correct the commit subject
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR
> > - Update ACPI_DSTATUS enum
> > - Drop writing of coreboot tables
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Use acpi,ddn instead of acpi,desc
> > - Rename to acpi_device_infer_name()
> > - Update newly created sandbox tests
> >
> 
> Since you were involved a lot in the discussion in the part A series,
> would you please let me know if you get some time to review this?

Unfortunately, I don't have as much time now for review of part B as I had for
part A. I already started reviewing part B and I will try to continue when time
allows.

regards, Wolfgang
Andy Shevchenko May 12, 2020, 12:32 p.m. | #3
On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:

> > Since you were involved a lot in the discussion in the part A series,
> > would you please let me know if you get some time to review this?
> 
> Unfortunately, I don't have as much time now for review of part B as I had for
> part A. I already started reviewing part B and I will try to continue when time
> allows.

I'm busy at the moment and I will be not available for this for few weeks.
Code can be fixed iteratively, the most important part now is to see the big
picture of the design and approach.

Could you remind which patch in the series describes that? I will look at it
closer and try to allocate a bit of time to do it.
Simon Glass May 12, 2020, 11:22 p.m. | #4
Hi Andy,

On Tue, 12 May 2020 at 06:32, Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:
>
> > > Since you were involved a lot in the discussion in the part A series,
> > > would you please let me know if you get some time to review this?
> >
> > Unfortunately, I don't have as much time now for review of part B as I had for
> > part A. I already started reviewing part B and I will try to continue when time
> > allows.
>
> I'm busy at the moment and I will be not available for this for few weeks.
> Code can be fixed iteratively, the most important part now is to see the big
> picture of the design and approach.
>
> Could you remind which patch in the series describes that? I will look at it
> closer and try to allocate a bit of time to do it.
>

The big picture was in part A. Part B uses the same mechanism to add
support for SSDT and DSDT generation, e.g. see [1] and [2].

Regards,
Simon

[1] http://patchwork.ozlabs.org/project/uboot/patch/20200510203409.203520-24-sjg at chromium.org/
[2] http://patchwork.ozlabs.org/project/uboot/patch/20200510143320.v2.32.I8b14735c2286701cc6be7d36b85bbad8ca58babd at changeid/
Andy Shevchenko May 13, 2020, 9:55 a.m. | #5
On Tue, May 12, 2020 at 05:22:38PM -0600, Simon Glass wrote:
> Hi Andy,
> 
> On Tue, 12 May 2020 at 06:32, Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> >
> > On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:
> >
> > > > Since you were involved a lot in the discussion in the part A series,
> > > > would you please let me know if you get some time to review this?
> > >
> > > Unfortunately, I don't have as much time now for review of part B as I had for
> > > part A. I already started reviewing part B and I will try to continue when time
> > > allows.
> >
> > I'm busy at the moment and I will be not available for this for few weeks.
> > Code can be fixed iteratively, the most important part now is to see the big
> > picture of the design and approach.
> >
> > Could you remind which patch in the series describes that? I will look at it
> > closer and try to allocate a bit of time to do it.
> >
> 
> The big picture was in part A. Part B uses the same mechanism to add
> support for SSDT and DSDT generation, e.g. see [1] and [2].

Thank you, then I think what is left are technical (implementation) details
that can be amended in the future.
Simon Glass May 14, 2020, 4:02 p.m. | #6
Hi,

On Wed, 13 May 2020 at 03:55, Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> On Tue, May 12, 2020 at 05:22:38PM -0600, Simon Glass wrote:
> > Hi Andy,
> >
> > On Tue, 12 May 2020 at 06:32, Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > >
> > > On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:
> > >
> > > > > Since you were involved a lot in the discussion in the part A series,
> > > > > would you please let me know if you get some time to review this?
> > > >
> > > > Unfortunately, I don't have as much time now for review of part B as I had for
> > > > part A. I already started reviewing part B and I will try to continue when time
> > > > allows.
> > >
> > > I'm busy at the moment and I will be not available for this for few weeks.
> > > Code can be fixed iteratively, the most important part now is to see the big
> > > picture of the design and approach.
> > >
> > > Could you remind which patch in the series describes that? I will look at it
> > > closer and try to allocate a bit of time to do it.
> > >
> >
> > The big picture was in part A. Part B uses the same mechanism to add
> > support for SSDT and DSDT generation, e.g. see [1] and [2].
>
> Thank you, then I think what is left are technical (implementation) details
> that can be amended in the future.

OK then perhaps part B can be applied and I can send part C, which is
the actual coral implementation?

Regards,
SImon
Andy Shevchenko May 14, 2020, 4:38 p.m. | #7
On Thu, May 14, 2020 at 10:02:08AM -0600, Simon Glass wrote:
> On Wed, 13 May 2020 at 03:55, Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Tue, May 12, 2020 at 05:22:38PM -0600, Simon Glass wrote:
> > > On Tue, 12 May 2020 at 06:32, Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Tue, May 12, 2020 at 01:55:49PM +0200, Wolfgang Wallner wrote:

...

> > > > Could you remind which patch in the series describes that? I will look at it
> > > > closer and try to allocate a bit of time to do it.
> > > >
> > >
> > > The big picture was in part A. Part B uses the same mechanism to add
> > > support for SSDT and DSDT generation, e.g. see [1] and [2].
> >
> > Thank you, then I think what is left are technical (implementation) details
> > that can be amended in the future.
> 
> OK then perhaps part B can be applied and I can send part C, which is
> the actual coral implementation?

I think so.