diff mbox

[v8,6/8] drivers: cpuidle: CPU idle ARM64 driver

Message ID 1409585324-3678-7-git-send-email-lorenzo.pieralisi@arm.com
State New
Headers show

Commit Message

Lorenzo Pieralisi Sept. 1, 2014, 3:28 p.m. UTC
This patch implements a generic CPU idle driver for ARM64 machines.

It relies on the DT idle states infrastructure to initialize idle
states count and respective parameters. Current code assumes the driver
is managing idle states on all possible CPUs but can be easily
generalized to support heterogenous systems and build cpumasks at
runtime using MIDRs or DT cpu nodes compatible properties.

The driver relies on the arm64 CPU operations to call the idle
initialization hook used to parse and save suspend back-end specific
idle states information upon probing.

Idle state index 0 is always initialized as a simple wfi state, ie always
considered present and functional on all ARM64 platforms.

Idle state indices higher than 0 trigger idle state entry by calling
the cpu_suspend function, that triggers the suspend operation through
the CPU operations suspend back-end hook. cpu_suspend passes the idle
state index as a parameter so that the CPU operations suspend back-end
can retrieve the required idle state data by using the idle state
index to execute a look-up on its internal data structures.

Reviewed-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 drivers/cpuidle/Kconfig         |   5 ++
 drivers/cpuidle/Kconfig.arm64   |  14 +++++
 drivers/cpuidle/Makefile        |   4 ++
 drivers/cpuidle/cpuidle-arm64.c | 121 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 144 insertions(+)
 create mode 100644 drivers/cpuidle/Kconfig.arm64
 create mode 100644 drivers/cpuidle/cpuidle-arm64.c

Comments

Lorenzo Pieralisi Sept. 3, 2014, 5:37 p.m. UTC | #1
Hi Daniel,

On Mon, Sep 01, 2014 at 04:28:42PM +0100, Lorenzo Pieralisi wrote:
> This patch implements a generic CPU idle driver for ARM64 machines.
> 
> It relies on the DT idle states infrastructure to initialize idle
> states count and respective parameters. Current code assumes the driver
> is managing idle states on all possible CPUs but can be easily
> generalized to support heterogenous systems and build cpumasks at
> runtime using MIDRs or DT cpu nodes compatible properties.
> 
> The driver relies on the arm64 CPU operations to call the idle
> initialization hook used to parse and save suspend back-end specific
> idle states information upon probing.
> 
> Idle state index 0 is always initialized as a simple wfi state, ie always
> considered present and functional on all ARM64 platforms.
> 
> Idle state indices higher than 0 trigger idle state entry by calling
> the cpu_suspend function, that triggers the suspend operation through
> the CPU operations suspend back-end hook. cpu_suspend passes the idle
> state index as a parameter so that the CPU operations suspend back-end
> can retrieve the required idle state data by using the idle state
> index to execute a look-up on its internal data structures.
> 
> Reviewed-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

This patch should be ready to go too, is it ok if I split the series
in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
(inclusive of DT bindings and !!this patch!!) and send two separate pull
requests ?

This patch relies on arm64 specific hooks to initialize idle states so
it has to go in at the same time as arm64 specific code in the series,
but through your tree since it is a CPUidle driver.

Thanks a lot !
Lorenzo

