On Wed, 2018-07-04 at 11:22 +0200, Rafael J. Wysocki wrote:
> 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?
I didn't look at them, but I think Sakari is doing the right things
here.
> Anyone from the ARM side of things?
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
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
