From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-acpi@vger.kernel.org, rafael@kernel.org,
mark.rutland@arm.com, broonie@kernel.org, robh@kernel.org,
ahs3@redhat.com
Subject: Re: [RFC 00/15] ACPI graph support
Date: Wed, 5 Oct 2016 21:14:28 +0300 [thread overview]
Message-ID: <20161005181428.GQ1765@lahna.fi.intel.com> (raw)
In-Reply-To: <788f4bcd-605f-2694-5df5-ec7ef1bde233@arm.com>
On Wed, Oct 05, 2016 at 04:30:18PM +0100, Sudeep Holla wrote:
>
>
> 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.
No and we are not ignoring ACPI either with this patch series.
> 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.
So how you propose we deal with this? Add it to the ACPI spec?
next prev parent reply other threads:[~2016-10-05 18:14 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 22:45 [RFC 00/15] ACPI graph support Sakari Ailus
2016-10-04 22:45 ` [RFC 01/15] ACPI / property: Add possiblity to retrieve parent firmware node Sakari Ailus
2016-10-04 22:45 ` [RFC 02/15] device property: Add fwnode_get_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 03/15] ACPI / property: Add fwnode_get_next_child_node() Sakari Ailus
2016-10-04 22:45 ` [RFC 04/15] device property: Add fwnode_get_named_child_node() Sakari Ailus
2016-10-04 22:45 ` [RFC 05/15] ACPI / property: Add support for remote endpoints Sakari Ailus
2016-10-04 22:45 ` [RFC 06/15] device " Sakari Ailus
2016-10-04 22:45 ` [RFC 07/15] device property: Add fwnode_handle_get() Sakari Ailus
2016-10-04 22:45 ` [RFC 08/15] of: Add of_fwnode_handle() to convert device nodes to fwnode_handle Sakari Ailus
2016-10-04 22:45 ` [RFC 09/15] driver core: Arrange headers alphabetically Sakari Ailus
2016-10-04 22:45 ` [RFC 10/15] of: No need to include property.h, fwnode.h is sufficient Sakari Ailus
2016-10-04 22:45 ` [RFC 11/15] device property: Obtain device's fwnode independently of FW type Sakari Ailus
2016-10-04 22:45 ` [RFC 12/15] device property: Add support for fwnode endpoints Sakari Ailus
2016-10-04 22:45 ` [RFC 13/15] of: Add nop implementation of of_get_next_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 14/15] device property: Add fwnode_get_next_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 15/15] ACPI / DSD: Document references, ports and endpoints Sakari Ailus
2016-10-05 9:22 ` [RFC 00/15] ACPI graph support Lorenzo Pieralisi
2016-10-05 11:41 ` Mika Westerberg
2016-10-05 15:06 ` Lorenzo Pieralisi
2016-10-05 15:32 ` Mika Westerberg
2016-10-05 16:18 ` Lorenzo Pieralisi
2016-10-05 20:33 ` Rafael J. Wysocki
2016-10-06 8:57 ` Lorenzo Pieralisi
2016-10-06 9:11 ` Mika Westerberg
2016-10-06 9:57 ` Lorenzo Pieralisi
2016-10-06 11:19 ` Mika Westerberg
2016-10-06 15:31 ` Mark Brown
2016-10-06 16:00 ` Rafael J. Wysocki
2016-10-06 16:14 ` Mark Brown
2016-10-06 17:02 ` Rafael J. Wysocki
2016-10-11 12:44 ` Mark Rutland
2016-10-12 0:19 ` Rafael J. Wysocki
2016-10-06 12:30 ` Rafael J. Wysocki
2016-10-06 10:40 ` Mark Brown
2016-10-06 12:26 ` Mika Westerberg
2016-10-06 13:15 ` Rafael J. Wysocki
2016-10-06 15:23 ` Mark Brown
2016-10-06 15:56 ` Rafael J. Wysocki
2016-10-06 15:57 ` Sudeep Holla
2016-10-06 12:26 ` Rafael J. Wysocki
2016-10-06 21:37 ` Mark Brown
2016-10-10 23:44 ` Rafael J. Wysocki
2016-10-11 12:11 ` Rafael J. Wysocki
2016-10-11 13:05 ` Mark Brown
2016-10-11 12:44 ` Mark Brown
2016-10-11 13:32 ` Mark Rutland
2016-10-12 0:32 ` Rafael J. Wysocki
2016-10-12 12:05 ` Mark Brown
2016-10-12 12:26 ` Rafael J. Wysocki
2016-10-11 13:01 ` Mark Rutland
2016-10-11 13:26 ` Mark Brown
2016-10-11 12:56 ` Mark Rutland
2016-10-06 22:02 ` Sakari Ailus
2016-10-11 12:35 ` Mark Rutland
2016-10-12 9:00 ` Mika Westerberg
2016-10-12 10:28 ` Mark Brown
2016-10-12 11:12 ` Mika Westerberg
2016-10-12 11:25 ` Rafael J. Wysocki
2016-10-12 16:00 ` Mark Brown
2016-10-12 11:14 ` Rafael J. Wysocki
2016-10-12 12:32 ` Mark Brown
2016-10-12 12:42 ` Rafael J. Wysocki
2016-10-12 14:59 ` Mark Brown
2016-10-12 17:50 ` Rafael J. Wysocki
2016-10-06 21:58 ` Sakari Ailus
2016-10-05 15:21 ` Mark Brown
2016-10-05 15:30 ` Sudeep Holla
2016-10-05 18:14 ` Mika Westerberg [this message]
2016-10-05 20:18 ` Rafael J. Wysocki
2016-10-06 10:29 ` Sudeep Holla
2016-10-06 13:04 ` Rafael J. Wysocki
2016-10-06 14:20 ` Sudeep Holla
2016-10-06 17:05 ` Rafael J. Wysocki
2016-10-06 17:20 ` Sudeep Holla
2016-10-11 0:05 ` Rafael J. Wysocki
2016-10-11 8:57 ` Sudeep Holla
2016-10-11 11:59 ` Rafael J. Wysocki
2016-10-11 13:15 ` Mark Brown
2016-10-12 0:35 ` Rafael J. Wysocki
2016-10-06 17:20 ` Al Stone
2016-10-06 20:14 ` Mark Brown
2016-10-06 20:54 ` Al Stone
2016-10-11 12:28 ` Mark Rutland
2016-10-12 1:18 ` Rafael J. Wysocki
2016-10-06 21:10 ` Sakari Ailus
2016-10-11 13:30 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161005181428.GQ1765@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=ahs3@redhat.com \
--cc=broonie@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.