Re: Undefined instruction error on Cortex A57 (aarch64) in init process

[Pankaj Jangra]

On Thu, Oct 1, 2015 at 2:24 PM, Arnd Bergmann  wrote:
> On Thursday 01 October 2015 13:02:46 Pankaj Jangra wrote:
>> In android system, after system is running for long time say 10 hour,
>> some time i am hitting below
>> traces:
>>
>>  init[1]: undefined instruction: pc=00401624
>> Code: 1a9f00c2 aa1703e0 2a1603e1 9400e1bf (6b1f001f)
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004
>>
>>
>
> Is it always the same address that causes the invalid instruction?
> This is the main loop of the init process, so it clearly got executed
> correctly before.
>
> Arnd

Yes Arnd, it always hits the same address. True, It must have been
executed lots of time.

-Pankaj Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Undefined instruction error on Cortex A57 (aarch64) in init process

[Pankaj Jangra]

In android system, after system is running for long time say 10 hour,
some time i am hitting below
traces:

 init[1]: undefined instruction: pc=00401624
Code: 1a9f00c2 aa1703e0 2a1603e1 9400e1bf (6b1f001f)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004

CPU: 0 PID: 1 Comm: init Tainted: G   O 3.10.67-g978f332 #15
Call trace:
[] dump_backtrace+0x0/0xf4
[] show_stack+0x10/0x1c
[] dump_stack+0x1c/0x28
[] panic+0xf8/0x118
[] find_new_reaper+0x98/0x154
[] forget_original_parent+0x40/0x1cc
[] exit_notify+0x14/0x16c
[] do_exit+0x2c4/0x3ec
[] do_group_exit+0xe8/0xec
[] get_signal_to_deliver+0x310/0x3a8
[] do_signal+0x160/0x180

The objdump of binary around this address is :
 401610:   eb1f011fcmp x8, xzr
 401614:   1a9f00c2cselw2, w6, wzr, eq
   bootchart_count = 0;
   }
   }
endif

   nr = poll(ufds, fd_count, timeout);
 401618:   aa1703e0mov x0, x23
 40161c:   2a1603e1mov w1, w22
 401620:   9400e1dfbl  439d9c 
   if (nr <= 0)
 401624:   6b1f001fcmp w0, wzr
 401628:   54fffccdb.le4015c0 
   continue;

   for (i = 0; i < fd_count; i++) {
 40162c:   34fffcb6cbz w22, 4015c0 
 401630:   510006c9sub w9, w22, #0x1
 401634:   aa1703f3mov x19, x23
 401638:   9100052aadd x10, x9, #0x1
 40163c:   8b0a0ef4add x20, x23, x10, lsl #3

Could any one please point me to what could be the problem here ? Or
how further i can approach to debug this further.

-Pankaj Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Undefined instruction error on Cortex A57 (aarch64) in init process

[Pankaj Jangra]

In android system, after system is running for long time say 10 hour,
some time i am hitting below
traces:

 init[1]: undefined instruction: pc=00401624
Code: 1a9f00c2 aa1703e0 2a1603e1 9400e1bf (6b1f001f)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004

CPU: 0 PID: 1 Comm: init Tainted: G   O 3.10.67-g978f332 #15
Call trace:
[] dump_backtrace+0x0/0xf4
[] show_stack+0x10/0x1c
[] dump_stack+0x1c/0x28
[] panic+0xf8/0x118
[] find_new_reaper+0x98/0x154
[] forget_original_parent+0x40/0x1cc
[] exit_notify+0x14/0x16c
[] do_exit+0x2c4/0x3ec
[] do_group_exit+0xe8/0xec
[] get_signal_to_deliver+0x310/0x3a8
[] do_signal+0x160/0x180

The objdump of binary around this address is :
 401610:   eb1f011fcmp x8, xzr
 401614:   1a9f00c2cselw2, w6, wzr, eq
   bootchart_count = 0;
   }
   }
endif

   nr = poll(ufds, fd_count, timeout);
 401618:   aa1703e0mov x0, x23
 40161c:   2a1603e1mov w1, w22
 401620:   9400e1dfbl  439d9c 
   if (nr <= 0)
 401624:   6b1f001fcmp w0, wzr
 401628:   54fffccdb.le4015c0 
   continue;

   for (i = 0; i < fd_count; i++) {
 40162c:   34fffcb6cbz w22, 4015c0 
 401630:   510006c9sub w9, w22, #0x1
 401634:   aa1703f3mov x19, x23
 401638:   9100052aadd x10, x9, #0x1
 40163c:   8b0a0ef4add x20, x23, x10, lsl #3

Could any one please point me to what could be the problem here ? Or
how further i can approach to debug this further.

-Pankaj Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Undefined instruction error on Cortex A57 (aarch64) in init process

[Pankaj Jangra]

On Thu, Oct 1, 2015 at 2:24 PM, Arnd Bergmann <a...@arndb.de> wrote:
> On Thursday 01 October 2015 13:02:46 Pankaj Jangra wrote:
>> In android system, after system is running for long time say 10 hour,
>> some time i am hitting below
>> traces:
>>
>>  init[1]: undefined instruction: pc=00401624
>> Code: 1a9f00c2 aa1703e0 2a1603e1 9400e1bf (6b1f001f)
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004
>>
>>
>
> Is it always the same address that causes the invalid instruction?
> This is the main loop of the init process, so it clearly got executed
> correctly before.
>
> Arnd

Yes Arnd, it always hits the same address. True, It must have been
executed lots of time.

-Pankaj Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] power: Fix comment typo in pm_wakeup.h

[Pankaj Jangra]

Hi,

On Thu, Jul 11, 2013 at 10:25 AM, Chanwoo Choi  wrote:
> This patch fix typo (sorce -> source)
>
> Signed-off-by: Chanwoo Choi 
> ---
>  include/linux/pm_wakeup.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
Looks Good.

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] power: Fix comment typo in pm_wakeup.h

[Pankaj Jangra]

Hi,

On Thu, Jul 11, 2013 at 10:25 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch fix typo (sorce - source)

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  include/linux/pm_wakeup.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Looks Good.

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] cpufreq: Add debugfs directory for cpufreq

[Pankaj Jangra]

gt; struct subsys_interface *sif
>
> if (cpu != data->cpu) {
> sysfs_remove_link(>kobj, "cpufreq");
> +   debugfs_remove(data->cpu_debugfs[cpu]);

I think you should add the call to remove the "cpufreq" also ???
   "debugfs_remove(cpufreq_debugfs);"
> } else if (cpus > 1) {
> /* first sibling now owns the new sysfs dir */
> cpu_dev = get_cpu_device(cpumask_first(data->cpus));
> @@ -1068,6 +1118,9 @@ static int __cpufreq_remove_dev(struct device *dev, 
> struct subsys_interface *sif
> return -EINVAL;
> }
>
> +   debugfs_remove_recursive(data->cpu_debugfs[cpu]);
> +   debugfs_remove(cpufreq_debugfs);
> +
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(data, cpu_dev->id);
> unlock_policy_rwsem_write(cpu);
> @@ -1976,6 +2029,10 @@ static int __init cpufreq_core_init(void)
> BUG_ON(!cpufreq_global_kobject);
> register_syscore_ops(_syscore_ops);
>
> +   cpufreq_debugfs = debugfs_create_dir("cpufreq", NULL);
> +   if (!cpufreq_debugfs)
> +   pr_debug("creating debugfs root failed\n");
> +
> return 0;
>  }
>  core_initcall(cpufreq_core_init);
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 037d36a..825f379 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -115,6 +115,7 @@ struct cpufreq_policy {
>
> struct kobject  kobj;
> struct completion   kobj_unregister;
> +   struct dentry   **cpu_debugfs;
>  };
>
>  #define CPUFREQ_ADJUST (0)
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] cpufreq: Add debugfs directory for cpufreq

