Re: [PATCH] ARM: Remove __ref on hotplug cpu die path

2015-09-14 Thread Viresh Kumar 
On 14-09-15, 17:23, Stephen Boyd wrote:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
> 
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
> 
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
> 
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Barry Song <bao...@kernel.org>
> Cc: Andy Gross <agr...@codeaurora.org>
> Cc: Viresh Kumar <vire...@kernel.org>
> Cc: Shiraz Hashim <shiraz.linux.ker...@gmail.com>
> Cc: Stephen Warren <swar...@wwwdotorg.org>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: Sudeep Holla <sudeep.ho...@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: <linux-omap@vger.kernel.org>
> Cc: <linux-arm-...@vger.kernel.org>
> Cc: <spear-de...@list.st.com>
> Cc: <linux-te...@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---
> 
> This patch can be broken up into per-SoC if desired.
> 
>  arch/arm/mach-spear/hotplug.c| 2 +-

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>

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

[PATCH 14/18] ARM/omap2/timer: Migrate to new 'set-state' interface

2015-07-16 Thread Viresh Kumar 
Migrate omap2 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap2/timer.c | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index cac46d852da1..16b37e7196f5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -102,38 +102,38 @@ static int omap2_gp_timer_set_next_event(unsigned long 
cycles,
return 0;
 }
 
