linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 4/8] arm64: kernel: introduce cpu_init_idle CPU operation
Date: Wed, 3 Sep 2014 18:46:45 +0100	[thread overview]
Message-ID: <20140903174645.GK1824@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140903173437.GI92149@ilina-mac.local>

On Wed, Sep 03, 2014 at 06:34:37PM +0100, Lina Iyer wrote:
> On Mon, Sep 01 2014 at 09:28 -0600, Lorenzo Pieralisi wrote:
> >The CPUidle subsystem on ARM64 machines requires the idle states
> >implementation back-end to initialize idle states parameter upon
> >boot. This patch adds a hook in the CPU operations structure that
> >should be initialized by the CPU operations back-end in order to
> >provide a function that initializes cpu idle states.
> >
> >This patch also adds the infrastructure to arm64 kernel required
> >to export the CPU operations based initialization interface, so
> >that drivers (ie CPUidle) can use it when they are initialized
> >at probe time.
> >
> I like the change for ARM64.
> However, that raises a question, how do I have the same driver that
> should get probed by a platform device (on 32 bit ARM) and getting called
> from cpu_init_idle on ARM64?

I am not following you sorry. The ARM64 CPUidle driver calls the arm64
cpu_init_idle hooks to initialize idle states (in a generic way from
a driver perspective), not the other way around.

On ARM64 your idle driver rely on an arm64 suspend back-end (eg PSCI) to
enter idle states, it works in a different way from ARM, on purpose.

Have a look at what the code does, it won't be the same driver that's
for certain, since on arm64 I do not want to cope with per-platform
CPUidle state enter functions anymore, the arm64 cpu_ops suspend hook
implements the idle state enter method.

Lorenzo

