| Message ID | 1409585324-3678-7-git-send-email-lorenzo.pieralisi@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 >
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).
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
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
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
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
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
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
[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,
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
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
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
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);