Re: [PATCH V3 15/17] ARM: exynos: cpuidle: Disable cpuidle for 5440

2014-04-08 Thread Nicolas Pitre
On Tue, 8 Apr 2014, Daniel Lezcano wrote:

> On 04/08/2014 02:51 PM, Amit Kucheria wrote:
> > On Tue, Apr 8, 2014 at 5:49 PM, Daniel Lezcano
> > mailto:daniel.lezc...@linaro.org>> wrote:
> >
> > There is no point to register the cpuidle driver for the 5440 as it
> > has only
> > one WFI state which is the default idle function when the cpuidle
> > driver is
> > disabled.
> >
> > By disabling cpuidle we prevent to enter to the governor computation for
> > nothing, thus saving a lot of processing time.
> >
> > The only drawback is the statistic via sysfs on this state which is
> > lost but
> > it is meaningless and it could be retrieved from the ftrace easily.
> >
> >
> > So for the future, you'll only merge platform drivers that enable
> > something more than WFI?
> 
> Well, I already picked up a driver with only WFI because I knew the next idle
> states were in preparation. But adding a cpuidle driver just for WFI is no
> sense and if, for a reason I missed, it is really needed, I guess a generic
> WFI cpuidle driver for all platforms would be make much more sense.

Better relegate WFI-only configurations to arch_cpu_idle().


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V3 15/17] ARM: exynos: cpuidle: Disable cpuidle for 5440

2014-04-08 Thread Daniel Lezcano

On 04/08/2014 02:51 PM, Amit Kucheria wrote:

On Tue, Apr 8, 2014 at 5:49 PM, Daniel Lezcano
mailto:daniel.lezc...@linaro.org>> wrote:

There is no point to register the cpuidle driver for the 5440 as it
has only
one WFI state which is the default idle function when the cpuidle
driver is
disabled.

By disabling cpuidle we prevent to enter to the governor computation for
nothing, thus saving a lot of processing time.

The only drawback is the statistic via sysfs on this state which is
lost but
it is meaningless and it could be retrieved from the ftrace easily.


So for the future, you'll only merge platform drivers that enable
something more than WFI?


Well, I already picked up a driver with only WFI because I knew the next 
idle states were in preparation. But adding a cpuidle driver just for 
WFI is no sense and if, for a reason I missed, it is really needed, I 
guess a generic WFI cpuidle driver for all platforms would be make much 
more sense.



Signed-off-by: Daniel Lezcano mailto:daniel.lezc...@linaro.org>>


In that case, Acked-by: Amit Kucheria mailto:amit.kuche...@linaro.org>>

---
  arch/arm/mach-exynos/cpuidle.c |5 -
  arch/arm/mach-exynos/exynos.c  |3 +++
  2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c
b/arch/arm/mach-exynos/cpuidle.c
index 4b94181..a1f111e 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -16,8 +16,6 @@
  #include 
  #include 

-#include 
-
  #include "common.h"

  static int idle_finisher(unsigned long flags)
@@ -77,9 +75,6 @@ static int exynos_cpuidle_probe(struct
platform_device *pdev)
  {
 int ret;

-   if (soc_is_exynos5440())
-   exynos_idle_driver.state_count = 1;
-
 ret = cpuidle_register(&exynos_idle_driver, NULL);
 if (ret) {
 dev_err(&pdev->dev, "failed to register cpuidle
driver\n");
diff --git a/arch/arm/mach-exynos/exynos.c
b/arch/arm/mach-exynos/exynos.c
index b567361..fe8dac8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -227,6 +227,9 @@ static struct platform_device exynos_cpuidle = {

  void __init exynos_cpuidle_init(void)
  {
+   if (soc_is_exynos5440())
+   return;
+
 platform_device_register(&exynos_cpuidle);
  }

--
1.7.9.5


___
linaro-kernel mailing list
linaro-ker...@lists.linaro.org 
http://lists.linaro.org/mailman/listinfo/linaro-kernel





--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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