From: Prashant Gaikwad <pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
<sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org"
<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
<t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH V2] clk: Add composite clock type
Date: Wed, 6 Feb 2013 15:22:54 +0530 [thread overview]
Message-ID: <511227F6.3050601@nvidia.com> (raw)
In-Reply-To: <20130206.081048.71241785637713947.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Wednesday 06 February 2013 11:40 AM, Hiroshi Doyu wrote:
> Prashant Gaikwad <pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote @ Wed, 6 Feb 2013 03:55:00 +0100:
>
>>>> 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.
>>> You are right. What about the following? We don't have to have similar
>>> copy of clk_composite_ops for each instances.
>> Clock framework takes decision depending on the ops availability and it
>> does not know if the clock is mux or gate.
>>
>> For example,
>>
>> if (clk->ops->enable) {
>> ret = clk->ops->enable(clk->hw);
>> if (ret) {
>> __clk_disable(clk->parent);
>> return ret;
>> }
>> }
>>
>> in above case if clk_composite does not have gate clock then as per your
>> suggestion if it returns error value then it will fail and it is wrong.
> Ok, now I understand. Thank you for explanation.
>
> We always need to allocate clk_composite_ops for each clk_composite,
> right? If so what about having "struct clk_ops ops" in "struct
> clk_composite"?
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index f30fb4b..5240e24 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -129,20 +129,13 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> pr_err("%s: could not allocate composite clk\n", __func__);
> return ERR_PTR(-ENOMEM);
> }
> + clk_composite_ops = &composite->ops;
>
> 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);
> - if (!clk_composite_ops) {
> - pr_err("%s: could not allocate clk ops\n", __func__);
> - kfree(composite);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> if (mux_hw && mux_ops) {
> if (!mux_ops->get_parent || !mux_ops->set_parent) {
> clk = ERR_PTR(-EINVAL);
> @@ -202,7 +195,6 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> return clk;
>
> err:
> - kfree(clk_composite_ops);
> kfree(composite);
> return clk;
> }
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index f0ac818..bb5d36a 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -346,6 +346,8 @@ struct clk_composite {
> const struct clk_ops *mux_ops;
> const struct clk_ops *div_ops;
> const struct clk_ops *gate_ops;
> +
> + const struct clk_ops ops;
> };
>
> struct clk *clk_register_composite(struct device *dev, const char *name,
This will work, but there is no harm in allocating dynamically. What is
preferred?
>
>>> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
>>> index f30fb4b..8f88805 100644
>>> --- a/drivers/clk/clk-composite.c
>>> +++ b/drivers/clk/clk-composite.c
>>> @@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struct clk_hw *hw)
>>> const struct clk_ops *mux_ops = composite->mux_ops;
>>> struct clk_hw *mux_hw = composite->mux_hw;
>>>
>>> + if (!mux_hw->clk)
>>> + return -EINVAL;
>>> +
>>> mux_hw->clk = hw->clk;
>> It is wrong.
> Will the above "mux_hw->clk = hw->clk" be removed from the original?
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: Wed, 6 Feb 2013 15:22:54 +0530 [thread overview]
Message-ID: <511227F6.3050601@nvidia.com> (raw)
In-Reply-To: <20130206.081048.71241785637713947.hdoyu@nvidia.com>
On Wednesday 06 February 2013 11:40 AM, Hiroshi Doyu wrote:
> Prashant Gaikwad <pgaikwad@nvidia.com> wrote @ Wed, 6 Feb 2013 03:55:00 +0100:
>
>>>> 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.
>>> You are right. What about the following? We don't have to have similar
>>> copy of clk_composite_ops for each instances.
>> Clock framework takes decision depending on the ops availability and it
>> does not know if the clock is mux or gate.
>>
>> For example,
>>
>> if (clk->ops->enable) {
>> ret = clk->ops->enable(clk->hw);
>> if (ret) {
>> __clk_disable(clk->parent);
>> return ret;
>> }
>> }
>>
>> in above case if clk_composite does not have gate clock then as per your
>> suggestion if it returns error value then it will fail and it is wrong.
> Ok, now I understand. Thank you for explanation.
>
> We always need to allocate clk_composite_ops for each clk_composite,
> right? If so what about having "struct clk_ops ops" in "struct
> clk_composite"?
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index f30fb4b..5240e24 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -129,20 +129,13 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> pr_err("%s: could not allocate composite clk\n", __func__);
> return ERR_PTR(-ENOMEM);
> }
> + clk_composite_ops = &composite->ops;
>
> 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);
> - if (!clk_composite_ops) {
> - pr_err("%s: could not allocate clk ops\n", __func__);
> - kfree(composite);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> if (mux_hw && mux_ops) {
> if (!mux_ops->get_parent || !mux_ops->set_parent) {
> clk = ERR_PTR(-EINVAL);
> @@ -202,7 +195,6 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> return clk;
>
> err:
> - kfree(clk_composite_ops);
> kfree(composite);
> return clk;
> }
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index f0ac818..bb5d36a 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -346,6 +346,8 @@ struct clk_composite {
> const struct clk_ops *mux_ops;
> const struct clk_ops *div_ops;
> const struct clk_ops *gate_ops;
> +
> + const struct clk_ops ops;
> };
>
> struct clk *clk_register_composite(struct device *dev, const char *name,
This will work, but there is no harm in allocating dynamically. What is
preferred?
>
>>> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
>>> index f30fb4b..8f88805 100644
>>> --- a/drivers/clk/clk-composite.c
>>> +++ b/drivers/clk/clk-composite.c
>>> @@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struct clk_hw *hw)
>>> const struct clk_ops *mux_ops = composite->mux_ops;
>>> struct clk_hw *mux_hw = composite->mux_hw;
>>>
>>> + if (!mux_hw->clk)
>>> + return -EINVAL;
>>> +
>>> mux_hw->clk = hw->clk;
>> It is wrong.
> Will the above "mux_hw->clk = hw->clk" be removed from the original?
WARNING: multiple messages have this Message-ID (diff)
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>,
"t.figa@samsung.com" <t.figa@samsung.com>
Subject: Re: [PATCH V2] clk: Add composite clock type
Date: Wed, 6 Feb 2013 15:22:54 +0530 [thread overview]
Message-ID: <511227F6.3050601@nvidia.com> (raw)
In-Reply-To: <20130206.081048.71241785637713947.hdoyu@nvidia.com>
On Wednesday 06 February 2013 11:40 AM, Hiroshi Doyu wrote:
> Prashant Gaikwad <pgaikwad@nvidia.com> wrote @ Wed, 6 Feb 2013 03:55:00 +0100:
>
>>>> 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.
>>> You are right. What about the following? We don't have to have similar
>>> copy of clk_composite_ops for each instances.
>> Clock framework takes decision depending on the ops availability and it
>> does not know if the clock is mux or gate.
>>
>> For example,
>>
>> if (clk->ops->enable) {
>> ret = clk->ops->enable(clk->hw);
>> if (ret) {
>> __clk_disable(clk->parent);
>> return ret;
>> }
>> }
>>
>> in above case if clk_composite does not have gate clock then as per your
>> suggestion if it returns error value then it will fail and it is wrong.
> Ok, now I understand. Thank you for explanation.
>
> We always need to allocate clk_composite_ops for each clk_composite,
> right? If so what about having "struct clk_ops ops" in "struct
> clk_composite"?
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index f30fb4b..5240e24 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -129,20 +129,13 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> pr_err("%s: could not allocate composite clk\n", __func__);
> return ERR_PTR(-ENOMEM);
> }
> + clk_composite_ops = &composite->ops;
>
> 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);
> - if (!clk_composite_ops) {
> - pr_err("%s: could not allocate clk ops\n", __func__);
> - kfree(composite);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> if (mux_hw && mux_ops) {
> if (!mux_ops->get_parent || !mux_ops->set_parent) {
> clk = ERR_PTR(-EINVAL);
> @@ -202,7 +195,6 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
> return clk;
>
> err:
> - kfree(clk_composite_ops);
> kfree(composite);
> return clk;
> }
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index f0ac818..bb5d36a 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -346,6 +346,8 @@ struct clk_composite {
> const struct clk_ops *mux_ops;
> const struct clk_ops *div_ops;
> const struct clk_ops *gate_ops;
> +
> + const struct clk_ops ops;
> };
>
> struct clk *clk_register_composite(struct device *dev, const char *name,
This will work, but there is no harm in allocating dynamically. What is
preferred?
>
>>> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
>>> index f30fb4b..8f88805 100644
>>> --- a/drivers/clk/clk-composite.c
>>> +++ b/drivers/clk/clk-composite.c
>>> @@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struct clk_hw *hw)
>>> const struct clk_ops *mux_ops = composite->mux_ops;
>>> struct clk_hw *mux_hw = composite->mux_hw;
>>>
>>> + if (!mux_hw->clk)
>>> + return -EINVAL;
>>> +
>>> mux_hw->clk = hw->clk;
>> It is wrong.
> Will the above "mux_hw->clk = hw->clk" be removed from the original?
next prev parent reply other threads:[~2013-02-06 9:52 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
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 [this message]
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=511227F6.3050601@nvidia.com \
--to=pgaikwad-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.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.