> ---
>  drivers/cpuidle/Kconfig         |   5 ++
>  drivers/cpuidle/Kconfig.arm64   |  14 +++++
>  drivers/cpuidle/Makefile        |   4 ++
>  drivers/cpuidle/cpuidle-arm64.c | 121 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 144 insertions(+)
>  create mode 100644 drivers/cpuidle/Kconfig.arm64
>  create mode 100644 drivers/cpuidle/cpuidle-arm64.c
> 
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 8deb934..c5029c1 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -33,6 +33,11 @@ depends on ARM
>  source "drivers/cpuidle/Kconfig.arm"
>  endmenu
>  
> +menu "ARM64 CPU Idle Drivers"
> +depends on ARM64
> +source "drivers/cpuidle/Kconfig.arm64"
> +endmenu
> +
>  menu "MIPS CPU Idle Drivers"
>  depends on MIPS
>  source "drivers/cpuidle/Kconfig.mips"
> diff --git a/drivers/cpuidle/Kconfig.arm64 b/drivers/cpuidle/Kconfig.arm64
> new file mode 100644
> index 0000000..d0a08ed
> --- /dev/null
> +++ b/drivers/cpuidle/Kconfig.arm64
> @@ -0,0 +1,14 @@
> +#
> +# ARM64 CPU Idle drivers
> +#
> +
> +config ARM64_CPUIDLE
> +	bool "Generic ARM64 CPU idle Driver"
> +	select ARM64_CPU_SUSPEND
> +	select DT_IDLE_STATES
> +	help
> +	  Select this to enable generic cpuidle driver for ARM64.
> +	  It provides a generic idle driver whose idle states are configured
> +	  at run-time through DT nodes. The CPUidle suspend backend is
> +	  initialized by calling the CPU operations init idle hook
> +	  provided by architecture code.
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 002b653..4d177b9 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -23,6 +23,10 @@ obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)        += cpuidle-exynos.o
>  obj-$(CONFIG_MIPS_CPS_CPUIDLE)		+= cpuidle-cps.o
>  
>  ###############################################################################
> +# ARM64 drivers
> +obj-$(CONFIG_ARM64_CPUIDLE)		+= cpuidle-arm64.o
> +
> +###############################################################################
>  # POWERPC drivers
>  obj-$(CONFIG_PSERIES_CPUIDLE)		+= cpuidle-pseries.o
>  obj-$(CONFIG_POWERNV_CPUIDLE)		+= cpuidle-powernv.o
> diff --git a/drivers/cpuidle/cpuidle-arm64.c b/drivers/cpuidle/cpuidle-arm64.c
> new file mode 100644
> index 0000000..d25fe6f
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-arm64.c
> @@ -0,0 +1,121 @@
> +/*
> + * ARM64 generic CPU idle driver.
> + *
> + * 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.
> + */
> +
> +#define pr_fmt(fmt) "CPUidle arm64: " fmt
> +
> +#include <linux/cpuidle.h>
> +#include <linux/cpumask.h>
> +#include <linux/cpu_pm.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +
> +#include <asm/cpuidle.h>
> +#include <asm/suspend.h>
> +
> +#include "dt_idle_states.h"
> +
> +/*
> + * arm64_enter_idle_state - Programs CPU to enter the specified state
> + *
> + * dev: cpuidle device
> + * drv: cpuidle driver
> + * idx: state index
> + *
> + * Called from the CPUidle framework to program the device to the
> + * specified target state selected by the governor.
> + */
> +static int arm64_enter_idle_state(struct cpuidle_device *dev,
> +				  struct cpuidle_driver *drv, int idx)
> +{
> +	int ret;
> +
> +	if (!idx) {
> +		cpu_do_idle();
> +		return idx;
> +	}
> +
> +	ret = cpu_pm_enter();
> +	if (!ret) {
> +		/*
> +		 * Pass idle state index to cpu_suspend which in turn will
> +		 * call the CPU ops suspend protocol with idle index as a
> +		 * parameter.
> +		 */
> +		ret = cpu_suspend(idx);
> +
> +		cpu_pm_exit();
> +	}
> +
> +	return ret ? -1 : idx;
> +}
> +
> +static struct cpuidle_driver arm64_idle_driver = {
> +	.name = "arm64_idle",
> +	.owner = THIS_MODULE,
> +	/*
> +	 * State at index 0 is standby wfi and considered standard
> +	 * on all ARM platforms. If in some platforms simple wfi
> +	 * can't be used as "state 0", DT bindings must be implemented
> +	 * to work around this issue and allow installing a special
> +	 * handler for idle state index 0.
> +	 */
> +	.states[0] = {
> +		.enter                  = arm64_enter_idle_state,
> +		.exit_latency           = 1,
> +		.target_residency       = 1,
> +		.power_usage		= UINT_MAX,
> +		.flags                  = CPUIDLE_FLAG_TIME_VALID,
> +		.name                   = "WFI",
> +		.desc                   = "ARM64 WFI",
> +	}
> +};
> +
> +static const struct of_device_id arm64_idle_state_match[] __initconst = {
> +	{ .compatible = "arm,idle-state",
> +	  .data = arm64_enter_idle_state },
> +	{ },
> +};
> +
> +/*
> + * arm64_idle_init
> + *
> + * Registers the arm64 specific cpuidle driver with the cpuidle
> + * framework. It relies on core code to parse the idle states
> + * and initialize them using driver data structures accordingly.
> + */
> +static int __init arm64_idle_init(void)
> +{
> +	int cpu, ret;
> +	struct cpuidle_driver *drv = &arm64_idle_driver;
> +
> +	/*
> +	 * Initialize idle states data, starting at index 1.
> +	 * This driver is DT only, if no DT idle states are detected (ret == 0)
> +	 * let the driver initialization fail accordingly since there is no
> +	 * reason to initialize the idle driver if only wfi is supported.
> +	 */
> +	ret = dt_init_idle_driver(drv, arm64_idle_state_match, 1);
> +	if (ret <= 0)
> +		return ret;
> +	/*
> +	 * Call arch CPU operations in order to initialize
> +	 * idle states suspend back-end specific data
> +	 */
> +	for_each_possible_cpu(cpu) {
> +		ret = cpu_init_idle(cpu);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return cpuidle_register(drv, NULL);
> +}
> +device_initcall(arm64_idle_init);
> -- 
> 1.9.1
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Catalin Marinas Sept. 4, 2014, 4:03 p.m. UTC | #2
On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 01, 2014 at 04:28:42PM +0100, Lorenzo Pieralisi wrote:
> > This patch implements a generic CPU idle driver for ARM64 machines.
> > 
> > It relies on the DT idle states infrastructure to initialize idle
> > states count and respective parameters. Current code assumes the driver
> > is managing idle states on all possible CPUs but can be easily
> > generalized to support heterogenous systems and build cpumasks at
> > runtime using MIDRs or DT cpu nodes compatible properties.
> > 
> > The driver relies on the arm64 CPU operations to call the idle
> > initialization hook used to parse and save suspend back-end specific
> > idle states information upon probing.
> > 
> > Idle state index 0 is always initialized as a simple wfi state, ie always
> > considered present and functional on all ARM64 platforms.
> > 
> > Idle state indices higher than 0 trigger idle state entry by calling
> > the cpu_suspend function, that triggers the suspend operation through
> > the CPU operations suspend back-end hook. cpu_suspend passes the idle
> > state index as a parameter so that the CPU operations suspend back-end
> > can retrieve the required idle state data by using the idle state
> > index to execute a look-up on its internal data structures.
> > 
> > Reviewed-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> 
> This patch should be ready to go too, is it ok if I split the series
> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> (inclusive of DT bindings and !!this patch!!) and send two separate pull
> requests ?

If Daniel/Rafael don't have any objection, I can take the whole series
through the arm64 tree (it seems that patches have been already acked by
Daniel).
Lorenzo Pieralisi Sept. 4, 2014, 5:29 p.m. UTC | #3
On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> > On Mon, Sep 01, 2014 at 04:28:42PM +0100, Lorenzo Pieralisi wrote:
> > > This patch implements a generic CPU idle driver for ARM64 machines.
> > > 
> > > It relies on the DT idle states infrastructure to initialize idle
> > > states count and respective parameters. Current code assumes the driver
> > > is managing idle states on all possible CPUs but can be easily
> > > generalized to support heterogenous systems and build cpumasks at
> > > runtime using MIDRs or DT cpu nodes compatible properties.
> > > 
> > > The driver relies on the arm64 CPU operations to call the idle
> > > initialization hook used to parse and save suspend back-end specific
> > > idle states information upon probing.
> > > 
> > > Idle state index 0 is always initialized as a simple wfi state, ie always
> > > considered present and functional on all ARM64 platforms.
> > > 
> > > Idle state indices higher than 0 trigger idle state entry by calling
> > > the cpu_suspend function, that triggers the suspend operation through
> > > the CPU operations suspend back-end hook. cpu_suspend passes the idle
> > > state index as a parameter so that the CPU operations suspend back-end
> > > can retrieve the required idle state data by using the idle state
> > > index to execute a look-up on its internal data structures.
> > > 
> > > Reviewed-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> > > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > 
> > This patch should be ready to go too, is it ok if I split the series
> > in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> > (inclusive of DT bindings and !!this patch!!) and send two separate pull
> > requests ?
> 
> If Daniel/Rafael don't have any objection, I can take the whole series
> through the arm64 tree (it seems that patches have been already acked by
> Daniel).

Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
follows a different pattern from arm legacy drivers I would like to get
Daniel's ack on this patch too before pushing it. For the records I have
just added two pr_err to signal driver probing error, ultraminor changes
that do not justify a repost.

If Samsung guys do not manifest themselves I would drop patch 8 from
the series till it gets tested and its patch dependency queued too.

Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Will Deacon Sept. 5, 2014, 9:21 a.m. UTC | #4
On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> > On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> > > This patch should be ready to go too, is it ok if I split the series
> > > in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> > > (inclusive of DT bindings and !!this patch!!) and send two separate pull
> > > requests ?
> > 
> > If Daniel/Rafael don't have any objection, I can take the whole series
> > through the arm64 tree (it seems that patches have been already acked by
> > Daniel).
> 
> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
> follows a different pattern from arm legacy drivers I would like to get
> Daniel's ack on this patch too before pushing it. For the records I have
> just added two pr_err to signal driver probing error, ultraminor changes
> that do not justify a repost.
> 
> If Samsung guys do not manifest themselves I would drop patch 8 from
> the series till it gets tested and its patch dependency queued too.

The last patch also has a dependency, as you mentioned to Daniel. I think
we can certainly merge the arm64 parts, and if Daniel doesn't object, then
we can take the driver stuff too but leaving the exynos bits out (i.e. drop
the last patch).

Anyway, if you could repost with the acks you've collected and rearrange it
so the arm64 patches are first in the series, that would be great.

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi Sept. 5, 2014, 3:34 p.m. UTC | #5
On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
> > On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> > > On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> > > > This patch should be ready to go too, is it ok if I split the series
> > > > in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> > > > (inclusive of DT bindings and !!this patch!!) and send two separate pull
> > > > requests ?
> > > 
> > > If Daniel/Rafael don't have any objection, I can take the whole series
> > > through the arm64 tree (it seems that patches have been already acked by
> > > Daniel).
> > 
> > Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
> > follows a different pattern from arm legacy drivers I would like to get
> > Daniel's ack on this patch too before pushing it. For the records I have
> > just added two pr_err to signal driver probing error, ultraminor changes
> > that do not justify a repost.
> > 
> > If Samsung guys do not manifest themselves I would drop patch 8 from
> > the series till it gets tested and its patch dependency queued too.
> 
> The last patch also has a dependency, as you mentioned to Daniel. I think
> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
> the last patch).
> 
> Anyway, if you could repost with the acks you've collected and rearrange it
> so the arm64 patches are first in the series, that would be great.