[Pankaj Jangra]

 = get_cpu_device(cpumask_first(data-cpus));
 @@ -1068,6 +1118,9 @@ static int __cpufreq_remove_dev(struct device *dev, 
 struct subsys_interface *sif
 return -EINVAL;
 }

 +   debugfs_remove_recursive(data-cpu_debugfs[cpu]);
 +   debugfs_remove(cpufreq_debugfs);
 +
 WARN_ON(lock_policy_rwsem_write(cpu));
 update_policy_cpu(data, cpu_dev-id);
 unlock_policy_rwsem_write(cpu);
 @@ -1976,6 +2029,10 @@ static int __init cpufreq_core_init(void)
 BUG_ON(!cpufreq_global_kobject);
 register_syscore_ops(cpufreq_syscore_ops);

 +   cpufreq_debugfs = debugfs_create_dir(cpufreq, NULL);
 +   if (!cpufreq_debugfs)
 +   pr_debug(creating debugfs root failed\n);
 +
 return 0;
  }
  core_initcall(cpufreq_core_init);
 diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
 index 037d36a..825f379 100644
 --- a/include/linux/cpufreq.h
 +++ b/include/linux/cpufreq.h
 @@ -115,6 +115,7 @@ struct cpufreq_policy {

 struct kobject  kobj;
 struct completion   kobj_unregister;
 +   struct dentry   **cpu_debugfs;
  };

  #define CPUFREQ_ADJUST (0)
 --
 1.8.0

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

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] drivers: gpio: msm: Fix the error condition for reading ngpio

[Pankaj Jangra]

Hi,


On Wed, Jun 19, 2013 at 7:23 AM, Rohit Vaswani  wrote:
>
> of_property_read_u32 return 0 on success. The check was using a ! to
> return error. Fix the if condition.
>
> Signed-off-by: Rohit Vaswani 
> ---
>  drivers/gpio/gpio-msm-v2.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Appropriate change.

Reviewed-by: Pankaj Jangra  

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] drivers: gpio: msm: Fix the error condition for reading ngpio

[Pankaj Jangra]

Hi,


On Wed, Jun 19, 2013 at 7:23 AM, Rohit Vaswani rvasw...@codeaurora.org wrote:

 of_property_read_u32 return 0 on success. The check was using a ! to
 return error. Fix the if condition.

 Signed-off-by: Rohit Vaswani rvasw...@codeaurora.org
 ---
  drivers/gpio/gpio-msm-v2.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Appropriate change.

Reviewed-by: Pankaj Jangra  jangra.pank...@gmail.com

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] clk: Fix incorrect return type in clk.c

[Pankaj Jangra]

Hi.

On Wed, Mar 13, 2013 at 3:17 PM, Sachin Kamat  wrote:
> Return type of function clk_propagate_rate_change is a pointer.
> But 0 was being returned. Change it to NULL.
> Silences the following warning:
> drivers/clk/clk.c:977:24: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/clk/clk.c |2 +-

Looks good to me.
Reviewed-by: Pankaj Jangra 

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] clk: Fix incorrect return type in clk.c

[Pankaj Jangra]

Hi.

On Wed, Mar 13, 2013 at 3:17 PM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Return type of function clk_propagate_rate_change is a pointer.
 But 0 was being returned. Change it to NULL.
 Silences the following warning:
 drivers/clk/clk.c:977:24: warning: Using plain integer as NULL pointer

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/clk/clk.c |2 +-

Looks good to me.
Reviewed-by: Pankaj Jangra jangra.pank...@gmail.com

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] ARM: msm: Migrate to common clock framework

[Pankaj Jangra]

Hi,

On Thu, Sep 27, 2012 at 12:20 AM, Stephen Boyd  wrote:
> On 09/26/12 11:47, Pankaj Jangra wrote:
>> Hi Stephen,
>>
>> On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
>>
>>> -static int pc_clk_set_rate(unsigned id, unsigned rate)
>>> +static int pc_clk_set_rate(struct clk_hw *hw, unsigned long new_rate,
>>> +  unsigned long p_rate)
>>>  {
>>> -   /* The rate _might_ be rounded off to the nearest KHz value by the
>>> +   struct clk_pcom *p = to_clk_pcom(hw);
>>> +   unsigned id = p->id, rate = new_rate;
>>> +   int rc;
>>> +
>>> +   /*
>>> +* The rate _might_ be rounded off to the nearest KHz value by the
>>>  * remote function. So a return value of 0 doesn't necessarily mean
>>>  * that the exact rate was set successfully.
>>>  */
>>> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, , );
>>> -   if (rc < 0)
>>> -   return rc;
>>> -   else
>>> -   return (int)id < 0 ? -EINVAL : 0;
>>> -}
>>> -
>>> -static int pc_clk_set_min_rate(unsigned id, unsigned rate)
>>> -{
>>> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, , );
>>> -   if (rc < 0)
>>> -   return rc;
>>> +   if (p->flags & CLKFLAG_MIN)
>>> +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, , );
>> You are missing if condition here checking the rc ?
>>
>>> else
>>> -   return (int)id < 0 ? -EINVAL : 0;
>>> -}
>>> -
>>> -static int pc_clk_set_max_rate(unsigned id, unsigned rate)
>>> -{
>>> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MAX_RATE, , );
>> and else here i think for the MIN_FLAG if check.
>>
>>> +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, , );
>>> if (rc < 0)
>>> return rc;
>>> else
>>> return (int)id < 0 ? -EINVAL : 0;
>>>  }
>
> This is the resulting code:
>
>     if (p->flags & CLKFLAG_MIN)
> rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, , );
> else
> rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, , );
> if (rc < 0)
> return rc;
> else
> return (int)id < 0 ? -EINVAL : 0;
>
> So we check the rc for both cases in the same if condition. Is there
> anything wrong?
My mistake. I overlooked a line. Sorry for spam. Thanks

--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] ARM: msm: Remove clock-7x30.h include file

[Pankaj Jangra]

Hi,

On Wed, Sep 26, 2012 at 11:48 PM, Stephen Boyd  wrote:
> On 09/26/12 10:51, Pankaj Jangra wrote:
>> On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
>>> diff --git a/arch/arm/mach-msm/devices-msm7x30.c 
>>> b/arch/arm/mach-msm/devices-msm7x30.c
>>> index 09b4f14..1597d43 100644
>>> --- a/arch/arm/mach-msm/devices-msm7x30.c
>>> +++ b/arch/arm/mach-msm/devices-msm7x30.c
>>> @@ -146,7 +146,6 @@ struct clk_lookup msm_clocks_7x30[] = {
>>> CLK_PCOM("grp_2d_pclk", GRP_2D_P_CLK,   NULL, 0),
>>> CLK_PCOM("grp_clk", GRP_3D_CLK, NULL, 0),
>>> CLK_PCOM("grp_pclk",GRP_3D_P_CLK,   NULL, 0),
>>> -   CLK_7X30S("grp_src_clk", GRP_3D_SRC_CLK, GRP_3D_CLK,NULL, 0),
>>> CLK_PCOM("hdmi_clk",HDMI_CLK,   NULL, 0),
>>> CLK_PCOM("imem_clk",IMEM_CLK,   NULL, OFF),
>> I suppose you forget to remove the include header clock-7x30.h from
>> this file. :)
>
> Thanks, fixed. BTW, you could have trimmed this mail down so I didn't
> have to scroll to the bottom.
>
ah, i think mistakenly i forgot. Next time will keep in mind..:)

--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

