All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prashant Gaikwad <pgaikwad@nvidia.com>
To: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: "mturquette@linaro.org" <mturquette@linaro.org>,
	"sboyd@codeaurora.org" <sboyd@codeaurora.org>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH V2] clk: Add composite clock type
Date: Tue, 5 Feb 2013 14:03:41 +0530	[thread overview]
Message-ID: <5110C3E5.2010503@nvidia.com> (raw)
In-Reply-To: <20130204.113739.2227266298512077917.hdoyu@nvidia.com>

On Monday 04 February 2013 03:07 PM, Hiroshi Doyu wrote:
> Hi Prashant,
>
> Prashant Gaikwad <pgaikwad@nvidia.com> wrote @ Mon, 4 Feb 2013 09:11:22 +0100:
>
>> +struct clk *clk_register_composite(struct device *dev, const char *name,
>> +                       const char **parent_names, int num_parents,
>> +                       struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>> +                       struct clk_hw *div_hw, const struct clk_ops *div_ops,
>> +                       struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>> +                       unsigned long flags)
>> +{
>> +       struct clk *clk;
>> +       struct clk_init_data init;
>> +       struct clk_composite *composite;
>> +       struct clk_ops *clk_composite_ops;
>> +
>> +       composite = kzalloc(sizeof(*composite), GFP_KERNEL);
>> +       if (!composite) {
>> +               pr_err("%s: could not allocate composite clk\n", __func__);
>> +               return ERR_PTR(-ENOMEM);
>> +       }
>> +
>> +       init.name = name;
>> +       init.flags = flags | CLK_IS_BASIC;
>> +       init.parent_names = parent_names;
>> +       init.num_parents = num_parents;
>> +
>> +       /* allocate the clock ops */
>> +       clk_composite_ops = kzalloc(sizeof(*clk_composite_ops), GFP_KERNEL);
> The members of "clk_composite_ops" seems to be always assigned
> statically. Istead of dynamically allocating/assigning, can't we just
> have "clk_composite_ops" statically as below?
>
> static struct clk_ops clk_composite_ops = {
> 	.get_parent = clk_composite_get_parent;
> 	.set_parent = clk_composite_set_parent;
> 	.recalc_rate = clk_composite_recalc_rate;
> 	.round_rate = clk_composite_round_rate;
> 	.set_rate = clk_composite_set_rate;
> 	.is_enabled = clk_composite_is_enabled;
> 	.enable = clk_composite_enable;
> 	.disable = clk_composite_disable;
> };
>
> struct clk *clk_register_composite(struct device *dev, const char *name,
> 		       const char **parent_names, int num_parents,
> 		       struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
> 		       struct clk_hw *div_hw, const struct clk_ops *div_ops,
> 		       struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> 		       unsigned long flags)
> {
> 	.....
>
> 	init.ops = &clk_composite_ops;

No, clk_ops depends on the clocks you are using. There could be a clock 
with mux and gate while another one with mux and div.

WARNING: multiple messages have this Message-ID (diff)
From: pgaikwad@nvidia.com (Prashant Gaikwad)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] clk: Add composite clock type
Date: Tue, 5 Feb 2013 14:03:41 +0530	[thread overview]
Message-ID: <5110C3E5.2010503@nvidia.com> (raw)
In-Reply-To: <20130204.113739.2227266298512077917.hdoyu@nvidia.com>

On Monday 04 February 2013 03:07 PM, Hiroshi Doyu wrote:
> Hi Prashant,
>
> Prashant Gaikwad <pgaikwad@nvidia.com> wrote @ Mon, 4 Feb 2013 09:11:22 +0100:
>
>> +struct clk *clk_register_composite(struct device *dev, const char *name,
>> +                       const char **parent_names, int num_parents,
>> +                       struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
>> +                       struct clk_hw *div_hw, const struct clk_ops *div_ops,
>> +                       struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
>> +                       unsigned long flags)
>> +{
>> +       struct clk *clk;
>> +       struct clk_init_data init;
>> +       struct clk_composite *composite;
>> +       struct clk_ops *clk_composite_ops;
>> +
>> +       composite = kzalloc(sizeof(*composite), GFP_KERNEL);
>> +       if (!composite) {
>> +               pr_err("%s: could not allocate composite clk\n", __func__);
>> +               return ERR_PTR(-ENOMEM);
>> +       }
>> +
>> +       init.name = name;
>> +       init.flags = flags | CLK_IS_BASIC;
>> +       init.parent_names = parent_names;
>> +       init.num_parents = num_parents;
>> +
>> +       /* allocate the clock ops */
>> +       clk_composite_ops = kzalloc(sizeof(*clk_composite_ops), GFP_KERNEL);
> The members of "clk_composite_ops" seems to be always assigned
> statically. Istead of dynamically allocating/assigning, can't we just
> have "clk_composite_ops" statically as below?
>
> static struct clk_ops clk_composite_ops = {
> 	.get_parent = clk_composite_get_parent;
> 	.set_parent = clk_composite_set_parent;
> 	.recalc_rate = clk_composite_recalc_rate;
> 	.round_rate = clk_composite_round_rate;
> 	.set_rate = clk_composite_set_rate;
> 	.is_enabled = clk_composite_is_enabled;
> 	.enable = clk_composite_enable;
> 	.disable = clk_composite_disable;
> };
>
> struct clk *clk_register_composite(struct device *dev, const char *name,
> 		       const char **parent_names, int num_parents,
> 		       struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
> 		       struct clk_hw *div_hw, const struct clk_ops *div_ops,
> 		       struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
> 		       unsigned long flags)
> {
> 	.....
>
> 	init.ops = &clk_composite_ops;

No, clk_ops depends on the clocks you are using. There could be a clock 
with mux and gate while another one with mux and div.

  reply	other threads:[~2013-02-05  8:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04  8:11 [PATCH V2] clk: Add composite clock type Prashant Gaikwad
2013-02-04  8:11 ` Prashant Gaikwad
2013-02-04  9:37 ` Hiroshi Doyu
2013-02-04  9:37   ` Hiroshi Doyu
2013-02-05  8:33   ` Prashant Gaikwad [this message]
2013-02-05  8:33     ` Prashant Gaikwad
     [not found]     ` <5110C3E5.2010503-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-05 10:22       ` Hiroshi Doyu
2013-02-05 10:22         ` Hiroshi Doyu
2013-02-05 10:22         ` Hiroshi Doyu
     [not found]         ` <20130205.122252.570646990867457667.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-05 10:38           ` Tomasz Figa
2013-02-05 10:38             ` Tomasz Figa
2013-02-05 10:38             ` Tomasz Figa
2013-02-05 11:15           ` Russell King - ARM Linux
2013-02-05 11:15             ` Russell King - ARM Linux
2013-02-05 11:15             ` Russell King - ARM Linux
2013-02-06  2:55           ` Prashant Gaikwad
2013-02-06  2:55             ` Prashant Gaikwad
2013-02-06  2:55             ` Prashant Gaikwad
     [not found]             ` <5111C604.8070104-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-06  6:10               ` Hiroshi Doyu
2013-02-06  6:10                 ` Hiroshi Doyu
2013-02-06  6:10                 ` Hiroshi Doyu
     [not found]                 ` <20130206.081048.71241785637713947.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-06  9:52                   ` Prashant Gaikwad
2013-02-06  9:52                     ` Prashant Gaikwad
2013-02-06  9:52                     ` Prashant Gaikwad
     [not found]                     ` <511227F6.3050601-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-06 10:00                       ` Hiroshi Doyu
2013-02-06 10:00                         ` Hiroshi Doyu
2013-02-06 10:00                         ` Hiroshi Doyu
2013-02-06 10:02                       ` Tomasz Figa
2013-02-06 10:02                         ` Tomasz Figa
2013-02-06 10:02                         ` Tomasz Figa
2013-02-05 10:15 ` Tomasz Figa
2013-02-05 10:15   ` Tomasz Figa
2013-02-06  3:04   ` Prashant Gaikwad
2013-02-06  3:04     ` Prashant Gaikwad
2013-02-06 10:06     ` Tomasz Figa
2013-02-06 10:06       ` Tomasz Figa
2013-02-28  7:58       ` Prashant Gaikwad
2013-02-28  7:58         ` Prashant Gaikwad
2013-02-28 18:20         ` Stephen Warren
2013-02-28 18:20           ` Stephen Warren
2013-03-13 16:30           ` Tomasz Figa
2013-03-13 16:30             ` Tomasz Figa
2013-03-19 12:04             ` Prashant Gaikwad
2013-03-19 12:04               ` Prashant Gaikwad
2013-02-05 10:50 ` Hiroshi Doyu
2013-02-05 10:50   ` Hiroshi Doyu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5110C3E5.2010503@nvidia.com \
    --to=pgaikwad@nvidia.com \
    --cc=hdoyu@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.