I can repost it with the acks and rearrange the patches, but for the
pull request I have to know what code can be merged, since there are
some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
tied to the arm64 CPUidle driver, so I *have* to know if the arm64
CPUidle driver (this patch) can get merged and that requires an ack.

If I do not hear from Samsung guys I will drop patch 8.

I will wait till Monday (ie -rc4) and repost, I hope that's acceptable.

Thank you !
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Lezcano Sept. 11, 2014, 8:28 a.m. UTC | #6
On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
> On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
>> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
>>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
>>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
>>>>> This patch should be ready to go too, is it ok if I split the series
>>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
>>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
>>>>> requests ?
>>>>
>>>> If Daniel/Rafael don't have any objection, I can take the whole series
>>>> through the arm64 tree (it seems that patches have been already acked by
>>>> Daniel).
>>>
>>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
>>> follows a different pattern from arm legacy drivers I would like to get
>>> Daniel's ack on this patch too before pushing it. For the records I have
>>> just added two pr_err to signal driver probing error, ultraminor changes
>>> that do not justify a repost.
>>>
>>> If Samsung guys do not manifest themselves I would drop patch 8 from
>>> the series till it gets tested and its patch dependency queued too.
>>
>> The last patch also has a dependency, as you mentioned to Daniel. I think
>> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
>> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
>> the last patch).
>>
>> Anyway, if you could repost with the acks you've collected and rearrange it
>> so the arm64 patches are first in the series, that would be great.
>
> I can repost it with the acks and rearrange the patches, but for the
> pull request I have to know what code can be merged, since there are
> some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
> tied to the arm64 CPUidle driver, so I *have* to know if the arm64
> CPUidle driver (this patch) can get merged and that requires an ack.
>
> If I do not hear from Samsung guys I will drop patch 8.