On Thu, Sep 27, 2012 at 12:18 AM, Stephen Boyd  wrote:
> On 09/26/12 09:58, Pankaj Jangra wrote:
>> On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
>>> diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
>>> index 9f5fc90..2ae0639 100644
>>> --- a/drivers/usb/otg/msm_otg.c
>>> +++ b/drivers/usb/otg/msm_otg.c
>>> @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
>>> motg->pdata->otg_control == OTG_PMIC_CONTROL)
>>> writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
>>>
>>> -   clk_disable(motg->pclk);
>>> -   clk_disable(motg->clk);
>>> +   clk_disable_unprepare(motg->pclk);
>>> +   clk_disable_unprepare(motg->clk);
>>> if (motg->core_clk)
>>> -   clk_disable(motg->core_clk);
>>> +   clk_disable_unprepare(motg->core_clk);
>>>
>> I was under assumption that system suspend/resume might be called from
>> the interrupt context. If that is case then its not appropriate to
>> call clk_prepare/unprepare here right? or my understanding is not correct
>
> Well we call disable_irq() at the top of this suspend function so I
> suspect your understanding is incorrect. disable_irq() can call
> schedule(). There are also a bunch of regulator calls in
> msm_hsusb_ldo_set_mode() that this suspend function calls (almost all
> regulator calls grab a mutex).

Ok, might be i am worng because in acpuclock driver of msm on
codeaurora tree, i have seen in commit text saying that it can be
called from suspend/resume in interrupt context .
So i was assuming that. Any way thanks.

--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] ARM: msm: Migrate to common clock framework

[Pankaj Jangra]

Hi Stephen,

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:

> -static int pc_clk_set_rate(unsigned id, unsigned rate)
> +static int pc_clk_set_rate(struct clk_hw *hw, unsigned long new_rate,
> +  unsigned long p_rate)
>  {
> -   /* The rate _might_ be rounded off to the nearest KHz value by the
> +   struct clk_pcom *p = to_clk_pcom(hw);
> +   unsigned id = p->id, rate = new_rate;
> +   int rc;
> +
> +   /*
> +* The rate _might_ be rounded off to the nearest KHz value by the
>  * remote function. So a return value of 0 doesn't necessarily mean
>  * that the exact rate was set successfully.
>  */
> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, , );
> -   if (rc < 0)
> -   return rc;
> -   else
> -   return (int)id < 0 ? -EINVAL : 0;
> -}
> -
> -static int pc_clk_set_min_rate(unsigned id, unsigned rate)
> -{
> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, , );
> -   if (rc < 0)
> -   return rc;
> +   if (p->flags & CLKFLAG_MIN)
> +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, , );

You are missing if condition here checking the rc ?

> else
> -   return (int)id < 0 ? -EINVAL : 0;
> -}
> -
> -static int pc_clk_set_max_rate(unsigned id, unsigned rate)
> -{
> -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MAX_RATE, , );

and else here i think for the MIN_FLAG if check.

> +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, , );
>     if (rc < 0)
> return rc;
> else
> return (int)id < 0 ? -EINVAL : 0;
>  }
>
--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/10] ARM: msm: Make proc_comm clock control into a platform driver

[Pankaj Jangra]

Hi Stephen,

Its good  you started moving the msm to common clock framework.:)
I hope msm's codeaurora tree will also be moved to CCF soon. :)

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
> To move closer to the generic struct clock framework move the
> proc_comm based clock code to a platform driver. The data
> describing the struct clks still live in the devices-$ARCH file,
> but the clock initialization is done at driver binding time.
>
> Cc: Saravana Kannan 
> Signed-off-by: Stephen Boyd 
> ---
Reviewed-by: Pankaj Jangra

>  arch/arm/mach-msm/board-halibut.c  |  2 +-
>  arch/arm/mach-msm/board-msm7x30.c  |  2 +-
>  arch/arm/mach-msm/board-qsd8x50.c  |  2 +-
>  arch/arm/mach-msm/board-trout.c|  3 +--
>  arch/arm/mach-msm/clock-pcom.c | 23 +--
>  arch/arm/mach-msm/clock-pcom.h |  5 +
>  arch/arm/mach-msm/clock.c  |  2 +-
>  arch/arm/mach-msm/clock.h  |  3 +++
>  arch/arm/mach-msm/devices-msm7x00.c| 12 ++--
>  arch/arm/mach-msm/devices-msm7x30.c| 11 +--
>  arch/arm/mach-msm/devices-qsd8x50.c| 11 +--
>  arch/arm/mach-msm/devices.h| 15 +++
>  arch/arm/mach-msm/include/mach/board.h |  5 -
>  13 files changed, 65 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-msm/board-halibut.c 
> b/arch/arm/mach-msm/board-halibut.c
> index 6ce542e..3c8cfe4 100644
> --- a/arch/arm/mach-msm/board-halibut.c
> +++ b/arch/arm/mach-msm/board-halibut.c
> @@ -59,6 +59,7 @@ static struct platform_device smc91x_device = {
>  };

> +
> +static int __devinit msm_clock_pcom_probe(struct platform_device *pdev)
> +{
> +   struct pcom_clk_pdata *pdata = pdev->dev.platform_data;

Should'nt it be const struct?

> +   msm_clock_init(pdata->lookup, pdata->num_lookups);
> +   return 0;
> +}
> +
--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] ARM: msm: Remove clock-7x30.h include file

[Pankaj Jangra]

