All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 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 17:18:00 +0100	[thread overview]
Message-ID: <20161005161800.GA22433@red-moon> (raw)
In-Reply-To: <20161005153229.GO1765@lahna.fi.intel.com>

On Wed, Oct 05, 2016 at 06:32:29PM +0300, Mika Westerberg wrote:

[...]

> > FWIW I had a quick look at dts bindings with "compatible = nokia,smia"
> > and related kernel driver.
> > 
> > Those nodes require properties like clocks and power supplies, it
> > seems to me that there are already ACPI PM methods to control those
> > properties and therefore they should not be handled with PRP0001,
> > I am happy to be corrected if I am wrong.
> 
> Clocks and power supplies should be handled as native ACPI
> PowerResources. We are not trying to represent those here.
> 
> > When you start matching whole subsystem through PRP0001 and related
> > compatible strings you can end up in a situation where DT and ACPI
> > FW handling clash and that's why we were opposed to mixing them from
> > the beginning, in ARM world if we need a DT we boot with a devicetree.
> > 
> > If PRP0001 is used for leaf-nodes drivers properties it may work,
> > everything else, frankly, is a bit of a gamble you are taking.
> 
> The hardware we are describing is exactly the same, only thing that
> changes is the firmware interface. So if there is a hardware property
> that cannot be discovered automatically it needs to be provided by the
> firmware, like ACPI.

We certainly agree that HW is the same and that the firmware interfaces
differ, that's why mixing them is not exactly ideal.

> If it happens that the property already has an existing DT binding, why
> do you think it is gambling to use it instead of inventing the same with
> annother name for ACPI?

Do not spin the argument. I am telling you that what I am worried
about is mixing the interfaces because that might trigger kernel
control paths clashing while controlling HW (DT native vs ACPI control
methods). I am pretty sure this won't happen, still, if you do not mind
please post this series (and drivers actually making use of it) to a
wider audience (which includes devicetree and ARM mailing list) and we
will restart the discussion from there.

Thanks,
Lorenzo

  reply	other threads:[~2016-10-05 16:17 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 [this message]
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
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=20161005161800.GA22433@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=ahs3@redhat.com \
    --cc=broonie@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.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.