Well I would prefer to have this patch merged (Cc'ing Tomasz).

> I will wait till Monday (ie -rc4) and repost, I hope that's acceptable.

There is a procedure to solve this branch dependency.

1. Create a patchset with only the changes in drivers/cpuidle (+ misc dt 
stuff)

2. Send the patchset to me.

3. I create a branch with these patches (which will be merged in my 
cpuidle next branch)

4. Merge this branch to a new branch (based on 3.17-rcX) and put on top 
of that your changes for ARM[64]

5. Send the PR to Catalin and Arnd (one for each branch or one for both 
arch)

I will ensure the base branch is not removed until the next merge window.

Does it sound good ?

   -- Daniel
Lorenzo Pieralisi Sept. 11, 2014, 8:57 a.m. UTC | #7
On Thu, Sep 11, 2014 at 09:28:06AM +0100, Daniel Lezcano wrote:
> On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
> > On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
> >> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
> >>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> >>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> >>>>> This patch should be ready to go too, is it ok if I split the series
> >>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> >>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
> >>>>> requests ?
> >>>>
> >>>> If Daniel/Rafael don't have any objection, I can take the whole series
> >>>> through the arm64 tree (it seems that patches have been already acked by
> >>>> Daniel).
> >>>
> >>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
> >>> follows a different pattern from arm legacy drivers I would like to get
> >>> Daniel's ack on this patch too before pushing it. For the records I have
> >>> just added two pr_err to signal driver probing error, ultraminor changes
> >>> that do not justify a repost.
> >>>
> >>> If Samsung guys do not manifest themselves I would drop patch 8 from
> >>> the series till it gets tested and its patch dependency queued too.
> >>
> >> The last patch also has a dependency, as you mentioned to Daniel. I think
> >> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
> >> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
> >> the last patch).
> >>
> >> Anyway, if you could repost with the acks you've collected and rearrange it
> >> so the arm64 patches are first in the series, that would be great.
> >
> > I can repost it with the acks and rearrange the patches, but for the
> > pull request I have to know what code can be merged, since there are
> > some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
> > tied to the arm64 CPUidle driver, so I *have* to know if the arm64
> > CPUidle driver (this patch) can get merged and that requires an ack.
> >
> > If I do not hear from Samsung guys I will drop patch 8.
> 
> Well I would prefer to have this patch merged (Cc'ing Tomasz).

Ok, but:

a) I only compile tested it
b) There is a dts patch dependency for patch 8 to apply cleanly and it
   hasn't been acked (I can't really do it since I can't test it)

   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274179.html

So, what should we do ? Tomasz ?

> > I will wait till Monday (ie -rc4) and repost, I hope that's acceptable.
> 
> There is a procedure to solve this branch dependency.
> 
> 1. Create a patchset with only the changes in drivers/cpuidle (+ misc dt 
> stuff)
> 
> 2. Send the patchset to me.

Ok. I will do it straight away.

> 3. I create a branch with these patches (which will be merged in my 
> cpuidle next branch)
> 4. Merge this branch to a new branch (based on 3.17-rcX) and put on top 
> of that your changes for ARM[64]
> 
> 5. Send the PR to Catalin and Arnd (one for each branch or one for both 
> arch)

There is no ARM code in my series. So to sum it up:

a) I send a pull request to Catalin for arm64 patches on top of the branch
   you are creating with my patches
b) You take care of merging the CPUidle related patches through your
   tree

Is the above what you meant ?

I will send you an mbox for CPUidle related patches straight away (well,
as soon as I know what to do with patch 8).