Hi

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
> This file is not used outside of the two users in the clock-7x30
> array. Those two clocks are virtual "source" clocks that don't
> really need to exist outside of the clock driver. Let's remove
> them from the array, since they're not doing anything anyway, and
> then remove the clock-7x30.h include file along with it.
>
> Cc: Saravana Kannan 
> Signed-off-by: Stephen Boyd 
> ---
>  arch/arm/mach-msm/clock-7x30.h  | 155 
> 
>  arch/arm/mach-msm/devices-msm7x30.c |   2 -
>  2 files changed, 157 deletions(-)
>  delete mode 100644 arch/arm/mach-msm/clock-7x30.h
>
> diff --git a/arch/arm/mach-msm/clock-7x30.h b/arch/arm/mach-msm/clock-7x30.h
> deleted file mode 100644
> index 1410445..000
> --- a/arch/arm/mach-msm/clock-7x30.h
> +++ /dev/null
> @@ -1,155 +0,0 @@
> -/* Copyright (c) 2009, Code Aurora Forum. All rights reserved.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 and
> - * only version 2 as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -#ifndef __ARCH_ARM_MACH_MSM_CLOCK_7X30_H
> -#define __ARCH_ARM_MACH_MSM_CLOCK_7X30_H
> -
> -enum {
> -   L_7X30_NONE_CLK = -1,
> -   L_7X30_ADM_CLK,
> -   L_7X30_I2C_CLK,
> -   L_7X30_I2C_2_CLK,
> -   L_7X30_QUP_I2C_CLK,
> -   L_7X30_UART1DM_CLK,
> -   L_7X30_UART1DM_P_CLK,
> -   L_7X30_UART2DM_CLK,
> -   L_7X30_UART2DM_P_CLK,
> -   L_7X30_EMDH_CLK,
> -   L_7X30_EMDH_P_CLK,
> -   L_7X30_PMDH_CLK,
> -   L_7X30_PMDH_P_CLK,
> -   L_7X30_GRP_2D_CLK,
> -   L_7X30_GRP_2D_P_CLK,
> -   L_7X30_GRP_3D_SRC_CLK,
> -   L_7X30_GRP_3D_CLK,
> -   L_7X30_GRP_3D_P_CLK,
> -   L_7X30_IMEM_CLK,
> -   L_7X30_SDC1_CLK,
> -   L_7X30_SDC1_P_CLK,
> -   L_7X30_SDC2_CLK,
> -   L_7X30_SDC2_P_CLK,
> -   L_7X30_SDC3_CLK,
> -   L_7X30_SDC3_P_CLK,
> -   L_7X30_SDC4_CLK,
> -   L_7X30_SDC4_P_CLK,
> -   L_7X30_MDP_CLK,
> -   L_7X30_MDP_P_CLK,
> -   L_7X30_MDP_LCDC_PCLK_CLK,
> -   L_7X30_MDP_LCDC_PAD_PCLK_CLK,
> -   L_7X30_MDP_VSYNC_CLK,
> -   L_7X30_MI2S_CODEC_RX_M_CLK,
> -   L_7X30_MI2S_CODEC_RX_S_CLK,
> -   L_7X30_MI2S_CODEC_TX_M_CLK,
> -   L_7X30_MI2S_CODEC_TX_S_CLK,
> -   L_7X30_MI2S_M_CLK,
> -   L_7X30_MI2S_S_CLK,
> -   L_7X30_LPA_CODEC_CLK,
> -   L_7X30_LPA_CORE_CLK,
> -   L_7X30_LPA_P_CLK,
> -   L_7X30_MIDI_CLK,
> -   L_7X30_MDC_CLK,
> -   L_7X30_ROTATOR_IMEM_CLK,
> -   L_7X30_ROTATOR_P_CLK,
> -   L_7X30_SDAC_M_CLK,
> -   L_7X30_SDAC_CLK,
> -   L_7X30_UART1_CLK,
> -   L_7X30_UART2_CLK,
> -   L_7X30_UART3_CLK,
> -   L_7X30_TV_CLK,
> -   L_7X30_TV_DAC_CLK,
> -   L_7X30_TV_ENC_CLK,
> -   L_7X30_HDMI_CLK,
> -   L_7X30_TSIF_REF_CLK,
> -   L_7X30_TSIF_P_CLK,
> -   L_7X30_USB_HS_SRC_CLK,
> -   L_7X30_USB_HS_CLK,
> -   L_7X30_USB_HS_CORE_CLK,
> -   L_7X30_USB_HS_P_CLK,
> -   L_7X30_USB_HS2_CLK,
> -   L_7X30_USB_HS2_CORE_CLK,
> -   L_7X30_USB_HS2_P_CLK,
> -   L_7X30_USB_HS3_CLK,
> -   L_7X30_USB_HS3_CORE_CLK,
> -   L_7X30_USB_HS3_P_CLK,
> -   L_7X30_VFE_CLK,
> -   L_7X30_VFE_P_CLK,
> -   L_7X30_VFE_MDC_CLK,
> -   L_7X30_VFE_CAMIF_CLK,
> -   L_7X30_CAMIF_PAD_P_CLK,
> -   L_7X30_CAM_M_CLK,
> -   L_7X30_JPEG_CLK,
> -   L_7X30_JPEG_P_CLK,
> -   L_7X30_VPE_CLK,
> -   L_7X30_MFC_CLK,
> -   L_7X30_MFC_DIV2_CLK,
> -   L_7X30_MFC_P_CLK,
> -   L_7X30_SPI_CLK,
> -   L_7X30_SPI_P_CLK,
> -   L_7X30_CSI0_CLK,
> -   L_7X30_CSI0_VFE_CLK,
> -   L_7X30_CSI0_P_CLK,
> -   L_7X30_CSI1_CLK,
> -   L_7X30_CSI1_VFE_CLK,
> -   L_7X30_CSI1_P_CLK,
> -   L_7X30_GLBL_ROOT_CLK,
> -
> -   L_7X30_AXI_LI_VG_CLK,
> -   L_7X30_AXI_LI_GRP_CLK,
> -   L_7X30_AXI_LI_JPEG_CLK,
> -   L_7X30_AXI_GRP_2D_CLK,
> -   L_7X30_AXI_MFC_CLK,
> -   L_7X30_AXI_VPE_CLK,
> -   L_7X30_AXI_LI_VFE_CLK,
> -   L_7X30_AXI_LI_APPS_CLK,
> -   L_7X30_AXI_MDP_CLK,
> -   L_7X30_AXI_IMEM_CLK,
> -   L_7X30_AXI_LI_ADSP_A_CLK,
> -   L_7X30_AXI_ROTATOR_CLK,
> -
> -   L_7X30_NR_CLKS
> -};
> -
> -struct clk_ops;
> -extern struct clk_ops clk_ops_7x30;
> -
> -struct clk_ops *clk_7x30_is_local(uint32_t id);
> -int clk_7x30_init(void);
> -
> -void pll_enable(uint32_t pll);
> -void pll_disable(uint32_t pll);
> -
> -extern int internal_pwr_rail_ctl_auto(unsigned rail_id, bool enable);
> -
> -#define CLK_7X30(clk_name, clk_id, clk_dev, clk_flags) {   \
> -   .con_id = clk_name, \
> -   .dev_id = clk_dev, \

Re: [PATCH 08/10] ARM: msm: Prepare clk_get() users in mach-msm for clock-pcom driver

[Pankaj Jangra]

Hi,

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
> In the near future we'll be moving clock-pcom to a platform
> driver, in which case these two users of clk_get() in mach-msm
> need to be updated. Have board-trout-panel.c make the proc_comm
> call directly so that we don't have to port this board specific
> code to the driver right now and reorder the initcall order of
> dma.c so that it initializes after the clock driver probes but
> before any drivers use dma APIs.
>
> Signed-off-by: Stephen Boyd 
> ---
>  arch/arm/mach-msm/Makefile|  9 ++---
>  arch/arm/mach-msm/board-trout-panel.c | 19 +++
>  arch/arm/mach-msm/dma.c   |  5 ++---
>  3 files changed, 15 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
> index 17519fa..3dbae74 100644
> --- a/arch/arm/mach-msm/Makefile
> +++ b/arch/arm/mach-msm/Makefile
> @@ -5,12 +5,15 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
>  obj-$(CONFIG_MSM_VIC) += irq-vic.o
>  obj-$(CONFIG_MSM_IOMMU) += devices-iommu.o
>
> -obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o
> -obj-$(CONFIG_ARCH_MSM7X30) += dma.o
> -obj-$(CONFIG_ARCH_QSD8X50) += dma.o sirc.o
> +obj-$(CONFIG_ARCH_MSM7X00A) += irq.o
> +obj-$(CONFIG_ARCH_QSD8X50) += sirc.o
>
>  obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
>
> +obj-$(CONFIG_ARCH_MSM7X00A) += dma.o
> +obj-$(CONFIG_ARCH_MSM7X30) += dma.o
> +obj-$(CONFIG_ARCH_QSD8X50) += dma.o
> +
I did not understand what is the need of this change in Makefile?

--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

Hi..

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd  wrote:
> Add calls to clk_prepare and unprepare so that MSM can migrate to
> the common clock framework.
>
> Cc: Felipe Balbi 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/otg/msm_otg.c | 38 +++---
>  1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
> index 9f5fc90..2ae0639 100644
> --- a/drivers/usb/otg/msm_otg.c
> +++ b/drivers/usb/otg/msm_otg.c
> @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
> motg->pdata->otg_control == OTG_PMIC_CONTROL)
> writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);
>
> -   clk_disable(motg->pclk);
> -   clk_disable(motg->clk);
> +   clk_disable_unprepare(motg->pclk);
> +   clk_disable_unprepare(motg->clk);
> if (motg->core_clk)
> -   clk_disable(motg->core_clk);
> +   clk_disable_unprepare(motg->core_clk);
>
I was under assumption that system suspend/resume might be called from
the interrupt context. If that is case then its not appropriate to
call clk_prepare/unprepare here right? or my understanding is not correct

--
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

Hi..

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 Add calls to clk_prepare and unprepare so that MSM can migrate to
 the common clock framework.

 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
  drivers/usb/otg/msm_otg.c | 38 +++---
  1 file changed, 19 insertions(+), 19 deletions(-)

 diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
 index 9f5fc90..2ae0639 100644
 --- a/drivers/usb/otg/msm_otg.c
 +++ b/drivers/usb/otg/msm_otg.c
 @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
 motg-pdata-otg_control == OTG_PMIC_CONTROL)
 writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);

 -   clk_disable(motg-pclk);
 -   clk_disable(motg-clk);
 +   clk_disable_unprepare(motg-pclk);
 +   clk_disable_unprepare(motg-clk);
 if (motg-core_clk)
 -   clk_disable(motg-core_clk);
 +   clk_disable_unprepare(motg-core_clk);

I was under assumption that system suspend/resume might be called from
the interrupt context. If that is case then its not appropriate to
call clk_prepare/unprepare here right? or my understanding is not correct

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] ARM: msm: Prepare clk_get() users in mach-msm for clock-pcom driver

[Pankaj Jangra]

Hi,

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 In the near future we'll be moving clock-pcom to a platform
 driver, in which case these two users of clk_get() in mach-msm
 need to be updated. Have board-trout-panel.c make the proc_comm
 call directly so that we don't have to port this board specific
 code to the driver right now and reorder the initcall order of
 dma.c so that it initializes after the clock driver probes but
 before any drivers use dma APIs.

 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
  arch/arm/mach-msm/Makefile|  9 ++---
  arch/arm/mach-msm/board-trout-panel.c | 19 +++
  arch/arm/mach-msm/dma.c   |  5 ++---
  3 files changed, 15 insertions(+), 18 deletions(-)

 diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
 index 17519fa..3dbae74 100644
 --- a/arch/arm/mach-msm/Makefile
 +++ b/arch/arm/mach-msm/Makefile
 @@ -5,12 +5,15 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
  obj-$(CONFIG_MSM_VIC) += irq-vic.o
  obj-$(CONFIG_MSM_IOMMU) += devices-iommu.o

 -obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o
 -obj-$(CONFIG_ARCH_MSM7X30) += dma.o
 -obj-$(CONFIG_ARCH_QSD8X50) += dma.o sirc.o
 +obj-$(CONFIG_ARCH_MSM7X00A) += irq.o
 +obj-$(CONFIG_ARCH_QSD8X50) += sirc.o

  obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o

 +obj-$(CONFIG_ARCH_MSM7X00A) += dma.o
 +obj-$(CONFIG_ARCH_MSM7X30) += dma.o
 +obj-$(CONFIG_ARCH_QSD8X50) += dma.o
 +
I did not understand what is the need of this change in Makefile?

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] ARM: msm: Remove clock-7x30.h include file

[Pankaj Jangra]

Hi

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 This file is not used outside of the two users in the clock-7x30
 array. Those two clocks are virtual source clocks that don't
 really need to exist outside of the clock driver. Let's remove
 them from the array, since they're not doing anything anyway, and
 then remove the clock-7x30.h include file along with it.

 Cc: Saravana Kannan skan...@codeaurora.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
  arch/arm/mach-msm/clock-7x30.h  | 155 
 
  arch/arm/mach-msm/devices-msm7x30.c |   2 -
  2 files changed, 157 deletions(-)
  delete mode 100644 arch/arm/mach-msm/clock-7x30.h

 diff --git a/arch/arm/mach-msm/clock-7x30.h b/arch/arm/mach-msm/clock-7x30.h
 deleted file mode 100644
 index 1410445..000
 --- a/arch/arm/mach-msm/clock-7x30.h
 +++ /dev/null
 @@ -1,155 +0,0 @@
 -/* Copyright (c) 2009, Code Aurora Forum. All rights reserved.
 - *
 - * This program is free software; you can redistribute it and/or modify
 - * it under the terms of the GNU General Public License version 2 and
 - * only version 2 as published by the Free Software Foundation.
 - *
 - * This program is distributed in the hope that it will be useful,
 - * but WITHOUT ANY WARRANTY; without even the implied warranty of
 - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 - * GNU General Public License for more details.
 - */
 -
 -#ifndef __ARCH_ARM_MACH_MSM_CLOCK_7X30_H
 -#define __ARCH_ARM_MACH_MSM_CLOCK_7X30_H
 -
 -enum {
 -   L_7X30_NONE_CLK = -1,
 -   L_7X30_ADM_CLK,
 -   L_7X30_I2C_CLK,
 -   L_7X30_I2C_2_CLK,
 -   L_7X30_QUP_I2C_CLK,
 -   L_7X30_UART1DM_CLK,
 -   L_7X30_UART1DM_P_CLK,
 -   L_7X30_UART2DM_CLK,
 -   L_7X30_UART2DM_P_CLK,
 -   L_7X30_EMDH_CLK,
 -   L_7X30_EMDH_P_CLK,
 -   L_7X30_PMDH_CLK,
 -   L_7X30_PMDH_P_CLK,
 -   L_7X30_GRP_2D_CLK,
 -   L_7X30_GRP_2D_P_CLK,
 -   L_7X30_GRP_3D_SRC_CLK,
 -   L_7X30_GRP_3D_CLK,
 -   L_7X30_GRP_3D_P_CLK,
 -   L_7X30_IMEM_CLK,
 -   L_7X30_SDC1_CLK,
 -   L_7X30_SDC1_P_CLK,
 -   L_7X30_SDC2_CLK,
 -   L_7X30_SDC2_P_CLK,
 -   L_7X30_SDC3_CLK,
 -   L_7X30_SDC3_P_CLK,
 -   L_7X30_SDC4_CLK,
 -   L_7X30_SDC4_P_CLK,
 -   L_7X30_MDP_CLK,
 -   L_7X30_MDP_P_CLK,
 -   L_7X30_MDP_LCDC_PCLK_CLK,
 -   L_7X30_MDP_LCDC_PAD_PCLK_CLK,
 -   L_7X30_MDP_VSYNC_CLK,
 -   L_7X30_MI2S_CODEC_RX_M_CLK,
 -   L_7X30_MI2S_CODEC_RX_S_CLK,
 -   L_7X30_MI2S_CODEC_TX_M_CLK,
 -   L_7X30_MI2S_CODEC_TX_S_CLK,
 -   L_7X30_MI2S_M_CLK,
 -   L_7X30_MI2S_S_CLK,
 -   L_7X30_LPA_CODEC_CLK,
 -   L_7X30_LPA_CORE_CLK,
 -   L_7X30_LPA_P_CLK,
 -   L_7X30_MIDI_CLK,
 -   L_7X30_MDC_CLK,
 -   L_7X30_ROTATOR_IMEM_CLK,
 -   L_7X30_ROTATOR_P_CLK,
 -   L_7X30_SDAC_M_CLK,
 -   L_7X30_SDAC_CLK,
 -   L_7X30_UART1_CLK,
 -   L_7X30_UART2_CLK,
 -   L_7X30_UART3_CLK,
 -   L_7X30_TV_CLK,
 -   L_7X30_TV_DAC_CLK,
 -   L_7X30_TV_ENC_CLK,
 -   L_7X30_HDMI_CLK,
 -   L_7X30_TSIF_REF_CLK,
 -   L_7X30_TSIF_P_CLK,
 -   L_7X30_USB_HS_SRC_CLK,
 -   L_7X30_USB_HS_CLK,
 -   L_7X30_USB_HS_CORE_CLK,
 -   L_7X30_USB_HS_P_CLK,
 -   L_7X30_USB_HS2_CLK,
 -   L_7X30_USB_HS2_CORE_CLK,
 -   L_7X30_USB_HS2_P_CLK,
 -   L_7X30_USB_HS3_CLK,
 -   L_7X30_USB_HS3_CORE_CLK,
 -   L_7X30_USB_HS3_P_CLK,
 -   L_7X30_VFE_CLK,
 -   L_7X30_VFE_P_CLK,
 -   L_7X30_VFE_MDC_CLK,
 -   L_7X30_VFE_CAMIF_CLK,
 -   L_7X30_CAMIF_PAD_P_CLK,
 -   L_7X30_CAM_M_CLK,
 -   L_7X30_JPEG_CLK,
 -   L_7X30_JPEG_P_CLK,
 -   L_7X30_VPE_CLK,
 -   L_7X30_MFC_CLK,
 -   L_7X30_MFC_DIV2_CLK,
 -   L_7X30_MFC_P_CLK,
 -   L_7X30_SPI_CLK,
 -   L_7X30_SPI_P_CLK,
 -   L_7X30_CSI0_CLK,
 -   L_7X30_CSI0_VFE_CLK,
 -   L_7X30_CSI0_P_CLK,
 -   L_7X30_CSI1_CLK,
 -   L_7X30_CSI1_VFE_CLK,
 -   L_7X30_CSI1_P_CLK,
 -   L_7X30_GLBL_ROOT_CLK,
 -
 -   L_7X30_AXI_LI_VG_CLK,
 -   L_7X30_AXI_LI_GRP_CLK,
 -   L_7X30_AXI_LI_JPEG_CLK,
 -   L_7X30_AXI_GRP_2D_CLK,
 -   L_7X30_AXI_MFC_CLK,
 -   L_7X30_AXI_VPE_CLK,
 -   L_7X30_AXI_LI_VFE_CLK,
 -   L_7X30_AXI_LI_APPS_CLK,
 -   L_7X30_AXI_MDP_CLK,
 -   L_7X30_AXI_IMEM_CLK,
 -   L_7X30_AXI_LI_ADSP_A_CLK,
 -   L_7X30_AXI_ROTATOR_CLK,
 -
 -   L_7X30_NR_CLKS
 -};
 -
 -struct clk_ops;
 -extern struct clk_ops clk_ops_7x30;
 -
 -struct clk_ops *clk_7x30_is_local(uint32_t id);
 -int clk_7x30_init(void);
 -
 -void pll_enable(uint32_t pll);
 -void pll_disable(uint32_t pll);
 -
 -extern int internal_pwr_rail_ctl_auto(unsigned rail_id, bool enable);
 -
 -#define CLK_7X30(clk_name, clk_id, clk_dev, clk_flags) {   \
 -   .con_id = clk_name, \
 -   .dev_id = clk_dev, \
 -   .clk = (struct clk){ \
 -   .id = L_7X30_##clk_id, \
 -   

Re: [PATCH 09/10] ARM: msm: Make proc_comm clock control into a platform driver

[Pankaj Jangra]

Hi Stephen,

Its good  you started moving the msm to common clock framework.:)
I hope msm's codeaurora tree will also be moved to CCF soon. :)

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 To move closer to the generic struct clock framework move the
 proc_comm based clock code to a platform driver. The data
 describing the struct clks still live in the devices-$ARCH file,
 but the clock initialization is done at driver binding time.

 Cc: Saravana Kannan skan...@codeaurora.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
