linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	Will Deacon <will.deacon@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jisheng Zhang <jszhang@marvell.com>
Subject: Re: [PATCH v2 2/2] ARM64: kernel: PSCI: move PSCI idle management code to drivers/firmware
Date: Mon, 12 Oct 2015 16:35:04 +0100	[thread overview]
Message-ID: <20151012153503.GD7452@leverpostej> (raw)
In-Reply-To: <20151012151220.GA12925@red-moon>

On Mon, Oct 12, 2015 at 04:12:20PM +0100, Lorenzo Pieralisi wrote:
> Hi Mark,
> 
> On Mon, Oct 12, 2015 at 03:29:26PM +0100, Mark Rutland wrote:
> > Hi Lorenzo,
> > 
> > On Mon, Oct 12, 2015 at 12:17:08PM +0100, Lorenzo Pieralisi wrote:
> > > ARM64 PSCI kernel interfaces that initialize idle states and implement
> > > the suspend API to enter them are generic and can be shared with the
> > > ARM architecture.
> > > 
> > > To achieve that goal, this patch moves ARM64 PSCI idle management
> > > code to drivers/firmware by creating a file that contains PSCI
> > > helper functions implementing the common kernel interface required
> > > by ARM and ARM64 to share the PSCI idle management code.
> > > 
> > > The ARM generic CPUidle implementation also requires the definition of
> > > a cpuidle_ops section entry for the kernel to initialize the CPUidle
> > > operations at boot based on the enable-method (ie ARM64 has the
> > > statically initialized cpu_ops counterparts for that purpose); therefore
> > > this patch also adds the required section entry on CONFIG_ARM for PSCI so
> > > that the kernel can initialize the PSCI CPUidle back-end when PSCI is
> > > the probed enable-method.
> > > 
> > > On ARM64 this patch provides no functional change.
> > > 
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Jisheng Zhang <jszhang@marvell.com>
> > > ---
> > >  arch/arm64/kernel/psci.c       |  99 +-----------------------------
> > >  drivers/firmware/Makefile      |   2 +-
> > >  drivers/firmware/psci_cpuops.c | 133 +++++++++++++++++++++++++++++++++++++++++
> > 
> > Do we really need the new file, given most of this lived happily in
> > psci.c previously?
> 
> No, I thought we could separate the PSCI FW API (eg psci_cpu_suspend())
> from helper functions that are basically a kernel glue layer (but we have
> already helper functions in psci.c like psci_tos_resident_on() so..),
> if we think it is fine to keep them in the same file I can move the
> functions to psci.c.

Ok. I guess I don't have strong feelings either way, but it seemed
simpler to keep them in the same file for now.

I understand your rationale, so either way I'm happy.

> > > +#ifdef CONFIG_ARM
> > > +struct cpuidle_ops psci_cpuidle_ops __initdata = {
> > > +	.suspend = psci_cpu_suspend_enter,
> > > +	.init = psci_dt_cpu_init_idle,
> > > +};
> > > +
> > > +CPUIDLE_METHOD_OF_DECLARE(psci, "arm,psci", &psci_cpuidle_ops);
> > > +#endif
> > 
> > Don't these also need to be guarded for CONFIG_CPU_IDLE?
> > 
> > The definitions of cpuidle_ops and CPUIDLE_METHOD_OF_DECLARE in
> > arch/arm/include/asm/cpuidle.h depend on it.
> 
> Not really, they are not guarded, the side effect of not having
> a CONFIG_CPU_IDLE guard is just a struct that is compiled in
> and freed after boot, I thought about that but I am tempted to leave
> it as is to avoid further ifdeffery, I am not fussed either way.

Whoops, I misread the gurards in arch/arm/include/asm/cpuidle.h. Sorry
for the noise!

Given the above, for this or a version with just psci.c:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

  reply	other threads:[~2015-10-12 15:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 11:17 [PATCH v2 0/2] Enabling PSCI based idle on ARM 32-bit platforms Lorenzo Pieralisi
2015-10-12 11:17 ` [PATCH v2 1/2] ARM: cpuidle: remove cpu parameter from the cpuidle_ops suspend hook Lorenzo Pieralisi
2015-10-12 14:56   ` Lina Iyer
2015-10-12 15:40     ` Lorenzo Pieralisi
2015-10-14 13:42       ` Lina Iyer
2015-10-12 11:17 ` [PATCH v2 2/2] ARM64: kernel: PSCI: move PSCI idle management code to drivers/firmware Lorenzo Pieralisi
2015-10-12 14:29   ` Mark Rutland
2015-10-12 15:12     ` Lorenzo Pieralisi
2015-10-12 15:35       ` Mark Rutland [this message]
2015-10-12 15:37   ` Catalin Marinas
2015-10-13  8:32 ` [PATCH v2 0/2] Enabling PSCI based idle on ARM 32-bit platforms Daniel Lezcano
2015-10-13 10:44   ` Lorenzo Pieralisi
2015-10-13 11:17     ` Daniel Lezcano
2015-10-14  8:39       ` Lorenzo Pieralisi
2015-10-13 11:34 ` Jisheng Zhang

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=20151012153503.GD7452@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will.deacon@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 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).