On 05/10/16 12:41, Mika Westerberg wrote:
On Wed, Oct 05, 2016 at 10:22:15AM +0100, Lorenzo Pieralisi wrote:
[ +MarkR, MarkB, Rob, Al - I suspect they may want to have a say]
On Wed, Oct 05, 2016 at 01:45:33AM +0300, Sakari Ailus wrote:
Hello everyone,
I've been working awhile with my collegue Mika Westerberg to bring
firmware graph support to ACPI based systems. In practice the
functionality achieved by these patches is very similar to what the Device
tree provides: the port and the endpoint concept are being employed. The
patches make use of the _DSD property and data extensions to achieve this.
The fwnode interface is extended by graph functionality; this way graph
information originating from both OF and ACPI may be accessed using the
same interface.
There is an ongoing effort to avoid wholesale import of DT bindings
into ACPI, I am not a V4L2 expert but it seems to me that with patches
like the one you have submitted we are getting closer and closer to
achieving it instead of avoiding it.
The whole purpose of PRP0001 ID is to allow DT bindings to be reused in
ACPI systems, so that the drivers can just call device_property_* and
get the properties regardless of the underlying firmware interface.
Does this also mean if there's some new bindings added to DT which ACPI
specification still lacks, then instead of enhancing ACPI specification
adding that to it, we can take a shortcut method of PRP0001 and
completely ignore ACPI. People are trying to do that as it's simple and
faster.
And yes this has been raised multiple times in past, but worth raising
every-time we head in that direction. And it's increasing day-by-day
which is alarming.
Even though you may say no to that, it absolutely prevents no one
to do so unless we control what bindings can be support using DSD.
--
Regards,
Sudeep
--
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