-static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
-   struct clock_event_device *evt)
+static int omap2_gp_timer_shutdown(struct clock_event_device *evt)
+{
+   __omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
+   return 0;
+}
+
+static int omap2_gp_timer_set_periodic(struct clock_event_device *evt)
 {
u32 period;
 
__omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
 
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   period = clkev.rate / HZ;
-   period -= 1;
-   /* Looks like we need to first set the load value separately */
-   __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
- 0x - period, OMAP_TIMER_POSTED);
-   __omap_dm_timer_load_start(clkev,
-   OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
-   0x - period, OMAP_TIMER_POSTED);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   break;
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+   period = clkev.rate / HZ;
+   period -= 1;
+   /* Looks like we need to first set the load value separately */
+   __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG, 0x - period,
+ OMAP_TIMER_POSTED);
+   __omap_dm_timer_load_start(clkev,
+  OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
+  0x - period, OMAP_TIMER_POSTED);
+   return 0;
 }
 
 static struct clock_event_device clockevent_gpt = {
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .rating = 300,
-   .set_next_event = omap2_gp_timer_set_next_event,
-   .set_mode   = omap2_gp_timer_set_mode,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .rating = 300,
+   .set_next_event = omap2_gp_timer_set_next_event,
+   .set_state_shutdown = omap2_gp_timer_shutdown,
+   .set_state_periodic = omap2_gp_timer_set_periodic,
+   .set_state_oneshot  = omap2_gp_timer_shutdown,
+   .tick_resume= omap2_gp_timer_shutdown,
 };
 
 static struct property device_disabled = {
-- 
2.4.0

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

[PATCH 12/18] ARM/omap1/time: Migrate to new 'set-state' interface

2015-07-16 Thread Viresh Kumar 
Migrate omap driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap1/time.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index a7588cfd0286..524977a31a49 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -124,29 +124,26 @@ static int omap_mpu_set_next_event(unsigned long cycles,
return 0;
 }
 
-static void omap_mpu_set_mode(enum clock_event_mode mode,
- struct clock_event_device *evt)
+static int omap_mpu_set_oneshot(struct clock_event_device *evt)
 {
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   omap_mpu_set_autoreset(0);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   omap_mpu_timer_stop(0);
-   omap_mpu_remove_autoreset(0);
-   break;
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+   omap_mpu_timer_stop(0);
+   omap_mpu_remove_autoreset(0);
+   return 0;
+}
+
+static int omap_mpu_set_periodic(struct clock_event_device *evt)
+{
+   omap_mpu_set_autoreset(0);
+   return 0;
 }
 
 static struct clock_event_device clockevent_mpu_timer1 = {
-   .name   = mpu_timer1,
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .set_next_event = omap_mpu_set_next_event,
-   .set_mode   = omap_mpu_set_mode,
+   .name   = mpu_timer1,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_next_event = omap_mpu_set_next_event,
+   .set_state_periodic = omap_mpu_set_periodic,
+   .set_state_oneshot  = omap_mpu_set_oneshot,
 };
 
 static irqreturn_t omap_mpu_timer1_interrupt(int irq, void *dev_id)
-- 
2.4.0

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

[PATCH 13/18] ARM/omap1/timer32: Migrate to new 'set-state' interface

2015-07-16 Thread Viresh Kumar 
Migrate omap timer32 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap1/timer32k.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 36bf174b3fac..0ae6c52a7d70 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -114,29 +114,28 @@ static int omap_32k_timer_set_next_event(unsigned long 
delta,
return 0;
 }
 
-static void omap_32k_timer_set_mode(enum clock_event_mode mode,
-   struct clock_event_device *evt)
+static int omap_32k_timer_shutdown(struct clock_event_device *evt)
 {
omap_32k_timer_stop();
+   return 0;
+}
 
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   omap_32k_timer_start(OMAP_32K_TIMER_TICK_PERIOD);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   break;
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+static int omap_32k_timer_set_periodic(struct clock_event_device *evt)
+{
+   omap_32k_timer_stop();
+   omap_32k_timer_start(OMAP_32K_TIMER_TICK_PERIOD);
+   return 0;
 }
 
 static struct clock_event_device clockevent_32k_timer = {
-   .name   = 32k-timer,
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .set_next_event = omap_32k_timer_set_next_event,
-   .set_mode   = omap_32k_timer_set_mode,
+   .name   = 32k-timer,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_next_event = omap_32k_timer_set_next_event,
+   .set_state_shutdown = omap_32k_timer_shutdown,
+   .set_state_periodic = omap_32k_timer_set_periodic,
+   .set_state_oneshot  = omap_32k_timer_shutdown,
+   .tick_resume= omap_32k_timer_shutdown,
 };
 
 static irqreturn_t omap_32k_timer_interrupt(int irq, void *dev_id)
-- 
2.4.0

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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-17 Thread Viresh Kumar 
On 17 December 2014 at 20:58, Nishanth Menon n...@ti.com wrote:
 I still do not see the need to crash the entire system - OK, fine
 cpufreq is broke, but the remaining part of the system can easily
 function. That BUG does look like a ugly point and lack of proper
 cleanup logic - cpufreq should be expected to report and gracefully
 shut itself down, not screw up my platform boot.

http://lists.linaro.org/pipermail/linaro-kernel/2013-November/009128.html

We came to this conclusion because you insisted that its not safe
for the system to continue on a unsupported frequency from kernel's
freq table. It may run well, but we don't know what will happen in
longer run..

And surely it deserves a bug-on then.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-17 Thread Viresh Kumar 
On 17 December 2014 at 22:13, Nishanth Menon n...@ti.com wrote:
 I do realize that i did have different opinion given bootloader screw
 ups. Given that we have discovered a potentially bad configuration (in
 this case for some reason almost ALL TI platforms have bad
 configuration - could be due to recent clock code changes or what
 ever), just killing boot does not make sense to me as purely
 bootloader being the cause may not always be the case for that path to
 go wrong.

Sorry, I still *disagree*.

Its not about bootloaders getting screwed up.. Yes, bootloader was indeed
running at a frequency not listed in kernel. But we *tried* our best to get
that resolved and we failed to change frequency.

We *shouldn't* allow kernel to move a inch further. It might be dangerous
for the platform to continue further as we are talking about the almighty
CPU. So, the bug is still the right way forward, atleast for me.

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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-17 Thread Viresh Kumar 
On 17 December 2014 at 22:46, Kevin Hilman khil...@kernel.org wrote:
 So this looks like a bug that has been hiding, but just exposed
 because cpufreq-cpu0 (now cpufreq-dt) was not getting built-in since
 before v3.18.

 On omap4-panda-es, v3.18 with multi_v7_defconfig + CPUFREQ_DT enabled,
 I see this:

 [2.062103] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted
 freq: 699977 KHz
 [2.070404] cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial
 frequency changed to: 70 KHz

 No BUG.  But, in next-20141216,

 [2.083953] cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted
 freq: 699977 KHz
 [2.091949] cpu cpu0: failed to set clock rate: -22
 [2.097045] cpufreq: __target_index: Failed to change cpu frequency: -22

 And then the BUG.

 So the BUG() itself isn't the problem with this regression.  There's
 been a fair amount of changes in the OMAP clk driver (including some
 other regressions), so I suspect the culprit to be lying somewhere in
 the recent OMAP clock changes.

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

Re: Fwd: next boot: 101 boots: 89 pass, 12 fail (next-20141216)

2014-12-16 Thread Viresh Kumar 
On 17 December 2014 at 02:33, Nishanth Menon n...@ti.com wrote:
 http://storage.armcloud.us/kernel-ci/next/next-20141216/arm-multi_v7_defconfig/lab-khilman/boot-omap5-uevm.html
 [2.071996] [ cut here ]
 [2.076831] kernel BUG at ../drivers/cpufreq/cpufreq.c:1258!
 [2.082753] Internal error: Oops - BUG: 0 [#1] SMP ARM

This is what we have hit:

if ((cpufreq_driver-flags  CPUFREQ_NEED_INITIAL_FREQ_CHECK)
 has_target()) {
/* Are we running at unknown frequency ? */
ret = cpufreq_frequency_table_get_index(policy, policy-cur);
if (ret == -EINVAL) {
/* Warn user and fix it */
pr_warn(%s: CPU%d: Running at unlisted freq: %u KHz\n,
__func__, policy-cpu, policy-cur);
ret = __cpufreq_driver_target(policy, policy-cur - 1,
CPUFREQ_RELATION_L);

/*
 * Reaching here after boot in a few seconds may not
 * mean that system will remain stable at unknown
 * frequency for longer duration. Hence, a BUG_ON().
 */
BUG_ON(ret);/* We have hit
this one ***/
pr_warn(%s: CPU%d: Unlisted initial frequency
changed to: %u KHz\n,
__func__, policy-cpu, policy-cur);
}
}


So the SoC was running on unlisted frequency and when we tried to
change to some other valid (listed) frequency, we failed.

The comment over it describes why it is a BUG.. Its some SoC issue
and need to be resolved by somebody with a board.

So, in short __cpufreq_driver_target() failed to change freq..
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT

2014-12-14 Thread Viresh Kumar 
On Fri, Dec 12, 2014 at 10:48 PM, Nishanth Menon n...@ti.com wrote:
 CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
 (cpufreq: cpu0: rename driver and internals to 'cpufreq_dt')

 Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with
 v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via
 different trees causing the resultant v3.18-rc1 to be non-functional for
 cpufreq as default supported with omap2plus_defconfig.

 Fixes: fdc509b15eb3eb (ARM: omap2plus_defconfig: Add cpufreq to defconfig)
 Signed-off-by: Nishanth Menon n...@ti.com

Whomsoever applies it, please add:

Cc: sta...@vger.kernel.org# 3.18

 ---

 NOTE: as of v3.18 tag, The following still need to be fixed - I do not have 
 all
 the platforms impacted to make a generic change, so CCying folks who might be 
 interested

 arch/arm/configs/shmobile_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y
 arch/arm/configs/multi_v7_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y

I have fixed them now.


  arch/arm/configs/omap2plus_defconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 3e09286..5fc0dbe 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -68,7 +68,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
  CONFIG_CPU_FREQ_GOV_POWERSAVE=y
  CONFIG_CPU_FREQ_GOV_USERSPACE=y
  CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
 -CONFIG_GENERIC_CPUFREQ_CPU0=y
 +CONFIG_CPUFREQ_DT=y
  # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
  CONFIG_CPU_IDLE=y
  CONFIG_BINFMT_MISC=y

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIX ME in omap-cpufreq.c

2014-12-04 Thread Viresh Kumar 
On 4 December 2014 at 23:13, nick xerofo...@gmail.com wrote:
 Greetings Kevin and the other maintainers of this file,

Hi,

 I am wondering why the below code still has a fix me? It seems rather trivial 
 to fix, as all we need is the transition
 time of the CPU. Due to this and I don't have the hardware do any of you have 
 the hardware, can any of you tell me the
 correct value for this if you have this hardware. Further more I will paste 
 the code below.

Not every FIXME wants to get fixed. Believe me.

Don't just grep for FIXME's in kernel and send patches for that. It
isn't working anymore Nick.

I understand that you want to get some name for yourself in the kernel community
(and for sure there is nothing wrong in that), but the way you have chosen isn't
taking you there. People aren't really happy with the way things are proceeding.

If you really want to help kernel (and yourself), start getting deeper
knowledge of
frameworks you have any idea of. And they try to solve some real problems.

I don't want to discourage you here, but trying to show the right path. Rest is
upon you :)

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

Re: [PATCH 07/14] cpufreq: cpu0: OPPs can be populated at runtime

2014-07-10 Thread Viresh Kumar 
On 10 July 2014 19:01, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 Yep. Last time I blocked the series because all the DT conversions
 were not done. Considering now the cpufreq-generic can work on non
 DT platforms, I am ok to remove the omap-cpufreq.

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

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP

2014-06-08 Thread Viresh Kumar 
On Fri, Jun 6, 2014 at 4:06 PM, Mark Brown broo...@kernel.org wrote:
 From: Mark Brown broo...@linaro.org

 Since the OPP layer is a kernel library which has been converted to be
 directly selectable by its callers rather than user selectable and
 requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
 has become redundant and can be removed. Do so.

 Signed-off-by: Mark Brown broo...@linaro.org
 ---
  Documentation/power/opp.txt| 3 ---
  arch/arm/mach-exynos/Kconfig   | 1 -
  arch/arm/mach-highbank/Kconfig | 1 -
  arch/arm/mach-imx/Kconfig  | 1 -
  arch/arm/mach-omap2/Kconfig| 1 -
  arch/arm/mach-shmobile/Kconfig | 2 --
  arch/arm/mach-vexpress/Kconfig | 1 -
  arch/arm/mach-zynq/Kconfig | 1 -
  drivers/devfreq/Kconfig| 1 -
  kernel/power/Kconfig   | 3 ---
  10 files changed, 15 deletions(-)

Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

2014-05-05 Thread Viresh Kumar 
On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
 diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
  int dev_pm_opp_init_cpufreq_table(struct device *dev,
 struct cpufreq_frequency_table **table)
  {
 -   struct device_opp *dev_opp;
 struct dev_pm_opp *opp;
 -   struct cpufreq_frequency_table *freq_table;
 -   int i = 0;
 +   struct cpufreq_frequency_table *freq_table = NULL;
 +   int i, max_opps, ret = 0;
 +   unsigned long rate;

 -   /* Pretend as if I am an updater */
 -   mutex_lock(dev_opp_list_lock);

What if opp is being added for some reason at the same time?
I hope we can surely see some awkward results, maybe some
NULL pointers invocations as well..
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] PM / OPP: Move cpufreq specific OPP functions out of generic OPP library

2014-05-05 Thread Viresh Kumar 
On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
 CPUFreq specific helper functions for OPP (Operating Performance Points)
 now use generic OPP functions that allow CPUFreq to be be moved back
 into CPUFreq framework. This allows for independent modifications
 or future enhancements as needed isolated to just CPUFreq framework
 alone.

 Here, we just move relevant code and documentation to make this part of
 CPUFreq infrastructure.

 Cc: Rafael J. Wysocki r...@rjwysocki.net
 Cc: Viresh Kumar viresh.ku...@linaro.org
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: cpuf...@vger.kernel.org
 Cc: linux-samsung-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization

2014-05-05 Thread Viresh Kumar 
On 5 May 2014 19:55, Nishanth Menon n...@ti.com wrote:
 On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote:


 What if opp is being added for some reason at the same time?
 I hope we can surely see some awkward results, maybe some
 NULL pointers invocations as well..

 we wont - rcu operations ensure that.

Stupid !!

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] PM / OPP: move cpufreq specific OPP functions out of generic OPP library