Thank you very much.
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Lezcano Sept. 11, 2014, 9:32 a.m. UTC | #8
On 09/11/2014 10:57 AM, Lorenzo Pieralisi wrote:
> On Thu, Sep 11, 2014 at 09:28:06AM +0100, Daniel Lezcano wrote:
>> On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
>>> On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
>>>> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
>>>>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
>>>>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
>>>>>>> This patch should be ready to go too, is it ok if I split the series
>>>>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
>>>>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
>>>>>>> requests ?
>>>>>>
>>>>>> If Daniel/Rafael don't have any objection, I can take the whole series
>>>>>> through the arm64 tree (it seems that patches have been already acked by
>>>>>> Daniel).
>>>>>
>>>>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
>>>>> follows a different pattern from arm legacy drivers I would like to get
>>>>> Daniel's ack on this patch too before pushing it. For the records I have
>>>>> just added two pr_err to signal driver probing error, ultraminor changes
>>>>> that do not justify a repost.
>>>>>
>>>>> If Samsung guys do not manifest themselves I would drop patch 8 from
>>>>> the series till it gets tested and its patch dependency queued too.
>>>>
>>>> The last patch also has a dependency, as you mentioned to Daniel. I think
>>>> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
>>>> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
>>>> the last patch).
>>>>
>>>> Anyway, if you could repost with the acks you've collected and rearrange it
>>>> so the arm64 patches are first in the series, that would be great.
>>>
>>> I can repost it with the acks and rearrange the patches, but for the
>>> pull request I have to know what code can be merged, since there are
>>> some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
>>> tied to the arm64 CPUidle driver, so I *have* to know if the arm64
>>> CPUidle driver (this patch) can get merged and that requires an ack.
>>>
>>> If I do not hear from Samsung guys I will drop patch 8.
>>
>> Well I would prefer to have this patch merged (Cc'ing Tomasz).
>
> Ok, but:
>
> a) I only compile tested it
> b) There is a dts patch dependency for patch 8 to apply cleanly and it
>     hasn't been acked (I can't really do it since I can't test it)
>
>     http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274179.html
>
> So, what should we do ? Tomasz ?
>
>>> I will wait till Monday (ie -rc4) and repost, I hope that's acceptable.
>>
>> There is a procedure to solve this branch dependency.
>>
>> 1. Create a patchset with only the changes in drivers/cpuidle (+ misc dt
>> stuff)
>>
>> 2. Send the patchset to me.
>
> Ok. I will do it straight away.
>
>> 3. I create a branch with these patches (which will be merged in my
>> cpuidle next branch)
>> 4. Merge this branch to a new branch (based on 3.17-rcX) and put on top
>> of that your changes for ARM[64]
>>
>> 5. Send the PR to Catalin and Arnd (one for each branch or one for both
>> arch)
>
> There is no ARM code in my series. So to sum it up:
>
> a) I send a pull request to Catalin for arm64 patches on top of the branch
>     you are creating with my patches
 >
> b) You take care of merging the CPUidle related patches through your
>     tree
>
> Is the above what you meant ?

Right, that allows to share a branch across the trees and resolve the 
dependencies when a patchset is touching different subsystems.

I realize the dependency is inverted regarding what I proposed 
initially, so it is up to Catalin to create the branch and I will share 
it with him.

> I will send you an mbox for CPUidle related patches straight away (well,
> as soon as I know what to do with patch 8).

You can send me the patches 6,7,8. I will create the branch with only 
the 2 first patches and re-integrate the patch 8 in the my cpuidle next 
branch if the Samsung guys give their ack later.

Thanks

   -- Daniel
Tomasz Figa Sept. 14, 2014, 4:59 p.m. UTC | #9
[dropping my old @samsung.com address]

On 11.09.2014 10:57, Lorenzo Pieralisi wrote:
> On Thu, Sep 11, 2014 at 09:28:06AM +0100, Daniel Lezcano wrote:
>> On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
>>> On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
>>>> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
>>>>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
>>>>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
>>>>>>> This patch should be ready to go too, is it ok if I split the series
>>>>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
>>>>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
>>>>>>> requests ?
>>>>>>
>>>>>> If Daniel/Rafael don't have any objection, I can take the whole series
>>>>>> through the arm64 tree (it seems that patches have been already acked by
>>>>>> Daniel).
>>>>>
>>>>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
>>>>> follows a different pattern from arm legacy drivers I would like to get
>>>>> Daniel's ack on this patch too before pushing it. For the records I have
>>>>> just added two pr_err to signal driver probing error, ultraminor changes
>>>>> that do not justify a repost.
>>>>>
>>>>> If Samsung guys do not manifest themselves I would drop patch 8 from
>>>>> the series till it gets tested and its patch dependency queued too.
>>>>
>>>> The last patch also has a dependency, as you mentioned to Daniel. I think
>>>> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
>>>> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
>>>> the last patch).
>>>>
>>>> Anyway, if you could repost with the acks you've collected and rearrange it
>>>> so the arm64 patches are first in the series, that would be great.
>>>
>>> I can repost it with the acks and rearrange the patches, but for the
>>> pull request I have to know what code can be merged, since there are
>>> some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
>>> tied to the arm64 CPUidle driver, so I *have* to know if the arm64
>>> CPUidle driver (this patch) can get merged and that requires an ack.
>>>
>>> If I do not hear from Samsung guys I will drop patch 8.
>>
>> Well I would prefer to have this patch merged (Cc'ing Tomasz).
> 
> Ok, but:
> 
> a) I only compile tested it
> b) There is a dts patch dependency for patch 8 to apply cleanly and it
>    hasn't been acked (I can't really do it since I can't test it)
> 
>    http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274179.html
> 
> So, what should we do ? Tomasz ?

