| Message ID | 20200510203409.203520-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | dm: Add programmatic generation of ACPI tables (part B) | expand |
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
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
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.
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/
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.
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
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.