2014-05-01 Thread Viresh Kumar 
On 2 May 2014 06:36, Nishanth Menon n...@ti.com wrote:
 diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
 index 1fbe11f..281ccfb 100644
 --- a/drivers/cpufreq/Kconfig
 +++ b/drivers/cpufreq/Kconfig
 @@ -17,6 +17,11 @@ config CPU_FREQ

  if CPU_FREQ

 +config CPU_FREQ_PM_OPP
 +   bool
 +   depends on PM_OPP
 +   default y
 +

Don't need this

  config CPU_FREQ_GOV_COMMON
 bool

 diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
 index 0dbb963..16eea68 100644
 --- a/drivers/cpufreq/Makefile
 +++ b/drivers/cpufreq/Makefile
 @@ -1,5 +1,7 @@
  # CPUfreq core
  obj-$(CONFIG_CPU_FREQ) += cpufreq.o freq_table.o
 +obj-$(CONFIG_CPU_FREQ_PM_OPP)  += cpufreq_opp.o

Just use: obj-$(CONFIG_PM_OPP)

 +
  # CPUfreq stats
  obj-$(CONFIG_CPU_FREQ_STAT) += cpufreq_stats.o


 diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
 new file mode 100644
 index 000..2602ff8
 --- /dev/null
 +++ b/drivers/cpufreq/cpufreq_opp.c
 @@ -0,0 +1,102 @@
 +/*
 + * Generic OPP Interface for CPUFREQ drivers
 + *
 + * Copyright (C) 2009-2014 Texas Instruments Incorporated.
 + * Nishanth Menon
 + * Romit Dasgupta
 + * Kevin Hilman
 + *
 + * 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.
 + */

I hope you have just copy pasted routines to this file, and haven't done
even the most minor modification in those, as its hard to review it.

 +#include linux/slab.h

Sure? That's it, nothing else required to compile this file independently?
As a rule include all the files directly which might be required for compilation
of this file and don't expect them to be included by some other header
files indirectly.

 diff --git a/drivers/cpufreq/cpufreq_opp.h b/drivers/cpufreq/cpufreq_opp.h

Two problems, driver may lie in arch/ as well, though we don't recommend
them, secondly move these in cpufreq.h, don't need a header here for sure.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] PM / OPP: move cpufreq specific OPP functions out of generic OPP library

2014-05-01 Thread Viresh Kumar 
On 2 May 2014 10:48, Nishanth Menon n...@ti.com wrote:
 On Thu, May 1, 2014 at 11:30 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
 diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
 new file mode 100644
 index 000..2602ff8
 --- /dev/null
 +++ b/drivers/cpufreq/cpufreq_opp.c
 @@ -0,0 +1,102 @@
 +/*
 + * Generic OPP Interface for CPUFREQ drivers
 + *
 + * Copyright (C) 2009-2014 Texas Instruments Incorporated.
 + * Nishanth Menon
 + * Romit Dasgupta
 + * Kevin Hilman
 + *
 + * 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.
 + */

 I hope you have just copy pasted routines to this file, and haven't done
 even the most minor modification in those, as its hard to review it.

 there is code replacement ofcourse -
 * the logic of walking down the list holding a mutex has been replaced
 with rcu locks,
 * instead of reading internal data structure and generating the list,
 use the existing search API that does exactly the same.
 * Documentation update for the same.

Hmm, actually if I would have written this patch, then probably I would
have done the same thing, but looking from the reviewers perspective,
it would be much more easy if we can separate things into patches.

So, maybe do these changes first in opp.c only and then finally a
patch that just moves things around.

 Both are needed if you have to move the code out. functionally, both
 are equivalent

That's an assumption and we never know when we might have screwed
the code :) .. And so more careful review of those parts is required :)

 diff --git a/drivers/cpufreq/cpufreq_opp.h b/drivers/cpufreq/cpufreq_opp.h

 Two problems, driver may lie in arch/ as well, though we don't recommend
 them, secondly move these in cpufreq.h, don't need a header here for sure.

 There are none at the moment. ideally, we'd like to discourage folks

Yes, we do. :)

 putting cpufreq drivers in arch/ given the amount of effort you have
 undertaken in bringing them all here. but I have personally no strong
 objection to getting rid of the private header and using the generic
 cpufreq header.

 Otherwise, I assume you are ok with this approach and will post a
 formal patch by monday.

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