Reviewed-by: Pankaj Jangrajangra.pank...@gmail.com

  arch/arm/mach-msm/board-halibut.c  |  2 +-
  arch/arm/mach-msm/board-msm7x30.c  |  2 +-
  arch/arm/mach-msm/board-qsd8x50.c  |  2 +-
  arch/arm/mach-msm/board-trout.c|  3 +--
  arch/arm/mach-msm/clock-pcom.c | 23 +--
  arch/arm/mach-msm/clock-pcom.h |  5 +
  arch/arm/mach-msm/clock.c  |  2 +-
  arch/arm/mach-msm/clock.h  |  3 +++
  arch/arm/mach-msm/devices-msm7x00.c| 12 ++--
  arch/arm/mach-msm/devices-msm7x30.c| 11 +--
  arch/arm/mach-msm/devices-qsd8x50.c| 11 +--
  arch/arm/mach-msm/devices.h| 15 +++
  arch/arm/mach-msm/include/mach/board.h |  5 -
  13 files changed, 65 insertions(+), 31 deletions(-)

 diff --git a/arch/arm/mach-msm/board-halibut.c 
 b/arch/arm/mach-msm/board-halibut.c
 index 6ce542e..3c8cfe4 100644
 --- a/arch/arm/mach-msm/board-halibut.c
 +++ b/arch/arm/mach-msm/board-halibut.c
 @@ -59,6 +59,7 @@ static struct platform_device smc91x_device = {
  };

 +
 +static int __devinit msm_clock_pcom_probe(struct platform_device *pdev)
 +{
 +   struct pcom_clk_pdata *pdata = pdev-dev.platform_data;

Should'nt it be const struct?

 +   msm_clock_init(pdata-lookup, pdata-num_lookups);
 +   return 0;
 +}
 +