Sorry for late reply. I don't work for Samsung anymore so I don't focus
that much on areas other than I still maintain.

As for b) I believe all my patches have been already merged and now
we're just waiting for Kukjin to apply Bart's patch (although it's been
sitting on the ML since July, so probably needs rebasing).

About the patch 8 alone, somebody would have to test it. Maybe Bart or
Krzysztof could find some time to look at this? Other than that, I'm not
quite sure about entry latency you specified. It would look like
entering the state takes longer time than leaving, which I believe is
not the case. However I can't find any place in the code which would use
entry latency, so it might not be that important for now.

Best regards,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bartlomiej Zolnierkiewicz Sept. 23, 2014, 1:42 p.m. UTC | #10
Hi,

On Sunday, September 14, 2014 06:59:20 PM Tomasz Figa wrote:
> [dropping my old @samsung.com address]
> 
> On 11.09.2014 10:57, Lorenzo Pieralisi wrote:
> > On Thu, Sep 11, 2014 at 09:28:06AM +0100, Daniel Lezcano wrote:
> >> On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
> >>> On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
> >>>> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
> >>>>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> >>>>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> >>>>>>> This patch should be ready to go too, is it ok if I split the series
> >>>>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> >>>>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
> >>>>>>> requests ?
> >>>>>>
> >>>>>> If Daniel/Rafael don't have any objection, I can take the whole series
> >>>>>> through the arm64 tree (it seems that patches have been already acked by
> >>>>>> Daniel).
> >>>>>
> >>>>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
> >>>>> follows a different pattern from arm legacy drivers I would like to get
> >>>>> Daniel's ack on this patch too before pushing it. For the records I have
> >>>>> just added two pr_err to signal driver probing error, ultraminor changes
> >>>>> that do not justify a repost.
> >>>>>
> >>>>> If Samsung guys do not manifest themselves I would drop patch 8 from
> >>>>> the series till it gets tested and its patch dependency queued too.
> >>>>
> >>>> The last patch also has a dependency, as you mentioned to Daniel. I think
> >>>> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
> >>>> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
> >>>> the last patch).
> >>>>
> >>>> Anyway, if you could repost with the acks you've collected and rearrange it
> >>>> so the arm64 patches are first in the series, that would be great.
> >>>
> >>> I can repost it with the acks and rearrange the patches, but for the
> >>> pull request I have to know what code can be merged, since there are
> >>> some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
> >>> tied to the arm64 CPUidle driver, so I *have* to know if the arm64
> >>> CPUidle driver (this patch) can get merged and that requires an ack.
> >>>
> >>> If I do not hear from Samsung guys I will drop patch 8.
> >>
> >> Well I would prefer to have this patch merged (Cc'ing Tomasz).
> > 
> > Ok, but:
> > 
> > a) I only compile tested it
> > b) There is a dts patch dependency for patch 8 to apply cleanly and it
> >    hasn't been acked (I can't really do it since I can't test it)
> > 
> >    http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274179.html
> > 
> > So, what should we do ? Tomasz ?
> 
> Sorry for late reply. I don't work for Samsung anymore so I don't focus
> that much on areas other than I still maintain.
> 
> As for b) I believe all my patches have been already merged and now
> we're just waiting for Kukjin to apply Bart's patch (although it's been
> sitting on the ML since July, so probably needs rebasing).
> 
> About the patch 8 alone, somebody would have to test it. Maybe Bart or
> Krzysztof could find some time to look at this? Other than that, I'm not
> quite sure about entry latency you specified. It would look like
> entering the state takes longer time than leaving, which I believe is
> not the case. However I can't find any place in the code which would use
> entry latency, so it might not be that important for now.

I tested this patch series on both Exynos4210 (Origen board) and Exynos5250
(Arndale board).  On Exynos4210 AFTR cpuidle mode is still working fine
with the patch series applied.  On Exynos5250 AFTR is not working but it is
an upstream problem (same happens with v3.17-rc4).

Lorenzo, you can add

Tested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