Re: [PATCH V7 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

2013-12-23 Thread Viresh Kumar 
On Wed, Oct 16, 2013 at 9:09 PM, Nishanth Menon n...@ti.com wrote:
 PandaBoard-ES (OMAP4460): http://pastebin.com/qQCmA2ng

Hi Nishanth,

A colleague of mine (Sanjay), was trying mainline on panda board. And
wasn't able to get cpufreq-cpu0 working with it. Even your log also
reports its broken as it can't get any regulator information..

He is getting this:

cpufreq_cpu0: failed to get cpu0 regulator: -19
cpufreq_cpu0: failed to get cpu0 clock: -2
cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2

Can you please help him out?

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

Re: [PATCH] cpufreq: omap: clk_round_rate() can return a zero upon error

2013-12-16 Thread Viresh Kumar 
On 10 December 2013 07:48, Paul Walmsley pwalms...@nvidia.com wrote:
 Treat both negative and zero return values from clk_round_rate() as errors.
 This is needed since subsequent patches will convert clk_round_rate()'s
 return value to be an unsigned type, rather than a signed type, since some
 clock sources can generate rates higher than (2^31)-1 Hz.

 Eventually, when calling clk_round_rate(), only a return value of
 zero will be considered a error.  All other values will be
 considered valid rates.  The comparison against values less than
 0 is kept to preserve the correct behavior in the meantime.

 This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended
 to be used only on combination pointer/error code return values; a
 side-benefit.

 Signed-off-by: Paul Walmsley pwalms...@nvidia.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Viresh Kumar viresh.ku...@linaro.org

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*

2013-09-20 Thread Viresh Kumar 
On 20 September 2013 02:33, Nishanth Menon n...@ti.com wrote:
 opp_get_opp_count
 opp_find_freq_exact
 opp_init_cpufreq_table
 opp_free_cpufreq_table

The only problem I see is that routines names for few of them are getting
really long now.. Otherwise not much I could find...

Though you had following changes, which you could have avoided in this
hard to review patchset:

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
new_opp = [-kzalloc(sizeof(struct
opp),-]{+kzalloc(sizeof(*new_opp),+} GFP_KERNEL);
new_opp = [-kmalloc(sizeof(struct
opp),-]{+kmalloc(sizeof(*new_opp),+} GFP_KERNEL);

It is almost impossible to catch these with naked eyes for such long
patches.. I took help of --word-diff though :)

If no one else sees these as problems then feel free to add my:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*

2013-09-20 Thread Viresh Kumar 
On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote:

 I am open to suggestions if any one feels we can improve this better.

I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp**
though..

 I believe that change was from Patch #2[1]

Yeah.. I just replied on a single patch :)

 yes, you are right, I had squashed this patch in to squelch checkpatch
 warnings:

I see..

 I had added a comment:
  Minor checkpatch warning fixes as a result of this change was fixed as
 well.

I really missed that..

 Would you suggest I split the change off to a separate patch or improve
  the comment a little more?

don't really know, maybe leave those as is and let checkpatch warn you..
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+

2013-08-29 Thread Viresh Kumar 
On Fri, Sep 23, 2011 at 2:37 AM, Kevin Hilman khil...@ti.com wrote:
 From: Russell King rmk+ker...@arm.linux.org.uk

 On OMAP SMP configuartion, both processors share the voltage
 and clock. So both CPUs needs to be scaled together and hence
 needs software co-ordination.

 Also, update lpj with reference value to avoid progressive error.

 Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate
 them with with reference to the initial values to avoid a
 progressively bigger and bigger error in the value over time.

 While at this, re-use the notifiers for UP/SMP since on UP machine or
 UP_ON_SMP policy-cpus mask would contain only the boot CPU.

 Based on initial SMP support by Santosh Shilimkar.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 [khil...@ti.com: due to overlap/rework, combined original Santosh patch
  and Russell's rework]
 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  drivers/cpufreq/omap-cpufreq.c |   80 
 +++-
  1 files changed, 70 insertions(+), 10 deletions(-)

 diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c

 +   /*
 +* On OMAP SMP configuartion, both processors share the voltage
 +* and clock. So both CPUs needs to be scaled together and hence
 +* needs software co-ordination. Use cpufreq affected_cpus
 +* interface to handle this scenario. Additional is_smp() check
 +* is to keep SMP_ON_UP build working.
 +*/
 +   if (is_smp()) {
 +   policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
 +   cpumask_or(cpumask, cpumask_of(policy-cpu), cpumask);
 +   cpumask_copy(policy-cpus, cpumask);
 +   }

Does somebody remember importance of is_smp() here??

Current code looks like:

if (is_smp())
cpumask_setall(policy-cpus);

And I was looking to remove this check if it is no more useful.. And
so simply do

cpumask_setall(policy-cpus);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+

2013-08-29 Thread Viresh Kumar 
On 29 August 2013 19:07, Santosh Shilimkar santosh.shilim...@ti.com wrote:
 On Thursday 29 August 2013 06:02 AM, Viresh Kumar wrote:

 cpumask_setall(policy-cpus);

 Thats should work I guess. Infact I changed this i downstream kernel
 a while back but forgot to send a patch. Just see if for some reason
 above can break UP machine since this driver is used on UP machines
 as well. Other than that, it should be fine

Atleast I can't see why it will break on UP machines as that should set
masks to individual CPUs then...

Okay I will fix that in my longest patchset ever... 230+ patches already :)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] cpufreq: OMAP: Add SMP support for OMAP4+

2013-08-29 Thread Viresh Kumar 
On 30 August 2013 11:13, Viresh Kumar viresh.ku...@linaro.org wrote:

 On 29 August 2013 19:12, Santosh Shilimkar santosh.shilim...@ti.com wrote:
  On Thursday 29 August 2013 09:39 AM, Viresh Kumar wrote:
  On 29 August 2013 19:07, Santosh Shilimkar santosh.shilim...@ti.com 
  wrote:
  On Thursday 29 August 2013 06:02 AM, Viresh Kumar wrote:
 
  cpumask_setall(policy-cpus);
 
  Thats should work I guess. Infact I changed this i downstream kernel
  a while back but forgot to send a patch. Just see if for some reason
  above can break UP machine since this driver is used on UP machines
  as well. Other than that, it should be fine
 
  Atleast I can't see why it will break on UP machines as that should set
  masks to individual CPUs then...
 
  Okay I will fix that in my longest patchset ever... 230+ patches already :)
 
  WoW !!
  Looks like you re-wrote most of the CPUFREQ drivers ;-)

 I am trying hard to get rid of redundancy of code wherever possible .. :)

 I am pasting my patch here for now (don't want to post
 this separately) as most of the concerned people are following this chain..

 I will include it in my patchset and will post it on lists with them (After
 your Ack, which you will give now :) )

 x-x--

OMG, Gmail fucked up completely... What to do now :)

Earlier (few days back):
- We could have selected the plain text mode while sending emails, where
emails are corrupted a bit and so patches couldn't be applied.
- BUT they are atleast readable as it wasn't fucked up so badly..

But today I noticed that gmail has completely removed tabs from mails
(Atleast while pasting code). And so all tabs used for alignments in mail are
gone.. And so aren't even readable anymore..

Deselecting plain text mode, sends it in HTML and that's fucked up too..
Mails gets bounced from our lists (and even then gmail has eaten up
the tabs from code)...

For now see the attached patch, I will send it using git later..