--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] ARM: msm: Migrate to common clock framework

[Pankaj Jangra]

Hi Stephen,

On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:

 -static int pc_clk_set_rate(unsigned id, unsigned rate)
 +static int pc_clk_set_rate(struct clk_hw *hw, unsigned long new_rate,
 +  unsigned long p_rate)
  {
 -   /* The rate _might_ be rounded off to the nearest KHz value by the
 +   struct clk_pcom *p = to_clk_pcom(hw);
 +   unsigned id = p-id, rate = new_rate;
 +   int rc;
 +
 +   /*
 +* The rate _might_ be rounded off to the nearest KHz value by the
  * remote function. So a return value of 0 doesn't necessarily mean
  * that the exact rate was set successfully.
  */
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, id, rate);
 -   if (rc  0)
 -   return rc;
 -   else
 -   return (int)id  0 ? -EINVAL : 0;
 -}
 -
 -static int pc_clk_set_min_rate(unsigned id, unsigned rate)
 -{
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, id, rate);
 -   if (rc  0)
 -   return rc;
 +   if (p-flags  CLKFLAG_MIN)
 +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, id, rate);

You are missing if condition here checking the rc ?

 else
 -   return (int)id  0 ? -EINVAL : 0;
 -}
 -
 -static int pc_clk_set_max_rate(unsigned id, unsigned rate)
 -{
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MAX_RATE, id, rate);

and else here i think for the MIN_FLAG if check.

 +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, id, rate);
 if (rc  0)
 return rc;
 else
 return (int)id  0 ? -EINVAL : 0;
  }

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] usb: otg: msm: Convert to clk_prepare/unprepare

[Pankaj Jangra]

On Thu, Sep 27, 2012 at 12:18 AM, Stephen Boyd sb...@codeaurora.org wrote:
 On 09/26/12 09:58, Pankaj Jangra wrote:
 On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 diff --git a/drivers/usb/otg/msm_otg.c b/drivers/usb/otg/msm_otg.c
 index 9f5fc90..2ae0639 100644
 --- a/drivers/usb/otg/msm_otg.c
 +++ b/drivers/usb/otg/msm_otg.c
 @@ -514,13 +514,13 @@ static int msm_otg_suspend(struct msm_otg *motg)
 motg-pdata-otg_control == OTG_PMIC_CONTROL)
 writel(readl(USB_PHY_CTRL) | PHY_RETEN, USB_PHY_CTRL);

 -   clk_disable(motg-pclk);
 -   clk_disable(motg-clk);
 +   clk_disable_unprepare(motg-pclk);
 +   clk_disable_unprepare(motg-clk);
 if (motg-core_clk)
 -   clk_disable(motg-core_clk);
 +   clk_disable_unprepare(motg-core_clk);

 I was under assumption that system suspend/resume might be called from
 the interrupt context. If that is case then its not appropriate to
 call clk_prepare/unprepare here right? or my understanding is not correct

 Well we call disable_irq() at the top of this suspend function so I
 suspect your understanding is incorrect. disable_irq() can call
 schedule(). There are also a bunch of regulator calls in
 msm_hsusb_ldo_set_mode() that this suspend function calls (almost all
 regulator calls grab a mutex).

Ok, might be i am worng because in acpuclock driver of msm on
codeaurora tree, i have seen in commit text saying that it can be
called from suspend/resume in interrupt context .
So i was assuming that. Any way thanks.

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] ARM: msm: Remove clock-7x30.h include file

[Pankaj Jangra]

Hi,