to the Exynos patch (patch #8).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi Sept. 23, 2014, 6:16 p.m. UTC | #11
On Tue, Sep 23, 2014 at 02:42:48PM +0100, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Sunday, September 14, 2014 06:59:20 PM Tomasz Figa wrote:
> > [dropping my old @samsung.com address]
> > 
> > On 11.09.2014 10:57, Lorenzo Pieralisi wrote:
> > > On Thu, Sep 11, 2014 at 09:28:06AM +0100, Daniel Lezcano wrote:
> > >> On 09/05/2014 05:34 PM, Lorenzo Pieralisi wrote:
> > >>> On Fri, Sep 05, 2014 at 10:21:20AM +0100, Will Deacon wrote:
> > >>>> On Thu, Sep 04, 2014 at 06:29:10PM +0100, Lorenzo Pieralisi wrote:
> > >>>>> On Thu, Sep 04, 2014 at 05:03:20PM +0100, Catalin Marinas wrote:
> > >>>>>> On Wed, Sep 03, 2014 at 06:37:40PM +0100, Lorenzo Pieralisi wrote:
> > >>>>>>> This patch should be ready to go too, is it ok if I split the series
> > >>>>>>> in arm64 arch specific patches (will ask Catalin to pull) and CPUidle ones
> > >>>>>>> (inclusive of DT bindings and !!this patch!!) and send two separate pull
> > >>>>>>> requests ?
> > >>>>>>
> > >>>>>> If Daniel/Rafael don't have any objection, I can take the whole series
> > >>>>>> through the arm64 tree (it seems that patches have been already acked by
> > >>>>>> Daniel).
> > >>>>>
> > >>>>> Thanks a lot Catalin. Since this one is a brand new CPUidle driver and it
> > >>>>> follows a different pattern from arm legacy drivers I would like to get
> > >>>>> Daniel's ack on this patch too before pushing it. For the records I have
> > >>>>> just added two pr_err to signal driver probing error, ultraminor changes
> > >>>>> that do not justify a repost.
> > >>>>>
> > >>>>> If Samsung guys do not manifest themselves I would drop patch 8 from
> > >>>>> the series till it gets tested and its patch dependency queued too.
> > >>>>
> > >>>> The last patch also has a dependency, as you mentioned to Daniel. I think
> > >>>> we can certainly merge the arm64 parts, and if Daniel doesn't object, then
> > >>>> we can take the driver stuff too but leaving the exynos bits out (i.e. drop
> > >>>> the last patch).
> > >>>>
> > >>>> Anyway, if you could repost with the acks you've collected and rearrange it
> > >>>> so the arm64 patches are first in the series, that would be great.
> > >>>
> > >>> I can repost it with the acks and rearrange the patches, but for the
> > >>> pull request I have to know what code can be merged, since there are
> > >>> some arm64 patches (PSCI and CPUidle arm64 back-end) that are strictly
> > >>> tied to the arm64 CPUidle driver, so I *have* to know if the arm64
> > >>> CPUidle driver (this patch) can get merged and that requires an ack.
> > >>>
> > >>> If I do not hear from Samsung guys I will drop patch 8.
> > >>
> > >> Well I would prefer to have this patch merged (Cc'ing Tomasz).
> > > 
> > > Ok, but:
> > > 
> > > a) I only compile tested it
> > > b) There is a dts patch dependency for patch 8 to apply cleanly and it
> > >    hasn't been acked (I can't really do it since I can't test it)
> > > 
> > >    http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274179.html
> > > 
> > > So, what should we do ? Tomasz ?
> > 
> > Sorry for late reply. I don't work for Samsung anymore so I don't focus
> > that much on areas other than I still maintain.
> > 
> > As for b) I believe all my patches have been already merged and now
> > we're just waiting for Kukjin to apply Bart's patch (although it's been
> > sitting on the ML since July, so probably needs rebasing).
> > 
> > About the patch 8 alone, somebody would have to test it. Maybe Bart or
> > Krzysztof could find some time to look at this? Other than that, I'm not
> > quite sure about entry latency you specified. It would look like
> > entering the state takes longer time than leaving, which I believe is
> > not the case. However I can't find any place in the code which would use
> > entry latency, so it might not be that important for now.
> 
> I tested this patch series on both Exynos4210 (Origen board) and Exynos5250
> (Arndale board).  On Exynos4210 AFTR cpuidle mode is still working fine
> with the patch series applied.  On Exynos5250 AFTR is not working but it is
> an upstream problem (same happens with v3.17-rc4).
> 
> Lorenzo, you can add
> 
> Tested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> 
> to the Exynos patch (patch #8).

Thanks a lot, that's great. I hope Daniel can add the tag and get this
merged.

Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lorenzo Pieralisi Sept. 29, 2014, 11:08 a.m. UTC | #12
On Sun, Sep 14, 2014 at 05:59:20PM +0100, Tomasz Figa wrote:

[...]

> About the patch 8 alone, somebody would have to test it. Maybe Bart or
> Krzysztof could find some time to look at this? Other than that, I'm not
> quite sure about entry latency you specified. It would look like
> entering the state takes longer time than leaving, which I believe is
> not the case. However I can't find any place in the code which would use
> entry latency, so it might not be that important for now.

I added that entry latency value because I thought that when entering that
idle state the CPU had to flush the outercache, which I do not think that's
what's really happening on Exynos.

Since Bart's patch to define cpu nodes in DT is making it to the
mainline, this leaves us time to find out what that entry-latency-us value
should be and patch the dts accordingly (Exynos CPUidle DT changes are
not making it for this cycle, so we have time to update the patch
accordingly).

entry-latency-us is used to compute CPUidle exit_latency so it has to be
correct, and I rely on Samsung guys to provide me with that value, or
I will ask them to set it properly for me.

Thanks,
Lorenzo

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 8deb934..c5029c1 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -33,6 +33,11 @@  depends on ARM
 source "drivers/cpuidle/Kconfig.arm"
 endmenu
 
+menu "ARM64 CPU Idle Drivers"
+depends on ARM64
+source "drivers/cpuidle/Kconfig.arm64"
+endmenu
+
 menu "MIPS CPU Idle Drivers"
 depends on MIPS
 source "drivers/cpuidle/Kconfig.mips"
diff --git a/drivers/cpuidle/Kconfig.arm64 b/drivers/cpuidle/Kconfig.arm64
new file mode 100644
index 0000000..d0a08ed
--- /dev/null
+++ b/drivers/cpuidle/Kconfig.arm64
@@ -0,0 +1,14 @@ 
+#
+# ARM64 CPU Idle drivers
+#
+
+config ARM64_CPUIDLE
+	bool "Generic ARM64 CPU idle Driver"
+	select ARM64_CPU_SUSPEND
+	select DT_IDLE_STATES
+	help
+	  Select this to enable generic cpuidle driver for ARM64.
+	  It provides a generic idle driver whose idle states are configured
+	  at run-time through DT nodes. The CPUidle suspend backend is
+	  initialized by calling the CPU operations init idle hook
+	  provided by architecture code.
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 002b653..4d177b9 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -23,6 +23,10 @@  obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)        += cpuidle-exynos.o
 obj-$(CONFIG_MIPS_CPS_CPUIDLE)		+= cpuidle-cps.o
 
 ###############################################################################