Btw, this is the link to master patch that you may need during reviews..
https://lkml.org/lkml/2013/8/21/485

 From: Viresh Kumar viresh.ku...@linaro.org
 Date: Wed, 21 Aug 2013 19:05:05 +0530
 Subject: [PATCH] cpufreq: omap: use cpufreq_generic_init() routine

 Use generic cpufreq_generic_init() routine instead of replicating the same 
 code
 here.

 This also rearranges the code a bit to make it more sensible. Also removes 
 some
 unnecessary checks.

 Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
 ---
  drivers/cpufreq/omap-cpufreq.c | 41 +++--
  1 file changed, 11 insertions(+), 30 deletions(-)

 diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
 index 09150fc..a94c4ef 100644
 --- a/drivers/cpufreq/omap-cpufreq.c
 +++ b/drivers/cpufreq/omap-cpufreq.c
 @@ -112,50 +112,31 @@ static inline void freq_table_free(void)

  static int omap_cpu_init(struct cpufreq_policy *policy)
  {
 - int result = 0;
 + int result;

   policy-clk = clk_get(NULL, cpufreq_ck);
   if (IS_ERR(policy-clk))
   return PTR_ERR(policy-clk);

 - if (policy-cpu = NR_CPUS) {
 - result = -EINVAL;
 - goto fail_ck;
 - }
 -
 - if (!freq_table)
 + if (!freq_table) {
   result = opp_init_cpufreq_table(mpu_dev, freq_table);
 -
 - if (result) {
 - dev_err(mpu_dev, %s: cpu%d: failed creating freq table[%d]\n,
 + if (result) {
 + dev_err(mpu_dev,
 + %s: cpu%d: failed creating freq table[%d]\n,
   __func__, policy-cpu, result);
 - goto fail_ck;
 + goto fail;
 + }
   }

   atomic_inc_return(freq_table_users);

 - result = cpufreq_table_validate_and_show(policy, freq_table);
 - if (result)
 - goto fail_table;
 -
 - /*
 - * On OMAP SMP configuartion, both processors share the voltage
 - * and clock. So both CPUs needs to be scaled together and hence
 - * needs software co-ordination. Use cpufreq affected_cpus
 - * interface to handle this scenario. Additional is_smp() check
 - * is to keep SMP_ON_UP build working.
 - */
 - if (is_smp())
 - cpumask_setall(policy-cpus);
 -
   /* FIXME: what's the actual transition time? */
 - policy-cpuinfo.transition_latency = 300 * 1000;
 -
 - return 0;
 + result = cpufreq_generic_init(policy, freq_table, 300 * 1000);
 + if (!result)
 + return 0;

 -fail_table:
   freq_table_free();
 -fail_ck:
 +fail:
   clk_put(policy-clk);
   return result;
  }



0001-cpufreq-omap-use-cpufreq_generic_init-routine.patch
Description: Binary data

Re: [PATCH 02/19] drivers/usb/host: add missing platform_driver owner

2013-05-20 Thread Viresh Kumar 
On Tue, May 21, 2013 at 8:12 AM, Libo Chen libo.c...@huawei.com wrote:
 set the owner of platform_driver, to ensure that the
 caller of driver holds a module refernece

 Signed-off-by: Libo Chen libo.c...@huawei.com
 ---
  drivers/usb/host/ehci-spear.c   |1 +

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

2013-03-28 Thread Viresh Kumar 
On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon n...@ti.com wrote:
 As multi-platform build is being adopted by more and more ARM platforms,
 initcall function should be used very carefully.  For example, when
 CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
 will be called on all the platforms to initialize omap-cpufreq driver.

 Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
 tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
 for OMAP in a single image, we need to ensure the following:
 1. With device tree boot, we use cpufreq-cpu0
 2. With non device tree boot, we use omap-cpufreq

 In the case of (1), we will have cpu OPPs and regulator registered
 as part of the device tree nodes, to ensure that omap-cpufreq
 and cpufreq-cpu0 don't conflict in managing the frequency of the
 same CPU, we should not permit omap-cpufreq to be probed.

 In the case of (2), we will not have the cpufreq-cpu0 device, hence
 only omap-cpufreq will be active.

 To eliminate this undesired these effects, we change omap-cpufreq
 driver to have it instantiated as a platform_driver and register
 omap-cpufreq device only when booted without device tree nodes on
 OMAP platforms.

 This allows the following:
 a) Will only run on platforms that create the platform_device
omap-cpufreq.
 b) Since the platform_device is registered only when device tree nodes
are *not* populated, omap-cpufreq driver does not conflict with
the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
device tree nodes are present.

 Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
 (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

 Cc: Kevin Hilman khil...@linaro.org
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoît Cousson b-cous...@ti.com
 Cc: Jon Hunter jon-hun...@ti.com
 Cc: Keerthy j-keer...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Shawn Guo shawn@linaro.org
 [robherri...@gmail.com: reported conflict of omap-cpufreq vs other
 driver in an non-device tree supported boot]
 Reported-by: Rob Herring robherri...@gmail.com
 Signed-off-by: Nishanth Menon n...@ti.com
 ---
 Changes in V3:
 - converted to platform_driver to
 address https://patchwork.kernel.org/patch/2303491/ as well
 - modified CC list.
 V2: https://patchwork.kernel.org/patch/2303491/
 V1: https://patchwork.kernel.org/patch/2273681/

  arch/arm/mach-omap2/pm.c   |9 +
  drivers/cpufreq/omap-cpufreq.c |   19 ++-
  2 files changed, 23 insertions(+), 5 deletions(-)

For cpufreq core:

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members

2013-03-25 Thread Viresh Kumar 
On 25 March 2013 14:06, Sekhar Nori nsek...@ti.com wrote:
 There is a line in the code a little above the ones you deleted that
 also sets these same variables. I guess you were relying on that line to
 set policy-cur, but that also sets policy-{min, max} which can be
 cleaned up.

This code is rather confusing or wrong, this was the state of code before
this patch:

policy-cur = policy-min = policy-max = davinci_getspeed(0);

if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!result)
cpufreq_frequency_table_get_attr(freq_table,
policy-cpu);
} else {
policy-cpuinfo.min_freq = policy-min;
policy-cpuinfo.max_freq = policy-max;
}

policy-min = policy-cpuinfo.min_freq;
policy-max = policy-cpuinfo.max_freq;
policy-cur = davinci_getspeed(0);


The tricky part is if/else, where if don't return error if
cpufreq_frequency_table_cpuinfo() fails. We want to set -min[max]
and cpuinfo.min[max] always. And i can see this code not doing that for some
case even with my patch.

Possible scenarios:
1. Valid freq_table: My patch + what you suggested is required.
2. Invalid freq_table: We never set cpuinfo.min[max] with or without my patch
3. No freq_table: Only my patch is required.

If i do what you suggested then 2 and 3 would fail... If you want to
return error
in case cpufreq_frequency_table_cpuinfo(), then i can fix it properly.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members

2013-03-25 Thread Viresh Kumar 
On 25 March 2013 15:11, Sekhar Nori nsek...@ti.com wrote:
 So down in the cpufreq driver probe below, we bail out if freq_table is
 not provided. So all this checking for freq_table in the code you pasted
 above is superfluous. If you can clean that part up and add checking for
 cpufreq_frequency_table_cpuinfo() as you proposed, I will be glad to
 test it out ;)

Attached is the complete patch and following is your fixup for davinci
(just to review):

diff --git a/arch/arm/mach-davinci/cpufreq.c b/arch/arm/mach-davinci/cpufreq.c
index ff46862..7c2e943 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/arch/arm/mach-davinci/cpufreq.c
@@ -137,18 +137,17 @@ static int davinci_cpu_init(struct cpufreq_policy *policy)
return result;
}

