[PATCH v4 00/59] dm: Add programatic generation of ACPI tables (part D)

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v4 00/59] dm: Add programatic generation of ACPI tables (part D)

Bin Meng-2
On Wed, Sep 23, 2020 at 2:46 AM Simon Glass <[hidden email]> wrote:

>
> Note: This is part D of this effort. With this, Coral includes all
> required ACPI tables.
>
> At present on x86 U-Boot supports creating ACPI (Advanced Configuration
> and Power Interface) tables using the Intel ACPI Source Language (ASL)
> compiler.
>
> This is good enough for basic operation but some devices need to add
> their information dynamically at runtime. An example is a device that
> needs to report its enable GPIO. This is described in the device tree,
> so we want to add code in the driver to convert that device-tree
> description into an ACPI description for use on Linux.
>
> This series adds support for generation of ACPI tables and fragments by
> devices. The core support is built into driver model.
>
> Several files are brought over from coreboot to do the actual generation.
>
> As an example of using this new feature, chromebook_coral is updated to
> write out a wide array of ACPI tables including DSDT and SSDT.
>
> This initial version of the series lays out the general approach. More
> work is needed to figure out the difference between CONFIG_ACPIGEN and
> CONFIG_GENERATE_ACPI_TABLE with respect to what is built.
>
> Changes in v4:
> - Add Andy's documentation to struct acpi_gpio
> - Add logging when writinge NHLT
> - Add new patch to use I2cSerialBusV2() instead of I2cSerialBus()
> - Change table version to 3
> - Correct DPTF enable property
> - Correct comment for dm_test_acpi_write_prw()
> - Correct compatible string for gma device
> Drop extra acpi_align() in apl_acpi_hb_write_tables()

v4 has been applied to u-boot-x86/next, thanks!
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH v4 58/59] acpi: Add more documentation for struct acpi_gpio

Andy Shevchenko-2
In reply to this post by Simon Glass-3
On Tue, Sep 22, 2020 at 12:45:43PM -0600, Simon Glass wrote:
> Add some documentation provided by Andy Shevchenko to describe how to
> use struct acpi_gpio.

Thanks!

I see Bin already applied this, perhaps follow up fix is needed. See below.

...

> + * Note that GpioIo doesn't have any means of Active Low / High setting, so a

GpioIo -> GpioIo()

> + * _DSD must be provided to mitigate this.

Plus the following:

"This parameter does not make sense for GpioInt() since it has its own means
to define it."

> + * GpioIo doesn't properly communicate the initial state of the output pin,

GpioIo -> GpioIo()

> + * thus Linux assumes the simple rule:
> + *
> + * Pull Bias       Polarity      Requested...
> + *
> + * Implicit        x             AS IS (assumed firmware configured for us)
> + * Explicit        x (no _DSD)   as Pull Bias (Up == High, Down == Low),
> + *                               assuming non-active (Polarity = !Pull Bias)
> + *
> + * Down            Low           as low, assuming active

> + * Down            High          as high, assuming non-active

Should be read:

" * Down            High          as low, assuming non-active"

> + * Up              Low           as high, assuming non-active
> + * Up              High          as high, assuming active
> + *
> + * GpioIo() can be used as interrupt and in this case the IoRestriction mustn't
> + * be OutputOnly.
> + * It also requires active_low flag from _DSD in cases where it's
> + * needed (better to always provide than rely on above assumption made on OS
> + * level).

--
With Best Regards,
Andy Shevchenko


1234