> >Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> >Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >---
> > arch/arm64/include/asm/cpu_ops.h |  3 +++
> > arch/arm64/include/asm/cpuidle.h | 13 +++++++++++++
> > arch/arm64/kernel/Makefile       |  1 +
> > arch/arm64/kernel/cpuidle.c      | 31 +++++++++++++++++++++++++++++++
> > 4 files changed, 48 insertions(+)
> > create mode 100644 arch/arm64/include/asm/cpuidle.h
> > create mode 100644 arch/arm64/kernel/cpuidle.c
> >
> >diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> >index d7b4b38..47dfa31 100644
> >--- a/arch/arm64/include/asm/cpu_ops.h
> >+++ b/arch/arm64/include/asm/cpu_ops.h
> >@@ -28,6 +28,8 @@ struct device_node;
> >  *		enable-method property.
> >  * @cpu_init:	Reads any data necessary for a specific enable-method from the
> >  *		devicetree, for a given cpu node and proposed logical id.
> >+ * @cpu_init_idle: Reads any data necessary to initialize CPU idle states from
> >+ *		devicetree, for a given cpu node and proposed logical id.
> >  * @cpu_prepare: Early one-time preparation step for a cpu. If there is a
> >  *		mechanism for doing so, tests whether it is possible to boot
> >  *		the given CPU.
> >@@ -47,6 +49,7 @@ struct device_node;
> > struct cpu_operations {
> > 	const char	*name;
> > 	int		(*cpu_init)(struct device_node *, unsigned int);
> >+	int		(*cpu_init_idle)(struct device_node *, unsigned int);
> > 	int		(*cpu_prepare)(unsigned int);
> > 	int		(*cpu_boot)(unsigned int);
> > 	void		(*cpu_postboot)(void);
> >diff --git a/arch/arm64/include/asm/cpuidle.h b/arch/arm64/include/asm/cpuidle.h
> >new file mode 100644
> >index 0000000..b52a993
> >--- /dev/null
> >+++ b/arch/arm64/include/asm/cpuidle.h
> >@@ -0,0 +1,13 @@
> >+#ifndef __ASM_CPUIDLE_H
> >+#define __ASM_CPUIDLE_H
> >+
> >+#ifdef CONFIG_CPU_IDLE
> >+extern int cpu_init_idle(unsigned int cpu);
> >+#else
> >+static inline int cpu_init_idle(unsigned int cpu)
> >+{
> >+	return -EOPNOTSUPP;
> >+}
> >+#endif
> >+
> >+#endif
> >diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> >index 383d81d..be78980 100644
> >--- a/arch/arm64/kernel/Makefile
> >+++ b/arch/arm64/kernel/Makefile
> >@@ -27,6 +27,7 @@ arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o
> > arm64-obj-$(CONFIG_HW_PERF_EVENTS)	+= perf_event.o
> > arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)	+= hw_breakpoint.o
> > arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND)	+= sleep.o suspend.o
> >+arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
> > arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
> > arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
> > arm64-obj-$(CONFIG_EFI)			+= efi.o efi-stub.o efi-entry.o
> >diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
> >new file mode 100644
> >index 0000000..19d17f5
> >--- /dev/null
> >+++ b/arch/arm64/kernel/cpuidle.c
> >@@ -0,0 +1,31 @@
> >+/*
> >+ * ARM64 CPU idle arch support
> >+ *
> >+ * Copyright (C) 2014 ARM Ltd.
> >+ * Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >+ *
> >+ * This program is free software; you can redistribute it and/or modify
> >+ * it under the terms of the GNU General Public License version 2 as
> >+ * published by the Free Software Foundation.
> >+ */
> >+
> >+#include <linux/of.h>
> >+#include <linux/of_device.h>
> >+
> >+#include <asm/cpuidle.h>
> >+#include <asm/cpu_ops.h>
> >+
> >+int cpu_init_idle(unsigned int cpu)
> >+{
> >+	int ret = -EOPNOTSUPP;
> >+	struct device_node *cpu_node = of_cpu_device_node_get(cpu);
> >+
> >+	if (!cpu_node)
> >+		return -ENODEV;
> >+
> >+	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_init_idle)
> >+		ret = cpu_ops[cpu]->cpu_init_idle(cpu_node, cpu);
> >+
> >+	of_node_put(cpu_node);
> >+	return ret;
> >+}
> >-- 
> >1.9.1
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2014-09-03 17:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01 15:28 [PATCH v8 0/8] ARM generic idle states Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 1/8] arm64: kernel: refactor the CPU suspend API for retention states Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 2/8] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 3/8] drivers: cpuidle: implement DT based idle states infrastructure Lorenzo Pieralisi
2014-09-03 13:25   ` Daniel Lezcano
2014-09-03 17:30     ` Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 4/8] arm64: kernel: introduce cpu_init_idle CPU operation Lorenzo Pieralisi
2014-09-03 17:34   ` Lina Iyer
2014-09-03 17:46     ` Lorenzo Pieralisi [this message]
2014-09-03 19:16       ` Lina Iyer
2014-09-01 15:28 ` [PATCH v8 5/8] arm64: add PSCI CPU_SUSPEND based cpu_suspend support Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 6/8] drivers: cpuidle: CPU idle ARM64 driver Lorenzo Pieralisi
2014-09-03 17:37   ` Lorenzo Pieralisi
2014-09-04 16:03     ` Catalin Marinas
2014-09-04 17:29       ` Lorenzo Pieralisi
2014-09-05  9:21         ` Will Deacon
2014-09-05 15:34           ` Lorenzo Pieralisi
2014-09-11  8:28             ` Daniel Lezcano
2014-09-11  8:57               ` Lorenzo Pieralisi
2014-09-11  9:32                 ` Daniel Lezcano
2014-09-12 10:32                   ` Catalin Marinas
2014-09-12 11:26                     ` Lorenzo Pieralisi
2014-09-23 13:35                       ` Bartlomiej Zolnierkiewicz
2014-09-23 18:14                         ` Lorenzo Pieralisi
2014-09-14 16:59                 ` Tomasz Figa
2014-09-23 13:42                   ` Bartlomiej Zolnierkiewicz
2014-09-23 18:16                     ` Lorenzo Pieralisi
2014-09-29 11:08                   ` Lorenzo Pieralisi
2014-09-01 15:28 ` [PATCH v8 7/8] drivers: cpuidle: initialize big.LITTLE driver through DT Lorenzo Pieralisi
2014-09-03 13:29   ` Daniel Lezcano
2014-09-01 15:28 ` [PATCH v8 8/8] drivers: cpuidle: initialize Exynos " Lorenzo Pieralisi
2014-09-03 13:32   ` Daniel Lezcano
2014-09-03 17:29     ` 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=20140903174645.GK1824@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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).