-   policy-cur = policy-min = policy-max = davinci_getspeed(0);
-
-   if (freq_table) {
-   result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
-   if (!result)
-   cpufreq_frequency_table_get_attr(freq_table,
-   policy-cpu);
-   } else {
-   policy-cpuinfo.min_freq = policy-min;
-   policy-cpuinfo.max_freq = policy-max;
+   policy-cur = davinci_getspeed(0);
+
+   result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+   if (result) {
+   pr_err(%s: cpufreq_frequency_table_cpuinfo() failed,
+   __func__);
+   return result;
}

+   cpufreq_frequency_table_get_attr(freq_table, policy-cpu);
+
/*
 * Time measurement across the target() function yields ~1500-1800us
 * time taken with no drivers on notification list.


0001-cpufreq-drivers-Remove-unnecessary-assignments-of-po.patch
Description: Binary data

[PATCH 2/2] cpufreq: drivers: Remove unnecessary assignments of policy- members

2013-03-24 Thread Viresh Kumar 
Some assignments of policy- min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq
aren't required as part of it is done by cpufreq driver or cpufreq core.

Remove them.

At some places we merge multiple lines together too.

Cc: Sekhar Nori nsek...@ti.com
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 Documentation/cpu-freq/cpu-drivers.txt | 5 +++--
 arch/arm/mach-davinci/cpufreq.c| 4 
 arch/arm/mach-imx/cpufreq.c| 3 ---
 arch/sh/kernel/cpufreq.c   | 9 +++--
 drivers/cpufreq/cpufreq-nforce2.c  | 6 ++
 drivers/cpufreq/omap-cpufreq.c | 4 +---
 6 files changed, 9 insertions(+), 22 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 72f70b1..c94383f 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -108,8 +108,9 @@ policy-governormust contain the default 
policy for
cpufreq_driver.target is called with
these values.
 
-For setting some of these values, the frequency table helpers might be
-helpful. See the section 2 for more information on them.
+For setting some of these values (cpuinfo.min[max]_freq, policy-min[max]), the
+frequency table helpers might be helpful. See the section 2 for more 
information
+on them.
 
 SMP systems normally have same clock source for a group of cpus. For these the
 .init() would be called only once for the first online cpu. Here the .init()
diff --git a/arch/arm/mach-davinci/cpufreq.c b/arch/arm/mach-davinci/cpufreq.c
index 8fb0c2a..ff46862 100644
--- a/arch/arm/mach-davinci/cpufreq.c
+++ b/arch/arm/mach-davinci/cpufreq.c
@@ -149,10 +149,6 @@ static int davinci_cpu_init(struct cpufreq_policy *policy)
policy-cpuinfo.max_freq = policy-max;
}
 
-   policy-min = policy-cpuinfo.min_freq;
-   policy-max = policy-cpuinfo.max_freq;
-   policy-cur = davinci_getspeed(0);
-
/*
 * Time measurement across the target() function yields ~1500-1800us
 * time taken with no drivers on notification list.
diff --git a/arch/arm/mach-imx/cpufreq.c b/arch/arm/mach-imx/cpufreq.c
index cfce5e3..387dc4c 100644
--- a/arch/arm/mach-imx/cpufreq.c
+++ b/arch/arm/mach-imx/cpufreq.c
@@ -144,14 +144,11 @@ static int mxc_cpufreq_init(struct cpufreq_policy *policy)
imx_freq_table[i].frequency = CPUFREQ_TABLE_END;
 
policy-cur = clk_get_rate(cpu_clk) / 1000;
-   policy-min = policy-cpuinfo.min_freq = cpu_freq_khz_min;
-   policy-max = policy-cpuinfo.max_freq = cpu_freq_khz_max;
 
/* Manual states, that PLL stabilizes in two CLK32 periods */
policy-cpuinfo.transition_latency = 2 * NANOSECOND / CLK32_FREQ;
 
ret = cpufreq_frequency_table_cpuinfo(policy, imx_freq_table);
-
if (ret  0) {
printk(KERN_ERR %s: failed to register i.MXC CPUfreq with 
error code %d\n,
   __func__, ret);
diff --git a/arch/sh/kernel/cpufreq.c b/arch/sh/kernel/cpufreq.c
index 0fdf64b..88c8fee 100644
--- a/arch/sh/kernel/cpufreq.c
+++ b/arch/sh/kernel/cpufreq.c
@@ -116,7 +116,7 @@ static int sh_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
return PTR_ERR(cpuclk);
}
 
-   policy-cur = policy-min = policy-max = sh_cpufreq_get(cpu);
+   policy-cur = sh_cpufreq_get(cpu);
 
freq_table = cpuclk-nr_freqs ? cpuclk-freq_table : NULL;
if (freq_table) {
@@ -129,15 +129,12 @@ static int sh_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
dev_notice(dev, no frequency table found, falling back 
   to rate rounding.\n);
 
-   policy-cpuinfo.min_freq =
+   policy-min = policy-cpuinfo.min_freq =
(clk_round_rate(cpuclk, 1) + 500) / 1000;
-   policy-cpuinfo.max_freq =
+   policy-max = policy-cpuinfo.max_freq =
(clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
}
 
-   policy-min = policy-cpuinfo.min_freq;
-   policy-max = policy-cpuinfo.max_freq;
-
policy-cpuinfo.transition_latency = CPUFREQ_ETERNAL;
 
dev_info(dev, CPU Frequencies - Minimum %u.%03u MHz, 
diff --git a/drivers/cpufreq/cpufreq-nforce2.c 
b/drivers/cpufreq/cpufreq-nforce2.c
index 224a478..af1542d 100644
--- a/drivers/cpufreq/cpufreq-nforce2.c
+++ b/drivers/cpufreq/cpufreq-nforce2.c
@@ -359,12 +359,10 @@ static int nforce2_cpu_init(struct cpufreq_policy *policy)
min_fsb = NFORCE2_MIN_FSB;
 
/* cpuinfo and default policy values */
-   policy-cpuinfo.min_freq = min_fsb * fid * 100;
-   policy-cpuinfo.max_freq = max_fsb * fid * 100;
+   policy-min = policy-cpuinfo.min_freq = min_fsb * fid * 100;
+   policy-max = policy

Re: [PATCH 8/8] cpufreq: omap: remove omap-cpufreq

2013-03-14 Thread Viresh Kumar 
On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote:
 We can now use cpufreq-cpu0 driver using DT entries.
 remove the redundant omap-cpufreq driver from the tree.
 Remove MAINTAINERS file entry for the same as well.

 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Benoît Cousson b-cous...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Shawn Guo shawn@linaro.org
 Cc: Keerthy j-keer...@ti.com
 Cc: linux-omap@vger.kernel.org
 Cc: devicetree-disc...@lists.ozlabs.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: cpuf...@vger.kernel.org
 Cc: linux...@vger.kernel.org

 Signed-off-by: Nishanth Menon n...@ti.com
 ---
  MAINTAINERS|1 -
  drivers/cpufreq/Kconfig.arm|6 -
  drivers/cpufreq/Makefile   |1 -
  drivers/cpufreq/omap-cpufreq.c |  291 
 
  4 files changed, 299 deletions(-)
  delete mode 100644 drivers/cpufreq/omap-cpufreq.c

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 077/493] mmc: remove use of __devexit_p

2012-11-19 Thread viresh kumar 
On Mon, Nov 19, 2012 at 11:50 PM, Bill Pemberton wf...@virginia.edu wrote:
 CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
 needed.

 Signed-off-by: Bill Pemberton wf...@virginia.edu
 Cc: Chris Ball c...@laptop.org
 Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
 Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
 Cc: Venkatraman S svenk...@ti.com
 Cc: Viresh Kumar viresh.li...@gmail.com
 Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Cc: Ian Molton i...@mnementh.co.uk
 Cc: Bruce Chang brucech...@via.com.tw
 Cc: Harald Welte haraldwe...@viatech.com
 Cc: Pierre Ossman pie...@ossman.eu
 Cc: uclinux-dist-de...@blackfin.uclinux.org
 Cc: linux-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: spear-de...@list.st.com
 ---
  drivers/mmc/host/sdhci-spear.c | 2 +-

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 237/493] mmc: remove use of __devinit

2012-11-19 Thread viresh kumar 
On Mon, Nov 19, 2012 at 11:53 PM, Bill Pemberton wf...@virginia.edu wrote:
 CONFIG_HOTPLUG is going away as an option so __devinit is no longer
 needed.

 Signed-off-by: Bill Pemberton wf...@virginia.edu
 Cc: Ludovic Desroches ludovic.desroc...@atmel.com
 Cc: Chris Ball c...@laptop.org
 Cc: Manuel Lauss manuel.la...@gmail.com
 Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
 Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
 Cc: Venkatraman S svenk...@ti.com
 Cc: Viresh Kumar viresh.li...@gmail.com
 Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
 Cc: Ian Molton i...@mnementh.co.uk
 Cc: Bruce Chang brucech...@via.com.tw
 Cc: Harald Welte haraldwe...@viatech.com
 Cc: Pierre Ossman pie...@ossman.eu
 Cc: linux-...@vger.kernel.org
 Cc: uclinux-dist-de...@blackfin.uclinux.org
 Cc: linux-omap@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: spear-de...@list.st.com
 ---
  drivers/mmc/host/sdhci-spear.c |  8 +++-

Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP: Compilation error: omapzoom kernel tree

2012-09-04 Thread Viresh Kumar 
Hello,

Which branch should i use from TI[1] tree? I need to boot linux
with linaro-nano.

I tried: p-linux-omap-3.4 branch but i am getting compilation error for
omap4plus_pm_min_defconfig and omap2plus_defconfig:

/home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S:
Assembler messages:
/home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S:260:
Error: selected processor does not support ARM mode `smc #0'
/home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S:260:
Error: selected processor does not support ARM mode `smc #0'
make[2]: *** [arch/arm/mm/proc-v7.o] Error 1

Can somebody help?

--
viresh

[1] http://omapzoom.org/?p=kernel/omap.git;a=summary
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/31] ARM: amba: spear: get rid of NO_IRQ initializers

