devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>, Nishanth Menon <nm@ti.com>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP
Date: Fri, 02 Aug 2013 14:43:36 +0100	[thread overview]
Message-ID: <51FBB788.7040209@arm.com> (raw)
In-Reply-To: <51FA917D.4060408@wwwdotorg.org>

On 01/08/13 17:49, Stephen Warren wrote:
> On 08/01/2013 07:54 AM, Mark Rutland wrote:
> ...
>> We seem to be going over two cases, which both feel wrong to me:
>>
>> * One SoC used in multiple boards, where on some boards an OPP cannot be
>>   used because some requirement is not met. In this case, the board's
>>   dts (by including the SoC's dtsi) describes something that's not
>>   necessarily usable, and we seem to have no way to describe in the OPP
>>   table that the OPP is not usable for that board.
> 
> There are probably a lot of examples of this already. For example, for
> pinctrl, people often want the SoC .dtsi file to include "pin
> configuration nodes" (see
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt) for many
> common pinmux configurations in the SoC .dtsi file, so that board files
> can simply refer to the already-existing nodes rather than having to
> write everything from scratch. Obviously, not all common configurations
> are used by every board.
> 
> ...
Agreed, but I am not convinced with the comparison(pinmux and OPPs).
The main concern I have is that if some developer wants to experiment
with various configurations provided by SoC(e.g. I have seen some SoC
where the pinmux have multiple functions and you can chose one of them)
But that's not true with OPPs, if someone experiments with wrong OPP
profile, then it might damage the board permanently.

Regards,
Sudeep


  reply	other threads:[~2013-08-02 13:43 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-30 18:00 [RFC PATCH 0/2] PM / OPP: updates to enable sharing OPPs info Sudeep KarkadaNagesha
2013-07-30 18:00 ` [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP Sudeep KarkadaNagesha
2013-07-30 18:34   ` Stephen Warren
2013-07-30 20:48     ` Nishanth Menon
2013-07-30 21:25       ` Stephen Warren
2013-07-31 11:14       ` Sudeep KarkadaNagesha
2013-07-31 14:46         ` Nishanth Menon
2013-07-31 15:28           ` Sudeep KarkadaNagesha
2013-07-31 15:53             ` Nishanth Menon
2013-07-31 16:40               ` Sudeep KarkadaNagesha
2013-07-31 19:13                 ` Nishanth Menon
2013-07-31 19:55                   ` Nishanth Menon
2013-07-31 15:29           ` Mark Rutland
2013-07-31 15:58             ` Nishanth Menon
2013-07-31 16:11               ` Mark Rutland
2013-07-31 16:27                 ` Nishanth Menon
2013-08-01 13:54                   ` Mark Rutland
2013-08-01 16:25                     ` Nishanth Menon
2013-08-02 13:15                       ` Mark Rutland
2013-08-06 13:45                         ` Nishanth Menon
2013-08-07 16:17                           ` Mark Rutland
2013-08-20 10:00                             ` Sudeep KarkadaNagesha
2013-08-20 14:01                               ` Nishanth Menon
2013-08-20 16:07                                 ` Sudeep KarkadaNagesha
2013-08-21 22:48                               ` Stephen Warren
2013-08-22 11:59                                 ` Mark Rutland
2013-08-22 15:32                                   ` Sudeep KarkadaNagesha
2013-08-22 15:50                                     ` Mark Rutland
2013-08-22 16:28                                       ` Sudeep KarkadaNagesha
2013-08-23 12:26                                         ` Mark Rutland
2013-08-01 16:49                     ` Stephen Warren
2013-08-02 13:43                       ` Sudeep KarkadaNagesha [this message]
2013-08-06 13:29                         ` Nishanth Menon
2013-07-31 21:59                 ` Stephen Warren
2013-07-31 21:51           ` Stephen Warren
2013-08-01 12:15             ` Nishanth Menon
2013-08-01 16:46               ` Stephen Warren
2013-07-31 10:46     ` Sudeep KarkadaNagesha
2013-07-30 18:00 ` [RFC PATCH 2/2] PM / OPP: check for existing OPP list when initialising from device tree Sudeep KarkadaNagesha
2013-07-31 16:39   ` Nishanth Menon

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=51FBB788.7040209@arm.com \
    --to=sudeep.karkadanagesha@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@sisk.pl \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@wwwdotorg.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).