+# ARM64 drivers
+obj-$(CONFIG_ARM64_CPUIDLE)		+= cpuidle-arm64.o
+
+###############################################################################
 # POWERPC drivers
 obj-$(CONFIG_PSERIES_CPUIDLE)		+= cpuidle-pseries.o
 obj-$(CONFIG_POWERNV_CPUIDLE)		+= cpuidle-powernv.o
diff --git a/drivers/cpuidle/cpuidle-arm64.c b/drivers/cpuidle/cpuidle-arm64.c
new file mode 100644
index 0000000..d25fe6f
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-arm64.c
@@ -0,0 +1,121 @@ 
+/*
+ * ARM64 generic CPU idle driver.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "CPUidle arm64: " fmt
+
+#include <linux/cpuidle.h>
+#include <linux/cpumask.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include <asm/cpuidle.h>
+#include <asm/suspend.h>
+
+#include "dt_idle_states.h"
+
+/*
+ * arm64_enter_idle_state - Programs CPU to enter the specified state
+ *
+ * dev: cpuidle device
+ * drv: cpuidle driver
+ * idx: state index
+ *
+ * Called from the CPUidle framework to program the device to the
+ * specified target state selected by the governor.
+ */
+static int arm64_enter_idle_state(struct cpuidle_device *dev,
+				  struct cpuidle_driver *drv, int idx)
+{
+	int ret;
+
+	if (!idx) {
+		cpu_do_idle();
+		return idx;
+	}
+
+	ret = cpu_pm_enter();
+	if (!ret) {
+		/*
+		 * Pass idle state index to cpu_suspend which in turn will
+		 * call the CPU ops suspend protocol with idle index as a
+		 * parameter.
+		 */
+		ret = cpu_suspend(idx);
+
+		cpu_pm_exit();
+	}
+
+	return ret ? -1 : idx;
+}
+
+static struct cpuidle_driver arm64_idle_driver = {
+	.name = "arm64_idle",
+	.owner = THIS_MODULE,
+	/*
+	 * State at index 0 is standby wfi and considered standard
+	 * on all ARM platforms. If in some platforms simple wfi
+	 * can't be used as "state 0", DT bindings must be implemented
+	 * to work around this issue and allow installing a special
+	 * handler for idle state index 0.
+	 */
+	.states[0] = {
+		.enter                  = arm64_enter_idle_state,
+		.exit_latency           = 1,
+		.target_residency       = 1,
+		.power_usage		= UINT_MAX,
+		.flags                  = CPUIDLE_FLAG_TIME_VALID,
+		.name                   = "WFI",
+		.desc                   = "ARM64 WFI",
+	}
+};
+
+static const struct of_device_id arm64_idle_state_match[] __initconst = {
+	{ .compatible = "arm,idle-state",
+	  .data = arm64_enter_idle_state },
+	{ },
+};
+
+/*
+ * arm64_idle_init
+ *
+ * Registers the arm64 specific cpuidle driver with the cpuidle
+ * framework. It relies on core code to parse the idle states
+ * and initialize them using driver data structures accordingly.
+ */
+static int __init arm64_idle_init(void)
+{
+	int cpu, ret;
+	struct cpuidle_driver *drv = &arm64_idle_driver;
+
+	/*
+	 * Initialize idle states data, starting at index 1.
+	 * This driver is DT only, if no DT idle states are detected (ret == 0)
+	 * let the driver initialization fail accordingly since there is no
+	 * reason to initialize the idle driver if only wfi is supported.
+	 */
+	ret = dt_init_idle_driver(drv, arm64_idle_state_match, 1);
+	if (ret <= 0)
+		return ret;
+	/*
+	 * Call arch CPU operations in order to initialize
+	 * idle states suspend back-end specific data
+	 */
+	for_each_possible_cpu(cpu) {
+		ret = cpu_init_idle(cpu);
+		if (ret)
+			return ret;
+	}
+
+	return cpuidle_register(drv, NULL);
+}
+device_initcall(arm64_idle_init);