2012-01-20 Thread Viresh Kumar 
On 1/20/2012 2:57 PM, Russell King - ARM Linux wrote:
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  arch/arm/mach-spear3xx/spear300.c |2 +-
  arch/arm/mach-spear3xx/spear3xx.c |4 ++--
  arch/arm/mach-spear6xx/spear6xx.c |   10 +-
  3 files changed, 8 insertions(+), 8 deletions(-)
 
 diff --git a/arch/arm/mach-spear3xx/spear300.c 
 b/arch/arm/mach-spear3xx/spear300.c
 index a5e46b4..6fdeec9 100644
 --- a/arch/arm/mach-spear3xx/spear300.c
 +++ b/arch/arm/mach-spear3xx/spear300.c
 @@ -440,7 +440,7 @@ struct amba_device spear300_gpio1_device = {
   .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {SPEAR300_VIRQ_GPIO1, NO_IRQ},
 + .irq = {SPEAR300_VIRQ_GPIO1},
  };
  
  /* spear300 routines */
 diff --git a/arch/arm/mach-spear3xx/spear3xx.c 
 b/arch/arm/mach-spear3xx/spear3xx.c
 index 10af45d..bc4f1c6 100644
 --- a/arch/arm/mach-spear3xx/spear3xx.c
 +++ b/arch/arm/mach-spear3xx/spear3xx.c
 @@ -38,7 +38,7 @@ struct amba_device spear3xx_gpio_device = {
   .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {SPEAR3XX_IRQ_BASIC_GPIO, NO_IRQ},
 + .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
  };
  
  /* uart device registration */
 @@ -51,7 +51,7 @@ struct amba_device spear3xx_uart_device = {
   .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {SPEAR3XX_IRQ_UART, NO_IRQ},
 + .irq = {SPEAR3XX_IRQ_UART},
  };
  
  /* Do spear3xx familiy common initialization part here */
 diff --git a/arch/arm/mach-spear6xx/spear6xx.c 
 b/arch/arm/mach-spear6xx/spear6xx.c
 index e0f6628..b997b1b 100644
 --- a/arch/arm/mach-spear6xx/spear6xx.c
 +++ b/arch/arm/mach-spear6xx/spear6xx.c
 @@ -34,7 +34,7 @@ struct amba_device uart_device[] = {
   .end = SPEAR6XX_ICM1_UART0_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {IRQ_UART_0, NO_IRQ},
 + .irq = {IRQ_UART_0},
   }, {
   .dev = {
   .init_name = uart1,
 @@ -44,7 +44,7 @@ struct amba_device uart_device[] = {
   .end = SPEAR6XX_ICM1_UART1_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {IRQ_UART_1, NO_IRQ},
 + .irq = {IRQ_UART_1},
   }
  };
  
 @@ -73,7 +73,7 @@ struct amba_device gpio_device[] = {
   .end = SPEAR6XX_CPU_GPIO_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {IRQ_LOCAL_GPIO, NO_IRQ},
 + .irq = {IRQ_LOCAL_GPIO},
   }, {
   .dev = {
   .init_name = gpio1,
 @@ -84,7 +84,7 @@ struct amba_device gpio_device[] = {
   .end = SPEAR6XX_ICM3_GPIO_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {IRQ_BASIC_GPIO, NO_IRQ},
 + .irq = {IRQ_BASIC_GPIO},
   }, {
   .dev = {
   .init_name = gpio2,
 @@ -95,7 +95,7 @@ struct amba_device gpio_device[] = {
   .end = SPEAR6XX_ICM2_GPIO_BASE + SZ_4K - 1,
   .flags = IORESOURCE_MEM,
   },
 - .irq = {IRQ_APPL_GPIO, NO_IRQ},
 + .irq = {IRQ_APPL_GPIO},
   }
  };
  

Acked-by: Viresh Kumar viresh.ku...@st.com

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

Re: [PATCH 30/31] ARM: amba: spear: use common amba device initializers

2012-01-20 Thread Viresh Kumar 
On 1/20/2012 3:02 PM, Russell King - ARM Linux wrote:
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  arch/arm/mach-spear3xx/spear300.c |   14 ++
  arch/arm/mach-spear3xx/spear3xx.c |   27 ---
  2 files changed, 6 insertions(+), 35 deletions(-)
 
 diff --git a/arch/arm/mach-spear3xx/spear300.c 
 b/arch/arm/mach-spear3xx/spear300.c
 index 6fdeec9..9da50e281 100644
 --- a/arch/arm/mach-spear3xx/spear300.c
 +++ b/arch/arm/mach-spear3xx/spear300.c
 @@ -430,18 +430,8 @@ static struct pl061_platform_data gpio1_plat_data = {
   .irq_base   = SPEAR300_GPIO1_INT_BASE,
  };
  
 -struct amba_device spear300_gpio1_device = {
 - .dev = {
 - .init_name = gpio1,
 - .platform_data = gpio1_plat_data,
 - },
 - .res = {
 - .start = SPEAR300_GPIO_BASE,
 - .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
 - .flags = IORESOURCE_MEM,
 - },
 - .irq = {SPEAR300_VIRQ_GPIO1},
 -};
 +AMBA_APB_DEVICE(spear300_gpio1, gpio1, 0, SPEAR300_GPIO_BASE,
 + {SPEAR300_VIRQ_GPIO1}, gpio1_plat_data);
  
  /* spear300 routines */
  void __init spear300_init(struct pmx_mode *pmx_mode, struct pmx_dev 
 **pmx_devs,
 diff --git a/arch/arm/mach-spear3xx/spear3xx.c 
 b/arch/arm/mach-spear3xx/spear3xx.c
 index bc4f1c6..b1733c3 100644
 --- a/arch/arm/mach-spear3xx/spear3xx.c
 +++ b/arch/arm/mach-spear3xx/spear3xx.c
 @@ -28,31 +28,12 @@ static struct pl061_platform_data gpio_plat_data = {
   .irq_base   = SPEAR3XX_GPIO_INT_BASE,
  };
  
 -struct amba_device spear3xx_gpio_device = {
 - .dev = {
 - .init_name = gpio,
 - .platform_data = gpio_plat_data,
 - },
 - .res = {
 - .start = SPEAR3XX_ICM3_GPIO_BASE,
 - .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
 - .flags = IORESOURCE_MEM,
 - },
 - .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
 -};
 +AMBA_APB_DEVICE(spear3xx_gpio, gpio, 0, SPEAR3XX_ICM3_GPIO_BASE,
 + {SPEAR3XX_IRQ_BASIC_GPIO}, gpio_plat_data);
  
  /* uart device registration */
 -struct amba_device spear3xx_uart_device = {
 - .dev = {
 - .init_name = uart,
 - },
 - .res = {
 - .start = SPEAR3XX_ICM1_UART_BASE,
 - .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
 - .flags = IORESOURCE_MEM,
 - },
 - .irq = {SPEAR3XX_IRQ_UART},
 -};
 +AMBA_APB_DEVICE(spear3xx_uart, uart, 0, SPEAR3XX_ICM1_UART_BASE,
 + {SPEAR3XX_IRQ_UART}, NULL);
  
  /* Do spear3xx familiy common initialization part here */
  void __init spear3xx_init(void)

Acked-by: Viresh Kumar viresh.ku...@st.com

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

Re: [PATCH 06/13] clocksource: add common mmio clocksource

2011-05-11 Thread viresh kumar 
On 05/10/2011 12:59 PM, Russell King - ARM Linux wrote:
 Add a generic mmio clocksource, covering both 32-bit and 16-bit register
 access sizes, for up or down counters.  This can be used to easily
 create clocksources for simple counter-based implementations.
 
 Cc: Alessandro Rubini rub...@unipv.it
 Cc: Colin Cross ccr...@android.com
 Cc: Eric Miao eric.y.m...@gmail.com
 Cc: Erik Gilling konk...@android.com
 Cc: Hans J. Koch h...@hansjkoch.de
 Cc: Imre Kaloz ka...@openwrt.org
 Cc: Krzysztof Halasa k...@pm.waw.pl
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Lennert Buytenhek ker...@wantstofly.org
 Cc: Linus Walleij linus.wall...@stericsson.com
 Cc: linux-omap@vger.kernel.org
 Cc: Nicolas Pitre n...@fluxnic.net
 Cc: Olof Johansson o...@lixom.net
 Cc: Sascha Hauer ker...@pengutronix.de
 Cc: Tony Lindgren t...@atomide.com
 Cc: Viresh Kumar viresh.ku...@st.com
 Cc: Wan ZongShun mcuos@gmail.com
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  drivers/Kconfig  |3 ++
  drivers/clocksource/Kconfig  |2 +
  drivers/clocksource/Makefile |1 +
  drivers/clocksource/mmio.c   |   72 
 ++
  include/linux/clocksource.h  |8 +
  5 files changed, 86 insertions(+), 0 deletions(-)
  create mode 100644 drivers/clocksource/Kconfig
  create mode 100644 drivers/clocksource/mmio.c
 
 diff --git a/drivers/Kconfig b/drivers/Kconfig
 index 177c7d1..557a469 100644
 --- a/drivers/Kconfig
 +++ b/drivers/Kconfig
 @@ -119,4 +119,7 @@ source drivers/platform/Kconfig
  source drivers/clk/Kconfig
  
  source drivers/hwspinlock/Kconfig
 +
 +source drivers/clocksource/Kconfig
 +
  endmenu
 diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
 new file mode 100644
 index 000..47f37b1
 --- /dev/null
 +++ b/drivers/clocksource/Kconfig
 @@ -0,0 +1,2 @@
 +config CLKSRC_MMIO
 + bool
 diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
 index be61ece..9b2ba29 100644
 --- a/drivers/clocksource/Makefile
 +++ b/drivers/clocksource/Makefile
 @@ -6,3 +6,4 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)  += cs5535-clockevt.o
  obj-$(CONFIG_SH_TIMER_CMT)   += sh_cmt.o
  obj-$(CONFIG_SH_TIMER_MTU2)  += sh_mtu2.o
  obj-$(CONFIG_SH_TIMER_TMU)   += sh_tmu.o
 +obj-$(CONFIG_CLKSRC_MMIO)+= mmio.o
 diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
 new file mode 100644
 index 000..71ad3a3
 --- /dev/null
 +++ b/drivers/clocksource/mmio.c
 @@ -0,0 +1,72 @@
 +/*
 + * Generic MMIO clocksource support
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +#include linux/clocksource.h
 +#include linux/errno.h
 +#include linux/init.h
 +#include linux/slab.h
 +
 +struct clocksource_mmio {
 + void __iomem *reg;
 + struct clocksource clksrc;
 +};
 +
 +static inline struct clocksource_mmio *to_mmio_clksrc(struct clocksource *c)
 +{
 + return container_of(c, struct clocksource_mmio, clksrc);
 +}
 +
 +cycle_t clocksource_mmio_readl_up(struct clocksource *c)
 +{
 + return readl_relaxed(to_mmio_clksrc(c)-reg);
 +}
 +
 +cycle_t clocksource_mmio_readl_down(struct clocksource *c)
 +{
 + return ~readl_relaxed(to_mmio_clksrc(c)-reg);
 +}
 +
 +cycle_t clocksource_mmio_readw_up(struct clocksource *c)
 +{
 + return readw_relaxed(to_mmio_clksrc(c)-reg);
 +}
 +
 +cycle_t clocksource_mmio_readw_down(struct clocksource *c)
 +{
 + return ~(unsigned)readw_relaxed(to_mmio_clksrc(c)-reg);
 +}
 +
 +/**
 + * clocksource_mmio_init - Initialize a simple mmio based clocksource
 + * @base:Virtual address of the clock readout register
 + * @name:Name of the clocksource
 + * @hz:  Frequency of the clocksource in Hz
 + * @rating:  Rating of the clocksource
 + * @bits:Number of valid bits
 + * @read:One of clocksource_mmio_read*() above
 + */
 +int __init clocksource_mmio_init(void __iomem *base, const char *name,
 + unsigned long hz, int rating, unsigned bits,
 + cycle_t (*read)(struct clocksource *))
 +{
 + struct clocksource_mmio *cs;
 +
 + if (bits  32 || bits  16)
 + return -EINVAL;
 +
 + cs = kzalloc(sizeof(struct clocksource_mmio), GFP_KERNEL);
 + if (!cs)
 + return -ENOMEM;
 +
 + cs-clksrc.name = name;
 + cs-clksrc.rating = rating;
 + cs-clksrc.read = read;
 + cs-clksrc.mask = CLOCKSOURCE_MASK(bits);
 + cs-clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
 +
 + return clocksource_register_hz(cs-clksrc, hz);
 +}
 diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
 index 94c1f38..a3558fd 100644
 --- a/include/linux/clocksource.h
 +++ b/include/linux/clocksource.h
 @@ -341,4 +341,12 @@ static inline void update_vsyscall_tz(void)
  
  extern void timekeeping_notify(struct clocksource *clock);
  
 +extern cycle_t clocksource_mmio_readl_up(struct clocksource