On Wed, Jun 27, 2018 at 11:37 AM, Sakari Ailus
<sakari.ailus@xxxxxxxxxxxxxxx> wrote:
> Hi all,
>
> I'm somewhat unhappy with the current state of affairs in ACPI and how the
> graphs as well as references have been implemented. In particular,
> whenever dealing with references to non-device nodes, the implementation
> for ACPI is quite different than on DT, requiring extra properties and
> knowledge of reference types in more generic frameworks that handle these
> references.
>
> The issue stems from the fact that currently ACPI does not allow
> referencing data extension nodes in the node hierarchy in a generic way.
> Both ACPI data extension nodes and device nodes are represented by the
> same fwnode_handle objects at runtime.
>
> Parsing a reference requires knowing what kind of reference it is, for
> instance whether it's a port, an endpoint or a LED. We currently use
> integer properties in the data nodes to tell this ("port" or "endpoint").
> This is problematic as each new type of a reference will add new
> properties to the same DT binding namespace that are not documented in DT
> binding documentation, increasing the likelihood of a clash. This headache
> will continue to increase with each new type of a reference.
>
> What I propose to address these issues is the following:
>
> - Instead of defining ways to refer to data nodes by following integer
> properties, use the names of the data nodes (first package entry of the
> data extension) themselves to do that. This is easier to understand and
> entirely agnostic to the type of the reference (see patch 2).
>
> - Add "@" character (as in DT) to separate the node name and its number.
> The name defines the purpose of the node, such as "port" for graph ports
> and "endpoint" for graph endpoints. This makes parsing easier as the "@"
> character separates the name from the number as well as brings ACPI to
> feature parity with DT in this respect --- the name could theoretically
> include numerals as well.
>
> - Use "reg" property to tell the number, instead of a purpose-defined
> property.
>
> These changes will also bring ACPI to feature parity with DT in two
> respects:
>
> - DT bindings will be sufficient in the vast majority of cases for making
> references.
>
> - References are generic and there is no need to know the type of the
> reference when parsing it.
>
> The benefits of these changes will include
>
> - Avoid incrementally increasing headache in managing properties in the
> DT property binding namespace that are (and likely won't) be part of the
> DT bindings.
>
> - Driver (e.g. LED) changes to support ACPI will be more or less limited
> to switching from OF to fwnode property API.
>
> - Firmware type can be hidded most of the time, and we could get rid of
> (or at not least add more functions like)
> v4l2_fwnode_reference_get_int_prop in
> drivers/media/v4l2-core/v4l2-fwnode.c.
>
> Sakari Ailus (10):
> ACPI: Convert ACPI reference args to generic fwnode reference args
> ACPI: property: Allow making references to non-device nodes
> ACPI / DSD: Add documentation on hierarchical data extension
> references
> ACPI: property: Make the ACPI graph API private
> ACPI: property: Allow direct graph endpoint references
> ACPI: property: Use data node name and reg property for graphs
> ACPI / DSD: graph: Update for hierarchical data extension 1.1
> ACPI / DSD: graph: Fix graph documentation
> ACPI / DSD: graph: If a port has a single endpoint, its value will be
> zero
> ACPI / DSD: graph: Use hierarchical data extension strings for
> references
Does anyone have any comments regarding this series? Mika? Andy?
Anyone from the ARM side of things?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