On Wed, Sep 26, 2012 at 11:48 PM, Stephen Boyd sb...@codeaurora.org wrote:
 On 09/26/12 10:51, Pankaj Jangra wrote:
 On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:
 diff --git a/arch/arm/mach-msm/devices-msm7x30.c 
 b/arch/arm/mach-msm/devices-msm7x30.c
 index 09b4f14..1597d43 100644
 --- a/arch/arm/mach-msm/devices-msm7x30.c
 +++ b/arch/arm/mach-msm/devices-msm7x30.c
 @@ -146,7 +146,6 @@ struct clk_lookup msm_clocks_7x30[] = {
 CLK_PCOM(grp_2d_pclk, GRP_2D_P_CLK,   NULL, 0),
 CLK_PCOM(grp_clk, GRP_3D_CLK, NULL, 0),
 CLK_PCOM(grp_pclk,GRP_3D_P_CLK,   NULL, 0),
 -   CLK_7X30S(grp_src_clk, GRP_3D_SRC_CLK, GRP_3D_CLK,NULL, 0),
 CLK_PCOM(hdmi_clk,HDMI_CLK,   NULL, 0),
 CLK_PCOM(imem_clk,IMEM_CLK,   NULL, OFF),
 I suppose you forget to remove the include header clock-7x30.h from
 this file. :)

 Thanks, fixed. BTW, you could have trimmed this mail down so I didn't
 have to scroll to the bottom.

ah, i think mistakenly i forgot. Next time will keep in mind..:)

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] ARM: msm: Migrate to common clock framework

[Pankaj Jangra]

Hi,

On Thu, Sep 27, 2012 at 12:20 AM, Stephen Boyd sb...@codeaurora.org wrote:
 On 09/26/12 11:47, Pankaj Jangra wrote:
 Hi Stephen,

 On Fri, Sep 21, 2012 at 7:56 AM, Stephen Boyd sb...@codeaurora.org wrote:

 -static int pc_clk_set_rate(unsigned id, unsigned rate)
 +static int pc_clk_set_rate(struct clk_hw *hw, unsigned long new_rate,
 +  unsigned long p_rate)
  {
 -   /* The rate _might_ be rounded off to the nearest KHz value by the
 +   struct clk_pcom *p = to_clk_pcom(hw);
 +   unsigned id = p-id, rate = new_rate;
 +   int rc;
 +
 +   /*
 +* The rate _might_ be rounded off to the nearest KHz value by the
  * remote function. So a return value of 0 doesn't necessarily mean
  * that the exact rate was set successfully.
  */
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, id, rate);
 -   if (rc  0)
 -   return rc;
 -   else
 -   return (int)id  0 ? -EINVAL : 0;
 -}
 -
 -static int pc_clk_set_min_rate(unsigned id, unsigned rate)
 -{
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, id, rate);
 -   if (rc  0)
 -   return rc;
 +   if (p-flags  CLKFLAG_MIN)
 +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, id, rate);
 You are missing if condition here checking the rc ?

 else
 -   return (int)id  0 ? -EINVAL : 0;
 -}
 -
 -static int pc_clk_set_max_rate(unsigned id, unsigned rate)
 -{
 -   int rc = msm_proc_comm(PCOM_CLKCTL_RPC_MAX_RATE, id, rate);
 and else here i think for the MIN_FLAG if check.

 +   rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, id, rate);
 if (rc  0)
 return rc;
 else
 return (int)id  0 ? -EINVAL : 0;
  }

 This is the resulting code:

 if (p-flags  CLKFLAG_MIN)
 rc = msm_proc_comm(PCOM_CLKCTL_RPC_MIN_RATE, id, rate);
 else
 rc = msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, id, rate);
 if (rc  0)
 return rc;
 else
 return (int)id  0 ? -EINVAL : 0;

 So we check the rc for both cases in the same if condition. Is there
 anything wrong?
My mistake. I overlooked a line. Sorry for spam. Thanks

--
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] [RFC] clk: new locking scheme for reentrancy

[Pankaj Jangra]

Hi Mike,

On Thu, Aug 16, 2012 at 5:13 AM, Mike Turquette  wrote:
> The global prepare_lock mutex prevents concurrent operations in the clk
> api.  This incurs a performance penalty when unrelated clock subtrees
> are contending for the lock.
>
> Additionally there are use cases which benefit from reentrancy into the
> clk api.  A simple example is reparenting a mux clock with a call to
> clk_set_rate.  Patch #4 in this series demonstrates this without the use
> of internal helper functions.
>
> A more complex example is performing dynamic frequency and voltage
> scaling from clk_set_rate.  Patches #2 and #3 in this series demonstrate
> this.
>
> This commit affects users of the global prepare_lock mutex, namely
> clk_prepare, clk_unprepare, clk_set_rate and clk_set_parent.
>
> This patch introduces an enum inside of struct clk which tracks whether
> the framework has LOCKED or UNLOCKED the clk.
>
> Access to clk->state must be protected by the global prepare_lock mutex.
> In the future maybe the global mutex can be dropped and all operations
> will only use a global spinlock to protect access to the per-clk enums.
> A general outline of the new locking scheme is as follows:
>
> 1) hold the global prepare_lock mutex
> 2) traverse the tree checking to make sure that any clk's needed are
> UNLOCKED and not LOCKED
> a) if a clk in the subtree of affected clk's is LOCKED then
>release the global lock, wait_for_completion and then try
>again up to a maximum of WAIT_TRIES times
> b) After WAIT_TRIES times return -EBUSY
> 3) if all clk's are UNLOCKED then mark them as LOCKED
> 4) release the global prepare_lock mutex
> 5) do the real work
> 6) hold the global prepare_lock mutex
> 7) set all of the clocks previously marked as LOCKED to UNLOCKED
> 8) release the global prepare_lock mutex and return
>
> The primary down-side to this approach is that the clk api's might
> return -EBUSY due to lock contention.  This is only after having tried
> several times.  Bailing out like this is necessary to prevent deadlocks.
>
> The enum approach in this version of the patchset does not benefit from
> lockdep checking the lock order (but neither did v1).  It is possible
> for circular dependencies to pop up for the careless developer and
> bailing out after a number of unsuccessful tries is the sanest strategy.
>
> Signed-off-by: Mike Turquette 
> ---
>  drivers/clk/clk.c|  354 
> +-
>  include/linux/clk-private.h  |1 +
>  include/linux/clk-provider.h |4 +-
>  3 files changed, 318 insertions(+), 41 deletions(-)
>

> +}
> +
> +void __clk_unprepare(struct clk *clk, struct clk *top)

Why do you need to change the signature of __clk_prepare and
__clk_unprepare functions ?
I mean i did not understand the use of passing struct clk *top? As i
understand, it tells when you reach at the last
clk struct in the tree which needs to be prepared/unprepared. Do we
have extra benefit of this or if i am missing something?

> +{
> if (clk->ops->unprepare)
> clk->ops->unprepare(clk->hw);
>
> -   __clk_unprepare(clk->parent);
> +   if (clk != top)
> +   __clk_unprepare(clk->parent, top);
> +}
> +
> +static void __clk_prepare_unlock(struct clk *clk, struct clk *top)
> +{
> +   clk->state = UNLOCKED;
> +
> +   if (clk != top)
> +   __clk_prepare_unlock(clk->parent, top);
>  }
>
>  /**
> @@ -404,35 +437,94 @@ void __clk_unprepare(struct clk *clk)
>   */
>  void clk_unprepare(struct clk *clk)
>  {
> +   struct clk *top = ERR_PTR(-EBUSY);
> +   int tries = 0;
> +
> +   /*
> +* walk the list of parents checking clk->state along the way.  If all
> +* clk->state is UNLOCKED then continue.  If a clk->state is LOCKED 
> then
> +* bail out with -EBUSY.
> +*/
> +   while (IS_ERR(top)) {
> +   mutex_lock(_lock);
> +   top = __clk_unprepare_lock(clk);
> +   mutex_unlock(_lock);
> +
> +   if (IS_ERR(top)) {
> +   pr_debug("%s: %s failed with %ld on attempt %d\n",
> +   __func__, clk->name, PTR_ERR(top),
> +   tries);
> +   wait_for_completion(_completion);
> +   if (WAIT_TRIES == ++tries)
> +   break;
> +   } else
> +   break;

Braces around else part please.

> +   }
> +
> +   if (WAIT_TRIES == tries) {
> +   pr_warning("%s: failed to lock clocks; cyclical 
> dependency?\n",
> +   __func__);
> +   return;
> +   }
> +
> +   /* unprepare the list of clocks from clk to top */
> +   __clk_unprepare(clk, top);
> +

> +   /* unprepare the list of clocks from clk to top */
> +   __clk_prepare(clk, top);

You mean prepare right ? :)



