public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Chander Kashyap <k.chander@samsung.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
	Doug Anderson <dianders@chromium.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Kevin Hilman <khilman@linaro.org>,
	Andrew Bresticker <abrestic@chromium.org>,
	Inderpal Singh <inderpal.s@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Chander Kashyap <chander.kashyap@linaro.org>,
	"olof@lixom.net" <olof@lixom.net>,
	Tushar Behera <trblinux@gmail.com>,
	Thomas Abraham <thomas.ab@samsung.com>,
	Abhilash Kesavan <a.kesavan@samsung.com>,
	Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start
Date: Wed, 11 Jun 2014 14:15:00 +0100	[thread overview]
Message-ID: <20140611131500.GA19884@red-moon> (raw)
In-Reply-To: <CADWw7OghkwkMbU=eZG=OhxVowNJy_12UOo_pNYnXbimF73Uwdw@mail.gmail.com>

On Wed, Jun 11, 2014 at 01:14:21PM +0100, Chander Kashyap wrote:
> On Wed, Jun 11, 2014 at 3:43 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > On Wed, Jun 11, 2014 at 05:52:10AM +0100, Chander Kashyap wrote:
> >> Hi Doug,
> >>
> >> On Tue, Jun 10, 2014 at 9:19 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Tue, 10 Jun 2014, Doug Anderson wrote:
> >> >
> >> >> My S-state knowledge is not strong, but I believe that Lorenzo's
> >> >> questions matter if we're using S2 for CPUidle (where we actually turn
> >> >> off power and hot unplug CPUs) but not when we're using S1 for CPUidle
> >> >> (where we just enter WFI/WFE).
> >> >>
> >>
> >> No Its not plain WFI.
> >>
> >> All cores in Exynos5420 can be powered off independently.
> >> This functionality has been tested.
> >>
> >> Below is the link for the posted patches.
> >>
> >> https://lkml.org/lkml/2014/6/10/194
> >>
> >> And as Nicolas wrote, these patches need MCPM for that.
> >
> > Chander, I cast a look into the code and I have a question
> > (you also told me on CPUidle review that only core off
> > is supported in CPUidle).
> >
> > When you say all cores can be powered off independently, do
> > you also mean that clusters can be powered off (in CPUidle) ?
> >
> > I am pointing this out since in the MCPM backend I noticed:
> >
> > "/* TODO: Turn off the cluster here to save power. */"
> >
> > I do not see any cluster power down request in the down path.
> >
> > If I am wrong, ignore my message, I am just writing to help.
> >
> > If you can only power down cores, but not the clusters on idle,
> > please keep in mind that you are currently cleaning and invalidating
> > the L2 when last man is running and this must not be taken
> > lightly since, if L2 stays on, that's a massive energy waste
> > for nothing.
> >
> > So, if clusters stay up, you _have_ to tweak the MCPM backend slightly
> > to avoid cleaning L2, that's pivotal.
> 
> Hi Lorenzo,
> Cluster shutdown is in progress. Abhilash will add support for that.
> 
> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg31104.html

Hi Chander,

thanks. So, as a heads-up:

1) if you merge CPUidle support now, as it is it is at least suboptimal, may
   even burn more energy than it saves. Latencies in the bL idle driver
   are likely to be wrong, since they are for cluster shutdown and for
   TC2, not core power gating that should require shorter target_residencies.
   On top of that, L2 is cleaned and invalidated for nothing.
2) when cluster support is merged, you might want to extend the CPUidle
   driver to add an additional state (ie C1 core gating, C2 cluster
   gating) and to do that you should extend the driver and the MCPM
   back-end accordingly, I discussed that with Nico already some time ago
   and actually it should be fairly easy to do but we have got to talk
   about that.

Thank you,
Lorenzo

> 
> 
> >
> > Lorenzo
> >
> >>
> >> >> I believe that in ChromeOS we use S1 CPUidle and that it works fine.
> >> >> We've never implemented S2 that I'm aware of.
> >> >
> >> > You'll have to rely on MCPM for that.  That's probably why it hasn't
> >> > been implemented before.
> >> >
> >> >
> >> > Nicolas
> >> >
> >> > _______________________________________________
> >> > linux-arm-kernel mailing list
> >> > linux-arm-kernel@lists.infradead.org
> >> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2014-06-11 13:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06 21:43 [PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start Doug Anderson
2014-06-06 22:35 ` Nicolas Pitre
2014-06-06 22:43   ` Doug Anderson
2014-06-06 22:46     ` Andrew Bresticker
2014-06-06 23:14 ` [PATCH v2] " Doug Anderson
2014-06-07  1:34   ` Nicolas Pitre
2014-06-09 18:09   ` Kevin Hilman
2014-06-09 20:05     ` Andrew Bresticker
2014-06-09 20:22       ` Nicolas Pitre
2014-06-09 20:35         ` Kevin Hilman
2014-06-09 20:55           ` Nicolas Pitre
2014-06-16 18:37             ` Doug Anderson
2014-06-16 18:47               ` Nicolas Pitre
2014-06-07 18:12 ` [PATCH] " Lorenzo Pieralisi
2014-06-09 17:03   ` Doug Anderson
2014-06-09 22:38     ` Lorenzo Pieralisi
2014-06-10  8:12       ` Chander Kashyap
2014-06-10 15:21         ` Doug Anderson
2014-06-10 15:49           ` Nicolas Pitre
2014-06-11  4:52             ` Chander Kashyap
2014-06-11 10:13               ` Lorenzo Pieralisi
2014-06-11 12:14                 ` Chander Kashyap
2014-06-11 13:15                   ` Lorenzo Pieralisi [this message]
2014-06-11 13:29                     ` Chander Kashyap
2014-06-11 13:34                     ` Abhilash Kesavan
2014-06-11 15:19               ` Doug Anderson
2014-06-11 15:28                 ` Kukjin Kim
2014-06-13 11:54                   ` Chander Kashyap
2014-06-13 13:29                     ` Nicolas Pitre
2014-06-13 15:10                     ` Doug Anderson
2014-06-16  7:40                       ` Chander Kashyap
2014-06-16 18:35                   ` Doug Anderson

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=20140611131500.GA19884@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=a.kesavan@samsung.com \
    --cc=abrestic@chromium.org \
    --cc=chander.kashyap@linaro.org \
    --cc=dianders@chromium.org \
    --cc=inderpal.s@samsung.com \
    --cc=javier.martinez@collabora.co.uk \
    --cc=k.chander@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.pitre@linaro.org \
    --cc=olof@lixom.net \
    --cc=thomas.ab@samsung.com \
    --cc=trblinux@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox