devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Antti P Miettinen <ananaza@iki.fi>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
	"khilman@linaro.org" <khilman@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"pdeschrijver@nvidia.com" <pdeschrijver@nvidia.com>,
	"nico@linaro.org" <nico@linaro.org>,
	"sboyd@codeaurora.org" <sboyd@codeaurora.org>,
	"amit.kucheria@linaro.org" <amit.kucheria@linaro.org>,
	"t.figa@samsung.com" <t.figa@samsung.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"santosh.shilimkar@ti.com" <santosh.shilimkar@ti.com>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"mark.hambleton@broadcom.com" <mark.hambleton@broadcom.com>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"galak@codeaurora.org" <galak@codeau>
Subject: Re: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
Date: Mon, 27 Jan 2014 18:22:07 +0000	[thread overview]
Message-ID: <20140127182207.GB8367@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140127.144815.1048814583962628826.apm@brigitte.kvy.fi>

On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > That's why I defined the worst case. How did you implemented it in your
> > idle drivers ? That would help generalize it, after all these bindings
> > are there to simplify drivers upstreaming, feedback welcome.
> 
> Currently we do not handle this well downstream either. The problem
> with worst case is that the absolute worst case can be really bad and
> probability of it might be very low. Sorry - no ready answer :-)

Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.

It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.

In the meantime if you have further pieces of feedback please keep them
coming.

Thanks,
Lorenzo

  reply	other threads:[~2014-01-27 18:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 17:47 [PATCH RFC v2 0/2] ARM: defining power states DT bindings Lorenzo Pieralisi
2014-01-20 17:47 ` [PATCH RFC v2 1/2] Documentation: arm: add cache " Lorenzo Pieralisi
2014-01-21 11:49   ` Dave Martin
2014-01-21 14:47     ` Lorenzo Pieralisi
     [not found]     ` <20140121114845.GA2598-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-01-27 12:58       ` Russell King - ARM Linux
2014-01-27 18:10         ` Lorenzo Pieralisi
2014-01-20 17:47 ` [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings Lorenzo Pieralisi
2014-01-21 11:16   ` Vincent Guittot
2014-01-21 13:31     ` Lorenzo Pieralisi
2014-01-21 14:35       ` Amit Kucheria
2014-01-21 15:23         ` Lorenzo Pieralisi
2014-01-22 11:52           ` Mark Brown
2014-01-22 16:23             ` Lorenzo Pieralisi
2014-01-22 18:17               ` Mark Brown
2014-01-22 11:42       ` Mark Brown
2014-01-22 16:33         ` Lorenzo Pieralisi
2014-01-22 18:11           ` Mark Brown
2014-01-22 19:20     ` Lorenzo Pieralisi
2014-01-24  8:40       ` Vincent Guittot
2014-01-24 17:58         ` Lorenzo Pieralisi
2014-01-28  8:24           ` Vincent Guittot
2014-01-29 12:42             ` Lorenzo Pieralisi
2014-01-25  8:15   ` Antti P Miettinen
2014-01-27 11:41     ` Lorenzo Pieralisi
2014-01-27 12:48       ` Antti P Miettinen
2014-01-27 18:22         ` Lorenzo Pieralisi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-01-27 15:59 Dave Martin
2014-01-29 12:33 ` Lorenzo Pieralisi

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=20140127182207.GB8367@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=amit.kucheria@linaro.org \
    --cc=ananaza@iki.fi \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeau \
    --cc=grant.likely@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=khilman@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.hambleton@broadcom.com \
    --cc=nico@linaro.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=sboyd@codeaurora.org \
    --cc=t.figa@samsung.com \
    --cc=vincent.guittot@linaro.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).