Regards,

Re: [PATCH v2 1/4] [RFC] clk: new locking scheme for reentrancy

[Pankaj Jangra]

Hi Mike,

On Thu, Aug 16, 2012 at 5:13 AM, Mike Turquette mturque...@linaro.org wrote:
 The global prepare_lock mutex prevents concurrent operations in the clk
 api.  This incurs a performance penalty when unrelated clock subtrees
 are contending for the lock.

 Additionally there are use cases which benefit from reentrancy into the
 clk api.  A simple example is reparenting a mux clock with a call to
 clk_set_rate.  Patch #4 in this series demonstrates this without the use
 of internal helper functions.

 A more complex example is performing dynamic frequency and voltage
 scaling from clk_set_rate.  Patches #2 and #3 in this series demonstrate
 this.

 This commit affects users of the global prepare_lock mutex, namely
 clk_prepare, clk_unprepare, clk_set_rate and clk_set_parent.

 This patch introduces an enum inside of struct clk which tracks whether
 the framework has LOCKED or UNLOCKED the clk.

 Access to clk-state must be protected by the global prepare_lock mutex.
 In the future maybe the global mutex can be dropped and all operations
 will only use a global spinlock to protect access to the per-clk enums.
 A general outline of the new locking scheme is as follows:

 1) hold the global prepare_lock mutex
 2) traverse the tree checking to make sure that any clk's needed are
 UNLOCKED and not LOCKED
 a) if a clk in the subtree of affected clk's is LOCKED then
release the global lock, wait_for_completion and then try
again up to a maximum of WAIT_TRIES times
 b) After WAIT_TRIES times return -EBUSY
 3) if all clk's are UNLOCKED then mark them as LOCKED
 4) release the global prepare_lock mutex
 5) do the real work
 6) hold the global prepare_lock mutex
 7) set all of the clocks previously marked as LOCKED to UNLOCKED
 8) release the global prepare_lock mutex and return

 The primary down-side to this approach is that the clk api's might
 return -EBUSY due to lock contention.  This is only after having tried
 several times.  Bailing out like this is necessary to prevent deadlocks.

 The enum approach in this version of the patchset does not benefit from
 lockdep checking the lock order (but neither did v1).  It is possible
 for circular dependencies to pop up for the careless developer and
 bailing out after a number of unsuccessful tries is the sanest strategy.

 Signed-off-by: Mike Turquette mturque...@linaro.org
 ---
  drivers/clk/clk.c|  354 
 +-
  include/linux/clk-private.h  |1 +
  include/linux/clk-provider.h |4 +-
  3 files changed, 318 insertions(+), 41 deletions(-)


 +}
 +
 +void __clk_unprepare(struct clk *clk, struct clk *top)

Why do you need to change the signature of __clk_prepare and
__clk_unprepare functions ?
I mean i did not understand the use of passing struct clk *top? As i
understand, it tells when you reach at the last
clk struct in the tree which needs to be prepared/unprepared. Do we
have extra benefit of this or if i am missing something?

 +{
 if (clk-ops-unprepare)
 clk-ops-unprepare(clk-hw);

 -   __clk_unprepare(clk-parent);
 +   if (clk != top)
 +   __clk_unprepare(clk-parent, top);
 +}
 +
 +static void __clk_prepare_unlock(struct clk *clk, struct clk *top)
 +{
 +   clk-state = UNLOCKED;
 +
 +   if (clk != top)
 +   __clk_prepare_unlock(clk-parent, top);
  }

  /**
 @@ -404,35 +437,94 @@ void __clk_unprepare(struct clk *clk)
   */
  void clk_unprepare(struct clk *clk)
  {
 +   struct clk *top = ERR_PTR(-EBUSY);
 +   int tries = 0;
 +
 +   /*
 +* walk the list of parents checking clk-state along the way.  If all
 +* clk-state is UNLOCKED then continue.  If a clk-state is LOCKED 
 then
 +* bail out with -EBUSY.
 +*/
 +   while (IS_ERR(top)) {
 +   mutex_lock(prepare_lock);
 +   top = __clk_unprepare_lock(clk);
 +   mutex_unlock(prepare_lock);
 +
 +   if (IS_ERR(top)) {
 +   pr_debug(%s: %s failed with %ld on attempt %d\n,
 +   __func__, clk-name, PTR_ERR(top),
 +   tries);
 +   wait_for_completion(clk_completion);
 +   if (WAIT_TRIES == ++tries)
 +   break;
 +   } else
 +   break;

Braces around else part please.

 +   }
 +
 +   if (WAIT_TRIES == tries) {
 +   pr_warning(%s: failed to lock clocks; cyclical 
 dependency?\n,
 +   __func__);
 +   return;
 +   }
 +
 +   /* unprepare the list of clocks from clk to top */
 +   __clk_unprepare(clk, top);
 +

 +   /* unprepare the list of clocks from clk to top */
 +   __clk_prepare(clk, top);

You mean prepare right ? :)



Regards,
Pankaj Kumar
--
To unsubscribe from this list: send the line unsubscribe 

Re: [PATCH 5/13] arch/arm: use clk_prepare_enable and clk_disable_unprepare

[Pankaj Jangra]

Hi,

On Sun, Aug 26, 2012 at 9:30 PM, Julia Lawall  wrote:
> From: Julia Lawall 
>
> Clk_prepare_enable and clk_disable_unprepare combine clk_prepare and
> clk_enable, and clk_disable and clk_unprepare.  They make the code more
> concise, and ensure that clk_unprepare is called when clk_enable fails.
>
> A simplified version of the semantic patch that introduces calls to these
> functions is as follows: (http://coccinelle.lip6.fr/)
>
> // 
> @@
> expression e;
> @@
>
> - clk_prepare(e);
> - clk_enable(e);
> + clk_prepare_enable(e);
>
> @@
> expression e;
> @@
>
> - clk_disable(e);
> - clk_unprepare(e);
> + clk_disable_unprepare(e);
> // 
>
> Signed-off-by: Julia Lawall 
>
> ---
>  arch/arm/common/sa.c   |3 +--
>  arch/arm/common/timer-sp.c |   16 
>  arch/arm/kernel/smp_twd.c  |   13 +++--
>  3 files changed, 8 insertions(+), 24 deletions(-)
>

Reviewed-by: Pankaj Jangra 

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/13] arch/arm: use clk_prepare_enable and clk_disable_unprepare

[Pankaj Jangra]

Hi,

On Sun, Aug 26, 2012 at 9:30 PM, Julia Lawall julia.law...@lip6.fr wrote:
 From: Julia Lawall julia.law...@lip6.fr

 Clk_prepare_enable and clk_disable_unprepare combine clk_prepare and
 clk_enable, and clk_disable and clk_unprepare.  They make the code more
 concise, and ensure that clk_unprepare is called when clk_enable fails.

 A simplified version of the semantic patch that introduces calls to these
 functions is as follows: (http://coccinelle.lip6.fr/)

 // smpl
 @@
 expression e;
 @@

 - clk_prepare(e);
 - clk_enable(e);
 + clk_prepare_enable(e);

 @@
 expression e;
 @@

 - clk_disable(e);
 - clk_unprepare(e);
 + clk_disable_unprepare(e);
 // /smpl

 Signed-off-by: Julia Lawall julia.law...@lip6.fr

 ---
  arch/arm/common/sa.c   |3 +--
  arch/arm/common/timer-sp.c |   16 
  arch/arm/kernel/smp_twd.c  |   13 +++--
  3 files changed, 8 insertions(+), 24 deletions(-)


Reviewed-by: Pankaj Jangra jangra.pank...@gmail.com

Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/