Hi Lorenzo,
On 10/05/16 12:22, 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.
For your information, Al is working on a process to submit _DSD
bindings and this patchset should at least be vetted within that
context.
It is an RFC and my comment is that I do not like the direction
this ACPI->_DSD->DT is taking, I would like to understand where
this is intended to stop because I am getting worried.
Thank you for your feedback.
The ACPI standard defines the syntax for _DSD property and data
extensions but it does not provide a solution for documenting these
properties. In other words, it does provide a mechanism but it does not
tell how and for which specific purposes that mechanism should or may be
used. The _DSD property extension specification strongly discourages the
use of _DSD for purposes that already are within the scope of the ACPI
standard. In this respect, the use of _DSD in this RFC patchset does
conform to the ACPI standard specifications.
That said, I do recognise that --- as we do have a single interface to
access the properties in drivers --- there must be uniform use of these
properties by firmware implementations or there will be problems. This
holds true independently of the firmware implementation, be it Device
tree, ACPI or both.
The Device tree binding documentation is part of the kernel and that's
what the FDT binaries are expected to use, too. The bindings are Linux
specific and, as far as I understand, cannot be expected to be used by
other operating systems even on same hardware.
ACPI should be more generic than that. Already, you can find ACPI BIOS
options for choosing the operating system you're running on. This is
hardly ideal.
AFAIU, the _DSD property database is intended for documenting the
properties drivers use, and as long as the DT properties in the Linux
kernel and in the _DSD property database match, a driver should be
safely able to use those properties independently of the firmware
implementation.
I do not agree with the proposition of making concepts and
implementation different on ACPI for the sake of it being ACPI. With
_DSD, the ACPI does support the same tree structure of nodes and
properties as DT; I see no reason why "ACPI native" support for this
class of constructs could not (or yet, even should not) use the same
mechanisms as the Device tree does. There's simply no need to reinvent
the wheel.
The patchset makes use of not only _DSD properties but also the _DSD
data extension. In order for that not to remain Linux specific, the next
logical step would be to extend the scope of the _DSD property database
to include _DSD data extension in this respect and document the following:
1) how _DSD data extension graph nodes are referenced,
2) port and endpoint concepts and how they are to be used,
3) generic properties defined in
Documentation/devicetree/bindings/media/video-interfaces.txt to the _DSD
database and
4) driver specific properties.
The ports and endpoints are not part (or have not been a part) of Device
tree itself, but they are the established practice on Linux and they
have worked well. Yet they do not have anything Linux specific as such:
they simply are a mechanism to describe the hardware.
--
Kind regards,
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx
--
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
